关于Solr/ES,我们不得不知道的十件事

关于Solr/ES,我们不得不知道的十件事

这里谈一下笔者多年使用Solr/ES的所总结出的Solr/ES十点不足:

1Solr/ES分词的不足之处

对于邮箱、手机号、车牌号码、网址、IP地址、程序类名、含有字母与数字的组合之类的数据会匹配不完整,导致数据查不全,因分词导致漏查以及缺失数据,对于模糊检索有精确匹配要求的场景下,业务存在较大的风险。如何玩转Solr/ES,能够自定义拓展任意的分词类型,如词库分词,语义分词,拼音分词等

2Solr/ES在模糊匹配中的实际问题

Solr/ES的模糊匹配是基于Lucene的分词来实现,但并不考虑单词的匹配顺序,也不保证匹配词语的连续性,中间可以穿插其他单词。为什么不能支持类似SQL中的like匹配,既考虑到了单词之间的匹配顺序,也保证了匹配词语的连续性,也可以通过*进行模糊查询,并能实现较高的like性能

3Solr/ES的用户接口为何不能丰富些?

除了Java API,能不能支持标准SQL的方式,支持JDBC/ODBC接入,能否与大数据生态中其他标准组件无缝对接如HiveSparkKafka等,也可与常见的报表工具、SQL可视化工具集成。

4、对函数的支持

Solr/ES只支持简单的检索过滤,summaxminavg等统计函数,单列groupby。是否能支持更多的函数,支持复杂的SQL,可以嵌套,多表关联,甚至自定义udfudafudtf

5、数据导出如何实现?

Solr/ES中的数据如若想导出到其他系统是比较难,海量原始数据的导出基本是不可行的,更不要说将原始数据经过各种复杂计算清洗后的导出了。比如:支持原始数据的任意维度导出,可以全表,也可以通过过滤筛选局部导出,支持数据经过各种组合计算过滤后的导出。

6、如何解决高性能排序?

按照时间逆序排序是很系统的硬指标。Solr/ES是采用LuceneSort接口实现,本质是借助DocValues的暴力扫描,如果数据量很大的情况下,排序过程会耗费大量的内存与IO资源,排序性能很低。

7、冷热索引处理机制问题

Solr/ES中默认是打开全部的索引,每个索引都会独占一些资源,如内存、文件描述符等。但是一台机器的内存与文件描述符始终是有限的,从而也限制了Solrs/ES能够装载的数据规模,在机器资源有限的情况下,制约了数据规模。

8、稳定性难题

1.笔者在实际环境中,在数据规模超过千万或过亿后,生产系统实时导入经常会出现OOM,以及CPU负载太高的问题,过亿数据事实上无法实时导入数据,一般过百亿的系统均采用离线创建索引的方式,即数据时效性延迟一天。

2Solr/ES中数据规模一旦过百亿,就会频繁的出现OOM,节点调片的情况。一旦调片后无法自动恢复服务,需要运维人员去重启相关服务。系统缺少过载保护,经常是一个人员做了一个复杂的查询,导致集群整体宕机,系统崩溃。这导致当数据量过亿后,Solr/ES在数据量比较大的情况下,实时索引几乎是不可能的,频繁的ord关系映射,会让整个系统不可用。

9、数据存储与恢复

Solr/ES索引存储在本地硬盘,数据恢复比较难:

1.磁盘读写没有很好的控速机制,导入数据没有良好的流量控制机制,无法控制流量,而生产系统,磁盘控速与流量控速是必须的,不能因为业务高峰对系统造成较大的冲击,导致磁盘都hang住或挂掉。

2.本地硬盘局部坏点,对于Solr/ES来说哪怕是仅仅一个byte数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉,但是SolrES如何及时的发现并修正这些错误呢?

3.数据存储在本地磁盘,一旦本地将近20T的存储盘损坏,需要从副本恢复后才能继续服务,恢复时间太长。

10、数据迁移之难

Solr/ES上如何实现跨机房数据迁移,需要运维人员细心的进行索引11复制,搬迁方案往往要数星期,且非常容易出错。而且迁移过程中为了保证数据的一致性,需要中断服务或者中断数据的实时导入,让数据静态化落地后不允许在变化后,才能进行迁移。

 

以上是笔者多年来使用Solr/ES所总结出的十点不足之处,这里用于抛砖引玉,与各位同学一起探讨,共同进步。说到底,Solr/ES并不是全能型的平台,其早在大数据概念未被提出之前,就已然是全文检索方面的首选组件了,我们确实不能对他们奢求太高,只是如果以上问题都得以解决,那可谓是一个近乎全能的产品,尤其在OLAP领域面向海量数据分析来讲,解决了高性能全文检索、即席交互式多维分析、企业级特性等多个难题,必将产生深远影响,感兴趣的同学,请加QQ群交流:171465049(验证口令为vv8086csdn博客)或在此给我评论留言。