Elasticsearch 和 MySQL 對比簡要分析。
背景
我們開發一般的企業級Web應用，其實從本質上來說，都是對數據的增刪查改進行各個維度的包裝。所以說，不管你的程序如何開發，基本上，都離不開數據本身。那麼，在開發企業級應用的過程中，很多同學一定遇到過這樣的困惑，當完成了應用程序的基本增刪查改功能之後，用戶會經常吐槽當下的查詢功能並不能滿足自己的查詢需求。這是因爲，通常情況下，我們基於傳統的數據庫進行開發，都是需要預先去進行各種方面的考慮，然後再開發相應的查詢語句。與其說是查詢語句，不如說是數據過濾語句。這種時候，一個全能的搜索引擎就非常有必要了，通常我們期望它可以檢索各類允許被用戶查詢的數據類型，充分的去已有的數據中檢索用戶想要的數據，並且還能進行智能排序，給用戶最想要的。那麼，問題來了，傳統的MySQL想要實現這麼一個搜索引擎，談何容易，我該怎麼辦？
What is ElasticSearch
ElasticSearch是一個基於Lucene的分佈式搜索引擎，業內簡稱ES。它提供了基於 RESTful 風格的全文搜索API。Elasticsearch是用Java開發的，並作爲Apache許可條款下的開放源碼發佈，是當前最流行的企業級搜索引擎。另外，它的分佈式設計讓它天生就適合用於雲計算中，並能夠達到準實時搜索，而且安裝使用方便，還擁有穩定，可靠，快速等特性。大家可以查閱更多的相關資料對ElasticSearch有更深入的瞭解。
Why Not MySQL
MySQL作爲傳統的關係型數據庫，是當下Web應用開發中最流行的關係型數據庫，沒有之一。那麼，很多同學會說，我對MySQL非常的瞭解，各種技巧，樣樣精通，直接用MySQL實現搜索引擎不就得了？
這裏我們來舉個比較實際的例子，看一下到底MySQL適不適合做搜索引擎。
假設我要求職，這裏我們有一張職位數據表jobs，我想從中檢索一些我想要的工作，一般我會先想好關鍵詞，比如"舒適辦公環境"、“有良好晉升空間"等，如果用MySQL實現，你可能會這樣寫SQL：SELECT * FROM jobs WHERE job_desc LIKE %關鍵詞%。這樣做，理論上是可以搜到一些數據的，比如和用戶輸入的關鍵詞完全匹配的就可以，但是假設jobs表中很多對工作職位的描述換了個說法，比如"辦公環境舒適”、"晉升空間良好"等，顛倒了詞的順序，LIKE關鍵詞肯定是匹配不到了。另外，LIKE是全表掃描的一個操作，如果你的數據量較小，還好說，但如果你數據量在百萬、千萬甚至更多的時候，耗時將是不可想象的，更別說還有惱人的分詞問題，單單使用MySQL是無法解決的。
Why Not Sphinx + MySQL
當然，有很多同學會說，MySQL確實不適合直接做檢索，但是我可以利用Sphinx中間件結合MySQL來做搜索引擎。確實，Sphinx也是一款比較優秀的搜索引擎。在某些方面，它很適合和MySQL做結合來使用。但是，Sphinx和ElasticSearch比起來，卻遜色不少。一方面，在複雜查詢邏輯下，Sphinx使用非常麻煩，在特定情況下，還需要修改Sphinx的源碼才能實現需求，而我們ES天生就擁有非常豐富的Query DSL，可以滿足幾乎任何的檢索情況；另一方面，在橫向擴展和高可用方面，Sphinx實現分佈式可謂是沒事找抽型，它並不是做不到，而是實在是太難用了，而ES從一出生就是爲分佈式、集羣化而生的，不僅方便橫向擴展、動態增加節點，還可以輕鬆的和Nginx等各類中間件實現負載均衡。
ElasticSearch and MySQL
通常，我們可以使用ES來實現自己的站內搜索引擎，但是，作者這裏還是推薦大家使用MySQL來做原始數據的存儲，然後基於MySQL在上層部署我們的ES中間件來實現我們的搜索引擎。主要原因是，MySQL雖然在數據全文檢索方面顯得有些力不從心，但是因爲它的事務功能特性，可以保證不會出現髒數據。而ES對事務方面並無建樹，所以不是很適合存儲原始數據。當然，你可以運用雙寫的策略，一方面利用MySQL保證原始數據的安全性，另一方面，利用ES的搜索力量。不過，作者這邊更推薦的是將兩個中間件直接結合起來，同時使用ES查詢數據，並結合MySQL做數據的增刪查改，具體實現細節，因人而異，大家還是要根據實際的需求來制定最優的解決方案。
總結
ElasticSearch作爲當下越來越火爆的分佈式搜索引擎以及大數據分析中間件，在互聯網技術中，已經佔據了半壁江山，在BAT等各大互聯網公司都有不同程度的應用，成爲了程序猿小朋友不可忽視的一門剛需技術。