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

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

1、Solr/ES分词的不足之处

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

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

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

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

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

4、对函数的支持

 Solr/ES只支持简单的检索过滤，sum，max，min，avg等统计函数，单列groupby。是否能支持更多的函数，支持复杂的SQL，可以嵌套，多表关联，甚至自定义udf，udaf，udtf

5、数据导出如何实现？

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

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

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

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

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

8、稳定性难题

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

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

9、数据存储与恢复

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

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

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

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

10、数据迁移之难

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

 

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