来来来，坐下来，我们一起来聊聊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的一方面。
- 下面都是我自己的YY
在不久的将来，Solr一定会引入更多网络传输协议来代替Http，来降低Http在集群内网络传输的消耗。如你所知，一个简单搜索过程群集内至少需要进两次或两次以上网络交互。将来挺有可能引用像Netty这样的网络传输框架来代替HttpClient，至少会升级Http1.1。
而且这个事，极可能发生在Solr7.x。
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非常看好。
又引入各种常用MetricsReporter，方便运维...