| it技術精華網
今天介紹下elasticsearch的分布式架構，如果你熟悉cassandra、hadoop、mongodb，你會發現elasticsearch裡面有很多他們的影子，沒錯，elasticsearch吸收了目前主流的分布式系統的很多特性，下面簡單介紹一把。
之前翻譯過一篇[譯]搜尋引擎與時間機器，裡面介紹了下作者在設計elasticsearch的一些想法，現在看起來還是記憶猶新，因為他的這種思路實在是非常新穎，比如es裡面的將資料分為工作資料和持久化資料兩種：
單前面說的那個還不算什麼，如果不能很好的解決動態擴容的問題，那就不算是elasticsearch了，在elasticsearch裡面，索引目錄有如下兩個概念：shard（碎片）、replica（副本）碎片(shard)的意思很好理解，db可以有sharding，索引也可以做嘛，單個索引目錄太大，gb級別的索引檔案，你再繼續往裡塞資料，檔案合併，優化，有過這種經驗的人應該會明白這種痛苦，怎麼辦？拆唄（china？拆那？），一般的做法是按資料拆，自己按租戶，按時間拆等等，很是麻煩，並且拆完了之後的事情也不少，跨目錄查詢怎麼辦？更新怎麼辦？介面要怎麼變？這些在elasticsearch裡面都幫你想到了，對你而言，全是透明的，你操作的就是乙個索引，你在建立索引的時候，根據索引的規模指定碎片的大小，其他的你就不用管了，至於它裡面怎麼實現資料的平均分配，其實很簡單，就用了乙個取模的演算法，隨機分配到各個碎片中，至於一致性雜湊之類的，目前來說完全沒有必要。
碎片可以解決單個索引太大的問題，但是凡任何事有利必有弊，索引碎片在實現上其實就分成了很多個索引目錄，索引目錄越多，對建索引的速度會有提示，尤其是多執行緒環境，因為我們建索引的時候單個索引目錄肯定加鎖，一旦涉及鎖，勢必要減慢速度，不過我多幾個目錄，不就可以併發執行了嗎？是的，es就是這麼做的，但是前面說了，有利就有弊，索引搞得到處都是，es查詢起來就很費勁了，一般情況下，我們在沒有使用routing的情況下（後面再介紹routing），es會同時多個執行緒去讀取各個碎片的索引資料，然後再合併查詢結果，另外在es的分布式環境下，碎片如果分布在多台伺服器上就要加上網路的開銷，勢必會影響查詢速度了，在海量資料的前提下，這些其實都還好，並且es支援多種查詢方式(reflink:search type)：
query and fetch：
query then fetch：
dfs, query and fetch：
dfs, query then fetch：
count：
scan：
根據不同的查詢需求，選擇合適的查詢型別，會收到意想不到的效果。
–先整體看看單es節點的模組結構吧：
再看看一次索引操作
再看看一次查詢請求
ElasticSearch 分布式集群
elasticsearch用於構建高可用和可擴充套件的系統。擴充套件的方式可以是購買更好的伺服器 縱向擴充套件 vertical scale or scaling up 或者購買更多的伺服器 橫向擴充套件 horizontal scale or scaling out elasticsearch雖然...
ElasticSearch分布式機制
1 使用場景 大型分布式日誌分析系統elk elasticsearch logstash kibana 大型電商商品搜尋系統 站內搜尋 網盤搜尋引擎等。2 elasticsearch的儲存結構 elasticsearch是檔案儲存，是面向文件型資料庫，一條資料在這裡就是乙個文件，用json作為文件序...
ElasticSearch 分布式集群
elasticsearch用於構建高可用和可擴充套件的系統。擴充套件的方式可以是購買更好的伺服器 縱向擴充套件 vertical scale or scaling up 或者購買更多的伺服器 橫向擴充套件 horizontal scale or scaling out elasticsearch雖然...