近實時，有兩層意思：
集群包含多個節點，每個節點屬於哪個集群都是通過壹個配置來決定的，
Node 是集群中的壹個節點，節點也有壹個名稱，默認是隨機分配的。默認節點會去加入壹個名 稱為 elasticsearch 的集群。如果直接啟動壹堆節點，那麽它們會自動組成壹個elasticsearch 集群，當然壹個節點也可以組成 elasticsearch 集群。
文檔是 es 中最小的數據單元，壹個 document 可以是1條客戶數據、1條商品分類數據、1條 訂單數據，通常用json 數據結構來表示。每個 index 下的 type，都可以存儲多條 document。
1個 document 裏面有多個 field，每個 field 就是1個數據字段。
es 集群多個節點，會自動選舉1個節點為 master 節點，這個 master 節點其實就是幹壹些管理 的工作的，比如維護索引元數據、負責切換 primary shard 和 replica shard 身份等。要是 master 節點宕機了，那麽會重新選舉1個節點為 master 節點。 如果是非 master節點宕機了，那麽會由 master 節點，讓那個宕機節點上的 primary shard 的身 份轉移到其他機器上的 replica shard。接著妳要是修復了那個宕機機器，重啟了之後，master 節點會控制將缺失的 replica shard 分配過去，同步後續修改的數據之類的，讓集群恢復正常。 說得更簡單1點，就是說如果某個非 master 節點宕機了，那麽此節點上的 primary shard 不就 沒了。那好，master 會讓 primary shard 對應的 replica shard（在其他機器上）切換為 primary shard。如果宕機的機器修復了，修復後的節點也不再是 primary shard，而是 replica shard。
索引可以拆分成多個 shard ，每個 shard 存儲部分數據。拆分多個 shard是有好處的，壹是支持橫向擴展，比如妳數據量是 3T，3 個 shard，每個 shard 就 1T 的數據， 若現在數據量增加到 4T，怎麽擴展，很簡單，重新建1個有 4 個 shard 的索引，將數據導進 去；二是提高性能，數據分布在多個 shard，即多臺服務器上，所有的操作，都會在多臺機器 上並行分布式執行，提高了吞吐量和性能。 接著就是這個 shard 的數據實際是有多個備份，就是說每個 shard 都有1個 primary shard ，負責寫入數據，但是還有多個 replica shard 。 primary shard 寫入數據之後， 會將數據同步到其他幾個 replica shard上去。
通過這個 replica 的方案，每個 shard 的數據都有多個備份，如果某個機器宕機了，沒關系啊， 還有別的數據副本在別的機器上，這樣子就高可用了。
總結：分布式就是兩點，1.通過shard切片實現橫向擴展；2.通過replica副本機制，實現高可用
基本概念
寫數據過程：客戶端通過hash選擇壹個node發送請求，這個node被稱做coordinating node（協調節點），協調節點對docmount進行路由，將請求轉發給到對應的primary shard，primary shard 處理請求，將數據同步到所有的replica shard，此時協調節點，發現primary shard 和所有的replica shard都處理完之後，就反饋給客戶端。
客戶端發送get請求到任意壹個node節點，然後這個節點就稱為協調節點，協調節點對document進行路由，將請求轉發到對應的node，此時會使用隨機輪詢算法，在primary shard 和replica shard中隨機選擇壹個，讓讀取請求負載均衡，接收請求的node返回document給協調節點，協調節點，返回document給到客戶端
es最強大的是做全文檢索，就是比如妳有三條數據
1.java真好玩兒啊
2.java好難學啊
3.j2ee特別牛
妳根據java關鍵詞來搜索，將包含java的document給搜索出來。
更新/刪除數據過程，首先還是write、merge操作，然後flush過程中：
1、write過程和上面的壹致；
2、refresh過程有點區別
所謂的倒排索引，就是把妳的數據內容先分詞，每句話分成壹個壹個的關鍵詞，然後記錄好每壹個關鍵詞對應出現在了哪些 id 標識的數據。
然後妳可以從其他地根據這個 id 找到對應的數據就可以了，這個就是倒排索引的數據格式 以及搜索的方式，這種利倒排索引查找數據的式，也被稱之為全文檢索。
Inverted Index就是我們常見的倒排索引, 主要包括兩部分：
壹個有序的數據字典 Dictionary（包括單詞 Term 和它出現的頻率）。
與單詞 Term 對應的 Postings（即存在這個單詞的文件）
當我們搜索的時候，首先將搜索的內容分解，然後在字典裏找到對應 Term，從而查找到與搜索相關的文件內容。
本質上，Stored Fields 是壹個簡單的鍵值對 key-value。默認情況下，Stored Fields是為false的,ElasticSearch 會存儲整個文件的 JSON source。
哪些情形下需要顯式的指定store屬性呢？大多數情況並不是必須的。從_source中獲取值是快速而且高效的。如果妳的文檔長度很長，存儲 _source或者從_source中獲取field的代價很大，妳可以顯式的將某些field的store屬性設置為yes。缺點如上邊所說：假設妳存 儲了10個field，而如果想獲取這10個field的值，則需要多次的io，如果從Stored Field 中獲取則只需要壹次，而且_source是被壓縮過 的。
這個時候妳可以指定壹些字段store為true，這意味著這個field的數據將會被單獨存儲(實際上是存兩份,source和 Stored Field都存了壹份)。這時候，如果妳要求返回field1（store：yes），es會分辨出field1已經被存儲了，因此不會從_source中加載，而是從field1的存儲塊中加載。
Doc_values 本質上是壹個序列化的 列式存儲，這個結構非常適用於聚合（aggregations）、排序（Sorting）、腳本（scripts access to field）等操作。而且，這種存儲方式也非常便於壓縮，特別是數字類型。這樣可以減少磁盤空間並且提高訪問速度,ElasticSearch 可以將索引下某壹個 Document Value 全部讀取到內存中進行操作.
Doc_values是存在磁盤的
在es中text類型字段默認只會建立倒排索引，其它幾種類型在建立倒排索引的時候還會建立正排索引，當然es是支持自定義的。在這裏這個正排索引其實就是Doc Value。
即上文所描述的動態索引
往 es 寫的數據，實際上都寫到磁盤文件裏去了，查詢的時候，操作系統會將磁盤文件裏的數據自動緩存到 filesystem cache 中去。
es 的搜索引擎嚴重依賴於底層的 filesystem cache ，妳如果給 filesystem cache 更多的 內存，盡量讓內存可以容納所有的 idx segment file 索引數據文件，那麽妳搜索的時候就 基本都是走內存的，性能會非常高。 性能差距究竟可以有多大？我們之前很多的測試和壓測，如果走磁盤壹般肯定上秒，搜索性能 絕對是秒級別的，1秒、5秒、10秒。但如果是走 filesystem cache ，是走純內存的，那麽壹 般來說性能比走磁盤要高壹個數量級，基本上就是毫秒級的，從幾毫秒到幾百毫秒不等。
那如何才能節約filesystem cache這部分的空間呢？
當寫數據到ES時就要考慮到最小化數據，當壹行數據有30幾個字段，並不需要把所有的數據都寫入到ES，只需要把關鍵的需要檢索的幾列寫入。這樣能夠緩存的數據就會越多。 所以需要控制每臺機器寫入的數據最好小於等於或者略大於filesystem cache空間最好。 如果要搜索海量數據，可以考慮用ES+Hbase架構。用Hbase存儲海量數據，然後ES搜索出doc id後，再去Hbase中根據doc id查詢指定的行數據。
當每臺機器寫入的數據大於cache os太多時，導致太多的數據無法放入緩存，那麽就可以把壹部分熱點數據刷入緩存中。
對於那些妳覺得比較熱的、經常會有人訪問的數據，最好做個專門的緩存預熱系統，就是 對熱數據每隔壹段時間，就提前訪問壹下，讓數據進入 filesystem cache 裏去。這樣下 次別人訪問的時候，性能肯定會好很多。
把熱數據和冷數據分開，寫入不同的索引裏，然後確保把熱索引數據刷到cache裏。
在ES裏最好不要用復雜的關聯表的操作。當需要這樣的場景時，可以在創建索引的時候，就把數據關聯好。比如在mysql中需要根據關聯ID查詢兩張表的關聯數據：select A.name ,B.age from A join B where A.id = B.id，在寫入ES時直接去把相關聯數據放到壹個document就好。
es 的分頁是較坑的，為啥呢？舉個例子吧，假如妳每頁是 10 條數據，妳現在要查詢第 100 頁，實際上是會把每個 shard 上存儲的前 1000 條數據都查到1個協調節點上，如果妳有個 5 個 shard，那麽就有 5000 條數據，接著協調節點對這 5000 條數據進行壹些合並、處理，再獲取到 最終第 100 頁的 10 條數據。
分布式的，妳要查第 100 頁的 10 條數據，不可能說從 5 個 shard，每個 shard 就查 2 條數據， 最後到協調節點合並成 10 條數據吧？妳必須得從每個 shard 都查 1000 條數據過來，然後根據 妳的需求進行排序、篩選等等操作，最後再次分頁，拿到裏面第 100 頁的數據。妳翻頁的時 候，翻的越深，每個 shard 返回的數據就越多，而且協調節點處理的時間越長，非常坑爹。所 以用 es 做分頁的時候，妳會發現越翻到後面，就越是慢。
我們之前也是遇到過這個問題，用 es 作分頁，前幾頁就幾十毫秒，翻到 10 頁或者幾十頁的時 候，基本上就要 5~10 秒才能查出來壹頁數據了。
解決方案嗎？
1）不允許深度分頁：跟產品經理說，妳系統不允許翻那麽深的頁，默認翻的越深，性能就越差；
2）在APP或者公眾號裏，通過下拉來實現分頁，即下拉時獲取到最新頁，可以通過scroll api來實現；
scroll 會1次性給妳生成所有數據的1個快照，然後每次滑動向後翻頁就是通過遊標 scroll_id 移動獲取下壹頁，性能會比上面說的那種分頁性能要高很多很 多，基本上都是毫秒級的。 但是，唯1的缺點就是，這個適合於那種類似微博下拉翻頁的，不能隨意跳到任何壹頁的場 景。也就是說，妳不能先進到第 10 頁，然後去第 120 頁，然後再回到第 58 頁，不能隨意亂跳 頁。所以現在很多APP產品，都是不允許妳隨意翻頁的，也有壹些網站，做的就是妳只能往 下拉，壹頁壹頁的翻。
初始化時必須指定 scroll 參數，告訴 es 要保存此次搜索的上下文多長時間。妳需要確保用戶不會持續不斷翻頁翻幾個小時，否則可能因為超時而失敗。
除了用 scroll api ，也可以用 search_after 來做， search_after 的思想是使用前壹頁的結果來幫助檢索下壹頁的數據，顯然，這種方式也不允許妳隨意翻頁，妳只能壹頁壹頁往後 翻。初始化時，需要使用壹個唯1值的字段作為 sort 字段。