上手elasticsearch有段時間了，主要以應用為主，未做深入的研究，下面就簡單的日常作個簡單的總結，做個記錄。
版本問題
????????es版本繁雜，讓首次使用的人無從下手。常見的有2+、5+版本，最新版已達6.1，迭代速度還是比較快的，但有個問題值得注意：每個版本間的API并不是完全兼容。
????????版本迭代速度快，導致的另一個問題外圍的工具有些跟不上，比如客戶端、遷移工具等等。建議采用5+版本。不至于太舊，享受不了新版本的功能，也不至于太新，導致外圍工具用不了。
數據遷移
????????版本迭代速度快，你在用的版本會很快顯得有些老舊，為享受到最新版本帶來的益處，數據遷移是個必然的過程。
????????除了自己編碼遷移外，還有幾款方式可以使用，如Elasticsearch-dump、Elasticsearch-Exporter、logstash、snapshot、物理拷貝等。?
????????各工具的使用依然受制于es的版本，如果采用snapshot備份、恢復，數據量大小不受限制，但不能跨版本使用，比如2+版本數據可以直接遷移至5+，但2+不能直接遷移至6+，只能通過5+版本做個過渡。
????????若不同版本間遷移數據，不建議采用物理拷貝的方式，以免出現意想不到的問題。如果使用dump的工具，數據量大的時候就顯得不妥。數據集大的情況下，采用snapshot方式是較好的選擇。
API
????????es基于lucene，sorl亦是基于lucene，所以這三者在使用方式上基本類似，有l(wèi)ucene或sorl基礎的話，es的學習成本幾乎更低。但每個版本的API又不完全一樣，無縫遷移幾乎不可能。還好es的提供RESTFul形式的http接口，語言無關性使其可以應用于各種語言體系下。?
????????具體到Java體系下，就是Node client,Transport client,Rest client,Spring-data-elasticsearch,Spring-data-jest等等，可選擇范圍還是比較廣泛的，鑒于es的版本迭代速度較快，API編寫也要考慮es的版本問題。
安全問題
????????es本身安全方面做的不足，后來elastic公司出品了x-pack組件，來強化中間件的安全性?？上У氖?，免費版本在安全方面基本缺失，但可以借助反向代理工具如Nginx或端口限制來提高其訪問控制權限。
實際應用
????????結合Beats的ELK Stack或者是EFK（fluent）應用是比較常見的日志分析、監(jiān)控架構，es被編寫的初衷是為了讓自己老婆方便搜索菜譜，當然這個愿望目前也沒實現。
????????es更多的是在搜索引擎領域的應用，比如常見的搜索功能：近義詞搜索、自動糾錯、搜索結果分類聚合、拼音搜索、首拼搜索、檢索關鍵字高亮等等。
????????電商應用中常用的推薦功能，采用es+mahout的方式也可以實現，收集用戶的行為數據后，依托一定的基礎算法就可以實現常見的：買過的還買了、看過的又看了、猜你喜歡等電商網站常見的功能，來促進銷售。
????????雖說es為搜索而存在，在某些場景下，也需要實現數據的精確匹配搜索，在大數據量的情況下，比如千萬級、億級，在無特殊優(yōu)化的情況下，其搜索效率遠非Mysql等關系性庫可比擬的，所以一般一些增量比較大、變化頻率不高的數據，存儲在es中是個極佳的選擇。
????????大數據應用當下是如日中天，結合es-hadoop插件，es可以方便的與hadoop體系數據關聯(lián)起來。
相關工具
????????成熟的產品總離不開外圍豐富的工具集，es也不例外，比如官方的ELK Stack套件、X-pack、Beats工具集、APM應用等，es與mysql等關系數據庫數據互通的工具elasticsearch-jdbc，監(jiān)控es集群的Kopf插件，簡單的UI訪問管理工具-head插件，實現中文分詞的ik的插件等等，還有其它插件工具集，網絡搜索“Elasticsearch擴展性插件”就可以看到N多豐富的工具可用。
數據擴展
????????天生設計為分布式存儲的es，集群配置更是簡單的無以復加，只要把cluster.name設置相同，部署在同一可以發(fā)現的網段內，端口不沖突即可完成簡單集群的配置，不熟悉數據分片采用默認配置即可，需要的話就特殊關注下分片策略的問題，生產環(huán)境最簡單的應用建議部署兩個實例，實現數據的簡單備份。
關于上面提到es的常見搜索、推薦功能，后面會針對做一系列實踐，逐個實現，降低入門者上手的門檻。
擴展閱讀：
Spring Boot + Elasticsearch大批量數據集下中文的精確匹配
Spring Boot + Elasticsearch 實現索引批量寫入
