來來來，坐下來，我們一起來聊聊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，方便運維…