摘要
對於Elastic Search的初始印象就是全文本搜索，與solr是競品。它與其他的存儲型數據庫有何區別，爲什麼其他數據庫已經能夠提供文本搜索功能了，還需要ES等一系列問題都是心中的困惑。這篇文章主要就是總結這些問題以及Elastic Search的概括介紹
ES資源
ES 下載：https://www.elastic.co/downloads/elasticsearchES 文檔: https://www.elastic.co/guide/en/elasticsearch/reference/current/index.htmlES 源碼：https://github.com/elastic/elasticsearch
ES 中國論壇: https://elasticsearch.cn/
ES介紹
Elastic 是一個基於ApacheV2的開源系統，能夠提供分佈式，實時的文檔索引並提供在線分析。Schema free.
專有名詞
映射(Mappings)
就是關係型數據庫中的schemas，不同的地方在於ES不用提前明確的指定數據的類型。
索引（indexes）
這邊的索引與通常意義上的索引有些不同，這邊的索引是ES的專業名詞，表示的意義就是關係型數據庫中database,是一個邏輯命名。
類型（Types）
就是關係型數據中的表的意思
集羣架構
主節點
集羣中只有1個，是整個集羣的協調節點。down掉以後，會自動從選舉出一個。負責集羣level的操作，比如創建刪除一個索引。跟蹤哪些節點時集羣的一部分，決定哪個shard分配給哪個節點。
數據節點
保存Lucene的索引分片，構成ES的分佈式索引
接待節點（ingest node）
這個是可以執行預處理的pipeline工作
協調節點
只負責路由，處理search reduce 階段默認情況下，一個節點這些角色都有，當集羣擴大了，想劃分職責了，可以disable到某些角色，
讓某個節點只做一件事。
吐槽：覺得這方面是ES做的不好，沒有一個清晰明確的集羣擴展拓撲圖。比如說在數據規模比較小的時候，所有的節點都是各個角色都有，到數據量大的時候再劃分特定的角色，這個實際操作不切實際，什麼時候就可以確定數據量大，什麼時候特定的角色就比所有角色都有效率高。而且在切換過程中需要怎麼切換，ES不支持resharding,和分片分裂。所以索引也沒辦法遷移了，如何能夠進行角色轉換。而且一旦劃分出coordinate node,客戶端連接節點還得更新。
ES初識
分片
沒有基於節點層面的分片，這點與mongo不同，與cassandra的partition類似。通過id hash來分片的。shard number 需要在創建index一開始去指定，後期如果要更改需要reindex
分佈式查詢
分佈式查詢就是查詢各個shard,然後對結果進行組合，在各個shard上的查詢可以並行進行，但是如果shard number 比節點數多的，在同一個節點上就必須得串行執行了，效率就會降低。一般單個節點上的shard不要超過2個，也就是說index 的shard number 設置爲10，節點水平擴展到20個就差不多了。官方對於不支持shard分裂理由
1. shard分裂就是一個reindex data,這個過程相比較從一個將shard從一個節點copy到另外一個節點會更重
2. 分裂是指數性，1分2，2分4，4分8，不會允許只擴容50%
3. shard 分裂要求你有足夠的能力去保存第二份索引，通常當你意識到你需要擴展時，你可能沒有足夠的空間去支持分片了。ES的reindex過程也是一個比較重的過程，同樣需要有足夠的空間去完成，但是至少你能夠控制新的索引中的索引數量。
> 吐槽:這個分片機制，ES設計的實在是太爛了，對於使用者來說，需要的是自動分片，而不是像MySQL那樣的自己實現，自動分片的含義不僅僅是初始的分片，當然也包括對擴展的要求。使用者怎麼知道自己的數據規模增長的上限，怎麼知道在開始的時候使用多少分片，reindexing在數據量大的情況下，完全是災難，當然應該把這部分工作放在日常解決。
索引
ES的索引是倒排索引，這個與一般的B-Tree索引不同，這也是爲什麼ES是全文本搜索引擎，B-Tree索引的話是針對字段的一個排序，對於模糊查詢比如說like,沒法進行查索引，而倒排索引的話，是一個反向索引，首先是進行分詞，然後記錄詞會哪些字段中出現，這是爲什麼一般的數據庫提供不了全文本搜索引擎的原因。
NoSQL數據庫
ES也有人拿來作爲NoSQL數據庫，因爲默認保存了原始數據，而且有transaction log,保證不丟數據，另外的query比較豐富，一些group by都可以通過aggregation 來實現。所以有些用戶拿來做BI分析
總結
ES使用起來比較簡單，容易上手。提供RESTFUL API接口，JSON文檔存儲，調用起來方便。作爲全文本搜索是一個選擇，與solr的區別暫時不清楚。作爲NoSQL數據庫存儲，查詢豐富在數據量不多，集羣規模不大的情況下可以選用，但是集羣擴展能力不行，分片策略有缺陷。不易在大規模數據存儲時使用。
參考https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.htmlhttps://www.elastic.co/guide/en/elasticsearch/guide/current/overallocation.html
本文分享自微信公衆號 - 方丈的寺院（gh_c98f244e174d）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。