大明聊solr今晚想跟你聊聊Solr6.x

Posted 2021-05-02 金沙数据

来来来，坐下来，我们一起来聊聊Solr6.6。我关注Solr已经有小几年了，对于Solr几个变化或者变化趋势有一点自己的看法。

1. Hi Solr

想聊Solr，不提及ElasticSearch还是挺难的。提到ElasticSearch免不了要谈谈它的爸爸Elastic.CO。 

如你所知，Solr出生很早，比ElasticSearch还要早一些。在Solr5.0之前， Solr一直很Solr，跟Lucene一脉相承。Solr原本就是Lucene一个子项目，连版本都是同步发布，版本也是一致的。

Lucene出生于2003年， Solr大致在2007年，ElasticSearch应该是2010年。

ElasticSearch可以说后起之秀了，主要是Elastic.CO这个大后台，以ElasticSearch为根基，定位于日志流处理，搞出一全套级解决方案，这就是大名顶顶的ELK三套件。

后续Solr走出差不多的路，后面不仅是PMC，还有LucidWorks.com。当然这里关系也不太清楚，LucidWorks号称是Expert for Solr Enterprise Search，是一家卖Solr技术服务的公司。多说一句，Solr 5.x开始Solr的Leader从Make换成Yonik Seeley了，然而Yonik Seeley就是LucidWorks的co-founder。

solr 3.x/4.x Solr Leader都是Make，在这个阶段Solr性能有极大提升，或者加强大数据量级下Solr可用性。主要是这两方面下功夫，例如排倒表诸如迭代，BlockTree，再到FTS；又如TireField来提升区间搜索效率；又如DocValues，优化排序，Facet/Group等等。

Yonik给我最大印象两块，一个SQL on Solr，另一块是JSON Request API。当然他工作也有很多，只是我脑容量的问题。 

另外，Solr6.5的SQL已经重新实现，换成Calcite，貌似由Calcite的作者带来的。

LucidWorks跟着Elastic.CO一样，也整出一整企业级搜索方案（注意搜索方案，不是日志解决方案）。也就是LucidWorks并没有非常强调日志这个关键字，而是聚焦在搜索上，

说这么多，还是介绍LucidWorks这个神级产品，它叫Fusion。后面我发现好多好多大数据产品叫这个名，比如华为的云平台就叫Fusion。

Fusion含类似ELK的三套件，E对Solr，作为搜索、分析引擎；L对Fusion Pipeline/Connectors，当然也可以选用Flume来收集数据。由于Fusion并不是针对日志来说，所以它并没有收集的概念，而是更加注重数据源DataSource；K对Banana，作为分析展示，Dashborad（仪表盘）。

实际上对Banana而言，相比Kibana的话，我只想呵呵。这可能也是因为Solr聚合函数上缺陷吧，另一方面Banana的爸爸不如是Kibana上心。

2. Solr，你变了！

如果你从Solr4.x开始的话，我猜你一定能感觉得到Solr这两年来的巨大变化，或者这个变化趋势。Solr5.x开始出现schemaless这就很ElasticSearch了；到了Solr6.5又引入了API v2，虽然我还没怎么用API v2， 但明显感觉到它非常ElasticSearch；另外是JSON Request API会更贴近ElasticSearch Query DSL，老实说Solr Function Query真是醉人，反正小弟至今不会用，愧疚愧疚愧疚; 最后是SolrJ API方面，也引入新编程风格Fluent Style了。当然这个才刚刚开始，我估计接下来的版本一定会继续往这边靠。

除此之外，Solr也提供了很多聚合函数。通过JSON Request API提供出聚合函数越来越多，也越好用。总比写Facet.Stats好用很多很多，也比写tvh好。这也越来越ElasticSearch的一方面。

在不久的将来，Solr一定会引入更多网络传输协议来代替Http，来降低Http在集群内网络传输的消耗。如你所知，一个简单搜索过程群集内至少需要进两次或两次以上网络交互。将来挺有可能引用像Netty这样的网络传输框架来代替HttpClient，至少会升级Http1.1。而且这个事，极可能发生在Solr7.x。

——我自己的YY 

3. Solr：Sorry! 我是搜索服务器

Solr还是很搜索的，这一定是在过去且在将来，与ElasticSearch保持绝对差异性的关键所在。

其实我对ElasticSearch了解并不多，很多人把ElasticSearch用于搜索服务器，但我感觉并远没有Solr好用。包括分词器的配置，搜索结果再排序，搜索结果转换等等，个人感觉ElasticSearch都不如Solr。 最最简单的，就是搜索调试，打开一个Chrome就能直接调试起来，非常方便。也是因为如此，Solr搜索输出格式也非常复杂和零乱，这也使得Solr不被用于分析吧。因此Solr又搞出SolrResponseWriter，和一堆handler，Component。

4. Solr 6.x

在solr 6.6更新之际，不能不谈谈Solr6.6的一些更新。在我看来，Solr6.6本身没什么特别的东西，但是它给出一些信号，或者说让我们又有一些期待吧。

前面几个更新都是属于API v2范围，然后更新几个都是Streaming Expression。这两个绝对Solr6.x关键特性，非常有意义。当然Streaming Expression跟Parallel SQL是一脉相承的，都能归于Sql的范畴。

streaming api 和Parallel SQL 这是Solr 6.0给出来新功能，也是Solr6.x非常重要功能。虽然这个功能出来已经有一段时间了，但我实际上我还没有开始深入去看它。之所以还没深入来了解它，只是因为她是暂时还只是一个非常的概念，却不实用，或者还存在一些Bug。用了几个小版本prestodb的SQL Parser之后，又切到Calcite，让我看到Solr Sql的希望了。其实对我来说，我并不是很非常关注SQL on Solr，但也说明她在往Analysis NoSQL Database发展。

为什么我一直调强SQL on Solr非常值期待呢，老实说，Solr6.5之前我都说Sql On Solr没什么意义。因为之前它是通SQLParser来解释SQL转成Streaming expression来执行，Solr的Streaming API也非常值得期待。只是不过这方式我并不看好，直到Solr6.5，Calcite的Committer带来Calcite，代替PrestoDB的SqlParser。之所以说看好SQL on Solr，不如说对Calcite非常看好。

“

https://blog.csdn.net/zteny/article/details/72943776

”

收到的都是惊喜