打算寫幾篇elasticsearch使用心得。
第一篇，先從elasticsearch與sphinx的橫向對比開始。橫向對比是反應優點和暴露問題的好方法。我是sphinx陣營轉向elasticsearch陣營的，兩者都是成熟的開源搜尋引擎，各有優劣，這篇文章也可以給糾結使用哪套方案的同學提供一些選擇的依據。
• 導入mysql資料生成索引
sphinx：原生支援基于mysql的表建索引
elasticsearch官方文檔上，資料都是使用restful接口一條一條插入的，也就是增量更新。在資料量非常大的時候，周遊全表重建一次索引會非常消耗時間。而elasticsearch-rivel-mysql這個項目并不是很靠譜，開發者甚至曾經在git上标明deprecated（現在沒了）。反正我是自己另外寫了一套。
在導入mysql資料生成索引時，從易用性、可靠性、速度上來看，sphinx優于elasticsearch。
• 增量更新支援
elasticsearch優于sphinx。elasticsearch把增量更新作為首選curd方式；而sphinx使用輔助表的方案不但不優雅，還會讓你的其他系統變得複雜起來，在你頻繁更改單條資料的時候很容易出錯。
• 可視化與輔助工具
kibana是elasticsearch提供的圖形化界面，基本功能有：1）讀取一個index 2）對一個index寫query查詢出具體資料 3）通過這些資料生成圖表 4）拉幾個圖表生成一個報表。kibana非常強大，根據這些基礎功能，我們已經可以自由定制完成各種複雜需求了。kibana還可以加各種插件，其中最常用的是marvel（性能、狀态監控）與logstash（資料收集），非常好用。
反觀sphinx tools，還停留在性能監控的階段，而且還在内測，被elasticsearch的kibana+全家桶甩太遠了。
• 搜尋算法支援
總的來說，elasticsearch稍微優于sphinx。
• 橫向擴充與高可用
elasticsearch是天生為了叢集化而設計的。索引如果沒有replica就會顯示黃燈，有才會亮綠燈。每個節點分為client node、data node、master node三種角色，在合理的配置之下，任意一台（甚至多台）機器炸了，整個叢集都能正常運作。elasticsearch還支援動态加機器等等功能，暫不贅述。
sphinx也有master searchd和slave searchd的概念，可以分布式，但想實作高可用就相當複雜了。
elasticsearch優于sphinx。sphinx的劣勢不在于做不到，而在于不好用。
• 資源占用
sphinx優于elasticsearch。
不得不說，java在這方面比不上c++。cpu還好，差距不大，記憶體占用方面真心天差地别。
• 搜尋速度
搜尋速度主要看怎麼配置cluster，越多搜起來就越快。
• nlp支援
這裡隻說中文nlp。
sphinx：曾經有個叫coreseek的項目，可惜沒有繼續維護了。
其實雙方都可以開發第三方插件，接入國内的ltp或者ictclas都不難。
• 總結
sphinx和elasticsearch都是很優秀的方案，都經曆了實戰的考驗。當時為什麼我從sphinx倒戈去了elasticsearch，主要原因是：
1）我有定制ranker的需求，elasticsearch的functional score query剛好滿足了我
2）業務越來越大，elasticsearch有更強的橫向擴充能力和高可用性
3）可以用kibana整出好看的報表啊！
現在回頭一看，elasticsearch發力非常猛，版本疊代如火箭一般，社群也很活躍。我認為這個選擇沒有出錯。