延云Ydb与 Solr/ES 的十点对比

一、分词

solr/ES：

对于邮箱、手机号、车牌号码、网址、IP地址、程序类名、含有字母与数字的组合之类的数据会匹配不完整，导致数据查不全，因分词导致漏查以及缺失数据，对于模糊检索有精确匹配要求的场景下，业务存在较大的风险。

YDB：

内置的分词类型会确保查询准确度，不会出现漏查，内置的分词类型，很好的解决了lucene默认分词导致的查询数据缺失的问题。另外YDB可以自定义拓展任意的luene分词类型。如词库分词，语义分词，拼音分词等。

二、排序

solr/ES：

采用lucene的Sort接口实现，本质是借助docvalues的暴力扫描，如果数据量很大排序过程耗费非常多的内存与IO，并且排序耗时很高。

YDB：

按照时间逆序排序可以说是很多日志系统的硬指标。在延云YDB系统中，我们改变了传统的暴力排序方式，通过索引技术，可以超快对数据进行单列排序，不需要全表暴力扫描，这个技术我们称之为blockSort，目前支持tlong,tdouble,tint,tfloat四种数据类型。

由于blockSort是借助搜索的索引来实现的，所以,采用blockSort的排序，不需要暴力扫描，性能有大幅度的提升。
详细测试请参考 http://blog.csdn.net/qq_33160722/article/details/54447022

三、模糊匹配

solr/ES：

基于lucene的分词来实现，但并不考虑单词的匹配顺序，也不保证匹配词语的连续性，中间可以穿插其他单词。

YDB：

1.除了常规lucene的分词匹配外，YDB还支持类似SQL中的like匹配。

即考虑到了单词之间的匹配顺序，也保证了匹配词语的连续性，也可以通过*进行模糊查询。

这个like也使用了lucene倒排索引，并非采用暴力扫描实现，故like性能比常规实现高很多，

2.除了常规匹配外，YDB也提供了额外的近似文本匹配与近似特征匹配。

近似文本匹配适合对长文本（如文章）进行匹配，可能中间相差几个字不或者局部的字顺序前后颠倒都没关系，只要大部分相似就可以匹配上。
近似特征匹配适合我指定一系列的特征，如高矮，胖瘦，年龄段，性别，时间等一系列目击者看到的嫌疑人特征，但是有可能有些目击者描述的不准确，所以不能进行精确匹配，如果能与大部分的匹配条件都相似，一两个条件没匹配上，但已经足以相似了，那么也要返回匹配结果。

四、用户接口

solr/es：

采用java API的方式，用户学习成本高。

因不是通用的通讯协议，与其他大数据系统集成对接麻烦。

YDB：

采用SQL的方式，用户学习陈本低。

支持HIVE的JDBC接入（编程），可以命令行接入（定时任务），http方式接入。

Hive的JDBC协议，已经是大数据的事实标准。

与常规大数据系统可无缝对接（如hive,spark,kafka等），也提供了拓展接口。

海量数据导入导出灵活方便，也可与常见的支持jdbc的报表工具、SQL可视化工具集成。

五、函数与功能

solr/es：

只支持简单的检索过滤,sum,max,min,avg等统计函数，单列group by

YDB：

除了solr/ES的简单功能外，内置了HIVE上百个函数，支持复杂的SQL，可以嵌套，多表关联，自定义udf,udaf,udtf，开源界已经有的函数库如Hivemall等也可以直接集成进来使用。
相对于solr/ES除了基本的数据检索外，还能做更复杂的分析。如：数据碰撞分析\同行车辆分析\陌生车辆分析\昼伏夜出、落脚点分析\ OLAP之多维分析\指数分析\人群画像\嫌疑车辆分析等。

六、数据导出

solr/es：

数据如若想导出到其他系统很难，大数据量原始数据的导出基本是不可行的，更别提还要将原始数据经过各种复杂计算后的清洗后的导出了。

YDB：

支持原始数据的任意维度导出
可以全表，也可以通过过滤筛选局部导出
支持数据经过各种组合计算过滤后的导出
可以将YDB中的多个表与其他系统的多个表，进行组合筛选过滤计算后在导出

可以将多个数据从ydb的一张表导入到YDB的另外一张表
可以将YDB里面的数据导出到别的系统里面（如hive，hbase，数据库等）
也可以将其他系统的数据导入到YDB里面。
可以从导出成文件，也可以从文件导入。
可以从kafka流式导入，也可以写插件，导出到kafka。

七、数据导入

solr/es：

采用API的方式导入数据

1.支持实时导入，在千万数据规模下导入性能较好。

2.数据过亿后，生产系统实时导入经常会出现OOM，以及CPU负载太高的问题，故过亿数据无法实时导入数据，一般过百亿的系统均采用离线创建索引的方式，即数据时效性延迟一天。

3.没有良好的合并控制策略，系统会发生阶段性（几分钟）的负载极高的情况（索引合并），此时系统资源占用特别高，前台查询响应速度极慢。

YDB：

采用SQL方式的批量导入，也支持kafka的流式导入

1.索引的设计实现，不会想solr与es那样将数据全部加载到内种内存中进行映射，这无论是在导入还是在查询过程中均大幅的减少了OOM的风险。

2.在内存与磁盘多个区域不同合并策略，在结合控速逻辑，让导入占用的性能控制在一定范围之内，让系统更平稳，尽量减少索引合并瞬间产生的几分钟占据了大量的资源的情况，分散资源的占用，让前台用户的查询更平稳。

3.结合了storm流式处理的优点，采用对接消息队列（如kafka）的方式，数据导入kafka后大约1~2分钟即可在ydb中查到。

八、数据存储与恢复

solr/es：

索引存储在本地硬盘，恢复难

1.磁盘读写没有很好的控速机制，导入数据没有良好的流量控制机制，无法控制流量，而生产系统，磁盘控速与流量控速是必须的，不能因为业务高峰对系统造成较大的冲击，导致磁盘都hang住或挂掉。
2.本地硬盘局部坏点，造成局部数据损坏对于lucene来说无法识别，但是对于索引来说哪怕是仅仅一个byte数据的读异常，就会造成索引指针的错乱，导致检索结果数据丢失，甚至整个索引废掉，但是solr与es不能及时的发现并修正这些错误。
3.数据存储在本地磁盘，一旦本地将近20T的存储盘损坏，需要从副本恢复后才能继续服务，恢复时间太长。

YDB：

将数据存储在HDFS之上

1.YDB基于HDFS做了磁盘与网络做了读写控速逻辑。

2.磁盘局部坏点hdfs配有crc32校验，有坏点会立即发现，并不影响服务，会自动切换到没有坏点的数据继续读取。

3.本地磁盘损坏，HDFS自动恢复数据，不会中断读写，不会有服务中断。

九、数据迁移

solr/es：

1.如若夸机房搬迁机器，需要运维人员细心的进行索引1对1复制，搬迁方案往往要数星期，且非常容易出错。

2.迁移过程中为了保证数据的一致性，需要中断服务或者中断数据的实时导入，让数据静态化落地后不允许在变化后，才能进行迁移。

YDB：

1.hdfs通过balance自动迁移数据。

2.可以控制迁移过程中的带宽流量。
2.迁移过程中不中断服务，hdfs扩容与移除机器也对服务没影响。

十、稳定性

solr/es：

1.数据规模一旦过百亿，就会频繁的出现OOM，节点调片的情况。

2.一旦调片后无法自动恢复服务，需要运维人员去重启相关服务。

3.系统无过载保护，经常是一个人员做了一个复杂的查询，导致集群整体宕机，系统崩溃。
lucene在索引合并过程中，每进行一次commit都要进行一次全范围的ord关系的重新映射，数据规模小的时候整个索引文件的映射还没什么，但是当数据量达到亿级别，甚至百亿级别后，这种映射关系会占用超多的CPU、内存、硬盘资源，所以当数据量过亿后，solr与Es在数据比较大的情况下，实时索引几乎是不可能的，频繁的ord关系映射，会让整个系统不可用。

YDB：

YDB相对于solr/es底层做了大幅度的改动，更适合海量数据。

1.优化或修正LUCENE的BUG大幅度的缩减了OOM，频繁调片的风险。

2.服务自动迁移与恢复的特性，大幅减少运维人员驻场的工作量。

3.提供了导入与查询的限流控制，也提供了过载保护控制，甚至在极端场景提供了有损查询与有损服务。