橫向對比ElasticSearch與Sphinx

01-31

專欄第一篇，先從Elastic Search與Sphinx的橫向對比開始。橫向對比是反映優點和暴露問題的好方法。我是Sphinx陣營轉向Elastic Search陣營的，兩者都是成熟的開源搜索引擎，各有優劣，這篇文章也可以給糾結使用哪套方案的同學提供一些選擇的依據。

? 導入MySQL數據生成索引

Elastic Search：RESTful介面，或 GitHub - scharron/elasticsearch-river-mysql

Sphinx：原生支持基於MySQL的表建索引

Elastic Search官方文檔上，數據都是使用RESTful介面一條一條插入的，也就是增量更新。有個bulk介面，可以批量導入、大幅加快速度。在數據量非常大的時候，遍歷全表重建一次索引會比較消耗時間。elasticsearch-rivel-mysql這個項目並不是很靠譜，開發者甚至曾經在git上標明deprecated。

我是推薦使用bulk方法的，畢竟Logstash就是用這個。

在導入MySQL數據生成索引時，從易用性、可靠性、速度上來看，Sphinx優於Elastic Search。Sphinx真的很快。

? 增量更新支持

Elastic Search優於Sphinx。Elastic Search把增量更新作為首選CURD方式；而Sphinx使用輔助表的方案不但不優雅，還會讓你的其他系統變得複雜起來，在你頻繁更改單條數據的時候很容易出錯。

? 可視化與輔助工具

Elastic Search：Kibana，Beats，Logstash，Marvel，Head

Sphinx：Sphinx Tools

Kibana是Elastic Search提供的數據可視化界面，基本功能有：1）讀取一個Index 2）對一個Index寫query查詢出具體數據 3）通過這些數據生成圖表 4）拉幾個圖表生成一個報表。

Kibana非常強大，根據這些基礎功能，我們已經可以自由定製完成各種複雜需求了。Kibana還可以加各種插件，其中最常用的是Marvel（性能、狀態監控），非常好用。

Beats是一套收集日誌的框架，官方稱為Data Shipper。這個以後單獨拿來說。

Logstash是一套日誌處理框架。老實說我很長一段時間迷茫Logstash跟Beats各自定位...簡單來說，Beats是專門用來收集數據的，Logstash是專門用來處理數據的。

反觀Sphinx Tools，還停留在性能監控的階段，而且還在內測，被Elastic Search的全家桶甩太遠了。

? 搜索演算法支持

ElasthcSearch的搜索底層功能基於Lucene，Sphinx也該有的都有。然而Elastic Search的Query DSL支持更複雜的查詢邏輯，這一點是超越Sphinx的。

在自定義Ranker方面，Elastic Search的Function Score Query比Sphinx的expression-ranker強大許多。當年我為了讓Sphinx支持一個定製的Ranker，不得不去改源碼，後來發現這個功能在Elastic Search上可以輕鬆實現。

總的來說，Elastic Search稍微優於Sphinx。

? 橫向擴展與高可用

Elastic Search是天生為了集群化而設計的。索引如果沒有Replica就會顯示黃燈，有才會亮綠燈。每個節點分為Client Node、Data Node、Master Node三種角色，在合理的配置之下，任意一台（甚至多台）機器炸了，整個集群都能正常運行。Elastic Search還支持動態加機器等等功能，暫不贅述。

Sphinx也有master searchd和slave searchd的概念，可以分散式，但想實現高可用就相當複雜了。

Elastic Search優於Sphinx。Sphinx的劣勢不在於做不到，而在於不好用。

? 資源佔用

Sphinx優於Elastic Search。

不得不說，java在這方面比不上C++。無論是CPU還是內存佔用，Sphinx都比Elastic Search優秀。所以在一些高並發的簡單需求，我依然會選擇Sphinx。

? 搜索速度

搜索速度主要看怎麼配置Cluster，越多搜起來就越快。

? NLP支持

這裡只說中文NLP。

Elastic Search：IK、結巴

Sphinx：曾經有個叫coreseek的項目，可惜沒有繼續維護了。

其實雙方都可以開發第三方插件，接入國內的LTP或者ICTCLAS都不難。

? 總結

Sphinx和Elastic Search都是很優秀的方案，都經歷了實戰的考驗。當時為什麼我從Sphinx倒戈去了Elastic Search，主要原因是：

? 我有定製Ranker的需求，Elastic Search的Functional Score Query剛好滿足了我

? 業務越來越大，Elastic Search有更強的橫向擴展能力和高可用性

? 可以用Kibana整出好看的報表啊！

現在回頭一看，Elastic Search發力非常猛，版本迭代如火箭一般，社區也很活躍。我認為這個選擇沒有出錯。