es一個索引能存儲多少數據

① java操作es獲取索引存儲大小

150GB。
在ES中，索引是一組文檔的集合，由於ES是個分布式的搜索引擎，索引會數絕被分解成不同部分，索引大小為150GB。
Java指編程語言，Java具有大部分編程語言所共有的一些特徵，被特意設計用於互聯網衡告的分布式環境，使用Java編寫的應用程序，既可以在一台單獨的電咐畢明腦上運行，也可以被分布在一個網路的伺服器端和客戶端運行。

② Elasticsearch 能夠存儲的數據量一般有多大

單獨看ES能玩多大數據意義不大，具體實踐中往往因為各種業務要求而無法繼續增加數據量。目大的方面考慮有如下幾點：
1、查詢速度。ES可以支持的查詢類型多種多樣，單一的term匹配，復雜的historm agg，甚至父子文檔模式下bool查詢之後繼續做文本高亮，數據量越大查詢時間越長。如果只是簡單的把數據寫進去然後按照ID獲取數據，那就盡管往裡面寫數據吧。
2、寫入速度。數據量越大，寫入速度受影響的可能性越大。業務要求1小時的數據1小時內必須寫完，如果做不到就得考慮分索引或者分集群了。
3、更新速度。同上，更新比單純的寫入操作更多，先get再merge再overwrite到es。
4、其他因素。
目前我遇到的ES集群，有1.5T-2T索引量的情況下，需要支持平均查詢在500ms以內的高並發高亮查詢。在我們的場景下這個量級不算小了。

③ 【ES】ElasticSearch 深入分片

@[toc]

分片是 Elasticsearch 在集群中分發數據的關鍵。

把分片想像成數據的容器。文檔存儲在分片中，然後分片分配到集群中的節點上。當集群擴容或縮小，Elasticsearch 將會自動在節點間遷移分片，以使集群保持平衡。

一個分片(shard)是一個最小級別「工作單元(worker unit)」，它只是保存了索引中所有數據的一部分。

這類似於 MySql 的分庫分表，只不過 Mysql 分庫分表需要藉助第三方組件而 ES 內部自身實現了此功能。

分片可以是 主分片(primary shard) 或者是 復制分片(replica shard) 。

在集群中唯一一個空節點上創建一個叫做 blogs 的索引。默認情況下，一個索引被分配 5 個主分片，下面只分配 3 個主分片和一個復制分片（每個主分片都有一個復制分片）並碼：

在一個多分片的索引中寫入數據時，通過路由來確定具體寫入哪一個分片中，大致路由過程如下：

routing 是一個可變值，默認是文檔的 _id ，也可以設置成一個自定義的值。routing 通過 hash 函數生成一個數字，然後這個數字再除以 number_of_primary_shards （主分片的數量）後得到余數 。這個在 0 到 number_of_primary_shards 之間的余數，就是所尋求的文檔所在分片的位置。

這解釋了為什麼要在創建索引的時候就確定好主分片的數量並且永遠不會改變這個數量： 因為如果數量變化了，那麼所有之前路由的值都會無效，文檔也再也找不到了 。

索引中的每個文檔屬於一個單獨的主分片，所以 主分片的數量決定了索引最多能存儲多少數據 （實際的數量取決於數據、硬體和應用場景）。

復制分片只是主分片的一個副本，它可以 防止硬體故障導致的數據丟失，同時可以提供讀請求，比如搜索或者從別的 shard 取迴文檔 。

每個主分片都有一個或多個副本分片，當主分片異常絕飢哪時，副本可以提供數據的肢滾查詢等操作。主分片和對應的副本分片是不會在同一個節點上的，所以副本分片數的最大值是 n -1（其中 n 為節點數）。

當索引創建完成的時候，主分片的數量就固定了，但是復制分片的數量可以隨時調整，根據需求擴大或者縮小規模。如把復制分片的數量從原來的 1 增加到 2 ：

分片本身就是一個完整的搜索引擎，它可以使用單一節點的所有資源。 主分片或者復制分片都可以處理讀請求——搜索或文檔檢索，所以數據的冗餘越多，能處理的搜索吞吐量就越大。

對文檔的新建、索引和刪除請求都是寫操作，必須在主分片上面完成之後才能被復制到相關的副本分片，ES 為了提高寫入的能力這個過程是並發寫的，同時為了解決並發寫的過程中數據沖突的問題，ES 通過樂觀鎖的方式控制，每個文檔都有一個 _version （版本）號，當文檔被修改時版本號遞增。一旦所有的副本分片都報告寫成功才會向協調節點報告成功，協調節點向客戶端報告成功。

ES 集群中每個節點通過路由都知道集群中的文檔的存放位置，所以每個節點都有處理讀寫請求的能力。

在一個寫請求被發送到某個節點後，該節點即為協調節點，協調節點會根據路由公式計算出需要寫到哪個分片上，再將請求轉發到該分片的主分片節點上。假設 shard = hash(routing) % 4 = 0 ，則過程大致如下：

寫入磁碟的倒排索引是不可變的，優勢主要表現在：

當然，不可變的索引有它的缺點：

在全文檢索的早些時候，會為整個文檔集合建立一個大索引，並且寫入磁碟。只有新的索引准備好了，它就會替代舊的索引，最近的修改才可以被檢索。這無疑是低效的。

因為索引的不可變性帶來的好處，那如何在保持不可變同時更新倒排索引？

答案是，使用多個索引。 不是重寫整個倒排索引，而是增加額外的索引反映最近的變化。 每個倒排索引都可以按順序查詢，從最老的開始，最後把結果聚合。

這就引入了 段 （segment） ：

分片下的索引文件被拆分為多個子文件，每個子文件叫作 段 ， 每一個段本身都是一個倒排索引，並且段具有不變性，一旦索引的數據被寫入硬碟，就不可再修改。

段被 寫入到磁碟 後會生成一個 提交點 ，提交點是一個用來記錄所有提交後段信息的文件。一個段一旦擁有了提交點，就說明這個段只有讀的許可權，失去了寫的許可權。相反，當段在內存中時，就只有寫的許可權，而不具備讀數據的許可權，意味著不能被檢索。

在 Lucene 中的索引（Lucene 索引是 ES 中的分片，ES 中的索引是分片的集合）指的是段的集合，再加上提交點(commit point)，如下圖：

在底層採用了分段的存儲模式，使它在讀寫時幾乎完全避免了鎖的出現，大大提升了讀寫性能。

索引文件分段存儲並且不可修改 ，那麼新增、更新和刪除如何處理呢？

ES 是怎麼做到 近實時 全文搜索？

磁碟是瓶頸。提交一個新的段到磁碟需要 fsync 操作，確保段被物理地寫入磁碟，即時電源失效也不會丟失數據。但是 fsync 是昂貴的，嚴重影響性能，當寫數據量大的時候會造成 ES 停頓卡死，查詢也無法做到快速響應。

所以 fsync 不能在每個文檔被索引的時就觸發，需要一種更輕量級的方式使新的文檔可以被搜索，這意味移除 fsync 。

為了提升寫的性能，ES 沒有每新增一條數據就增加一個段到磁碟上，而是採用 延遲寫 的策略。

每當有新增的數據時，就將其先寫入到內存中，在內存和磁碟之間是文件系統緩存，當達到默認的時間（1秒鍾）或者內存的數據達到一定量時，會觸發一次刷新（Refresh），將內存中的數據生成到一個新的段上並緩存到文件緩存系統 上，稍後再被刷新到磁碟中並生成提交點 。

這里的內存使用的是ES的JVM內存，而文件緩存系統使用的是操作系統的內存。新的數據會繼續的被寫入內存，但內存中的數據並不是以段的形式存儲的，因此不能提供檢索功能。由內存刷新到文件緩存系統的時候會生成了新的段，並將段打開以供搜索使用，而不需要等到被刷新到磁碟。

在 Elasticsearch 中，這種寫入和打開一個新段的輕量的過程叫做 refresh （即內存刷新到文件緩存系統）。默認情況下每個分片會每秒自動刷新一次。 這就是為什麼說 Elasticsearch 是近實時的搜索了：文檔的改動不會立即被搜索，但是會在一秒內可見。

也可以手動觸發 refresh。 POST /_refresh 刷新所有索引， POST /index/_refresh 刷新指定的索引：

沒用 fsync 同步文件系統緩存到磁碟，不能確保電源失效，甚至正常退出應用後，數據的安全。為了 ES 的可靠性，需要確保變更持久化到磁碟。

雖然通過定時 Refresh 獲得近實時的搜索，但是 Refresh 只是將數據挪到文件緩存系統，文件緩存系統也是內存空間，屬於操作系統的內存，只要是內存都存在斷電或異常情況下丟失數據的危險。

為了避免丟失數據，Elasticsearch添加了 事務日誌（Translog） ，事務日誌記錄了所有還沒有持久化到磁碟的數據。

有了事務日誌，過程現在如下：

事務日誌記錄了沒有 flush 到硬碟的所有操作。當故障重啟後，ES 會用最近一次提交點從硬碟恢復所有已知的段，並且從日誌里恢復所有的操作。

在 ES 中，進行一次提交並刪除事務日誌的操作叫做 flush 。分片每 30 分鍾，或事務日誌過大會進行一次 flush 操作。 flush API 也可用來進行一次手動 flush ， POST/ _flush 針對所有索引有效， POST /index/_flush 則指定的索引：

通常很少需要手動 flush ，通常自動的就夠了。

總體的流程大致如下：

由於自動刷新流程每秒會創建一個新的段 ，這樣會導致短時間內的段數量暴增。而段數目太多會帶來較大的麻煩。每一個段都會消耗文件句柄、內存和 cpu 運行周期。更重要的是，每個搜索請求都必須輪流檢查每個段然後合並查詢結果，所以段越多，搜索也就越慢。

ES 通過後台合並段解決這個問題。小段被合並成大段，再合並成更大的段。這時舊的文檔從文件系統刪除的時候，舊的段不會再復制到更大的新段中。合並的過程中不會中斷索引和搜索。

段合並在進行索引和搜索時會自動進行，合並進程選擇一小部分大小相似的段，並且在後台將它們合並到更大的段中，這些段既可以是未提交的也可以是已提交的。

合並結束後老的段會被刪除，新的段被 flush 到磁碟，同時寫入一個包含新段且排除舊的和較小的段的新提交點，新的段被打開可以用來搜索。

1. 全文搜索引擎Elasticsearch，這篇文章給講透了
2.ElasticSearch 權威指南》

④ ES索引設計

一個碼拆神index可以被分為多個shards，從而分布到不同的物理機上。Shard的劃分結果也會影響索引和查詢速度。
每個分片都可以處理數據寫入和查詢請求，在設置索引分片數時，可從以下幾個方面考慮：

一個shard就是一個lucene分片，ES底層基於lucene實現。
通常根據集群中的節點數量，對集群中的Shards數進行合理限制。

分片的大小和數量怎麼設定？
注1： 小的分片會造成小的分段，從而會增加開銷。我們的目的是將平均分片大小控制在幾 GB 到幾十 GB 之間。對於基於時間的數據的使用場景來說，通常將分片大小控制在 20GB 到 40GB 之間。

注2： 由於每個分片的開銷取決於分段的數量和大小，因此通過 forcemerge 操作強制將較小的分段合並為較大的分段，這樣可以減少開銷並提高查詢性能。 理想情況下，一旦不再向索引寫入數據，就應該這樣做。 請注意，這是一項比較耗費性能和開銷的操作，因此應該在非高峰時段執行。

注3： 我們可以在節點上保留的分片數量與可用的堆內遲虧存成正比，但 Elasticsearch 沒有強制的固定限制。 一個好的經驗法則是確保每個節點的分片數量低於每GB堆內存配置20到25個分片。 因此，具有30GB堆內存的節點應該具有最多600-750個分片，但是低於該限制可以使其保持更好。 這通常有助於集群保持健康。

注4： 如果擔心數據的快速增長, 建議根據這條限制: ElasticSearch推薦的最大JVM堆空間是 30~32G, 把分片最大容量限制為 30GB, 然後再對分片數量做合理估算。例如, 如果的數據能達到 200GB, 則最多分配7到8個分片。

索引和shard數並不是越多越好，對於批量讀寫都會有性能下降，所以要綜合考慮性能和容量規劃，同時配合壓力測試，不存在真正的最優解。

索引的⽣命周期有五個階段：

ES中open狀態的索引都會佔用堆內存來存儲倒排索引，過多的索引會導致集群整體內存使用率多大，甚至引起內存溢出。所以需要根據自身業務管理歷史數據的生命周期，如近3個月的數據open用於快速查詢；過去3-6月的數據索引close以釋放內存，需要時再開啟；超過6個月的可以刪除索引。

可以使用索引模板的方式按照一定時間創建新的索引，例如按御困天創建索引，索引的命名可能是index-yyyy-mm-dd，每天生成不同的索引，清除歷史數據時可直接關閉或刪除。

⑤ ES是什麼

是指Elastic search。

Elasticsearch是一個基於Lucene的搜索伺服器。它提供了一個分布式多用戶能力的全文搜索引擎，基於RESTful web介面。Elasticsearch是用Java語言開發的，並作為Apache許可條款下的開放源碼發布，是一種流行的企業級搜索引擎。

Elasticsearch用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。官方客戶端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和許多其他語言中都是可用的。根據DB-Engines的排名顯示，Elasticsearch是最受歡迎的企業搜索引擎，其次是Apache Solr，也是基於Lucene。

相關信息：

Elasticsearch可以用於搜索各種文檔。它提供可擴展的搜索，具有接近實時的搜索，並支持多租戶。Elasticsearch是分布式的，這意味著索引可以被分成分片，每個分片可以有0個或多個副本。每個節點託管一個或多個分片，並充當協調器將操作委託給正確的分片。

再平衡和路由是自動完成的。相關數據通常存儲在同一個索引中，該索引由一個或多個主分片和零個或多個復制分片組成。一旦創建了索引，就不能更改主分片的數量。

⑥ es可以一天存百萬條數據么

es不可以一天存百萬條數據。es一天最大的存儲量是90萬條數據，所以es不可以一天存百萬條數據。es全稱ElasticSearch,是一個基於Lucene的搜索伺服器。

⑦ elastic索引最多可以創建多少欄位

elastic索引最多可以創建10000個欄位，默認1000個。當分片被占滿後，創建新索引失敗。每個Elasticsearch碎片都是一個Lucene索引。一個Lucene索引中可以包含的文檔最多。設置ignore_above後，超過給定長度後的數據將不被索引，無法通過term精確匹配檢索返回結果。索引是一種單獨的、物理的對資料庫表中一列或多列的值進行排序的一種存儲結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。索引針對表而建立，每個索引頁面中的行都會含有邏輯指針，以便加速檢索物理數據。

⑧ ElasticSearch數據存儲內容

很多使用Elasticsearch的同學會關心數據存儲在ES中的存儲容量，會有這樣的疑問：xxTB的數據入到ES會使用多少存儲空間。這個問題其實很難直接回答的，只有數據寫入ES後，才能觀察到實際的存儲空間。比如同樣是1TB的數據，寫入ES的存儲空間可能差距會非常大，可能小到只有300~400GB，也可能多到6-7TB，為什麼會造成這么大的差距呢？究其原因，我們來探究下Elasticsearch中的數據是如何存儲。文章中我以Elasticsearch 2.3版本為示例，對應的lucene版本是5.5，Elasticsearch現在已經來到了6.5版本，數字類型、列存等存儲結構有些變化，但基本的概念變化不多，文章中的內容依然適用。

Elasticsearch對外提供的是index的概念，可以類比為DB，用戶查詢是在index上完成的，每個index由若干個shard組成，以此來達到分布式可擴展的能力。比如下圖是一個由10個shard組成的index。

shard是Elasticsearch數據存儲的最小單位，index的存儲容量為所有shard的存儲容量之和。Elasticsearch集群的存儲容量則為所有index存儲容量之和。

一個shard就對應了一個lucene的library。對於一個shard，Elasticsearch增加了translog的功能，類似於HBase WAL，是數據寫入過程中的中間數據，其餘的數據都在lucene庫中管理的。

所以Elasticsearch索引使用的存儲內容主要取決於lucene中的數據存儲。

下面我們主要看下lucene的文件內容，在了解lucene文件內容前，大家先了解些lucene的基本概念。

lucene包的文件是由很多segment文件組成的，segments_xxx文件記錄了lucene包下面的segment文件數量。每個segment會包含如下的文件。

下面我們以真實的數據作為示例，看看lucene中各類型數據的容量佔比。

寫100w數據，有一個uuid欄位，寫入的是長度為36位的uuid，字元串總為3600w位元組，約為35M。

數據使用一個shard，不帶副本，使用默認的壓縮演算法，寫入完成後merge成一個segment方便觀察。

使用線上默認的配置，uuid存為不分詞的字元串類型。創建如下索引：

首先寫入100w不同的uuid，使用磁碟容量細節如下：

可以看到正排數據、倒排索引數據，列存數據容量佔比幾乎相同，正排數據和倒排數據還會存儲Elasticsearch的唯一id欄位，所以容量會比列存多一些。

35M的uuid存入Elasticsearch後，數據膨脹了3倍，達到了122.7mb。Elasticsearch竟然這么消耗資源，不要著急下結論，接下來看另一個測試結果。

我們寫入100w一樣的uuid，然後看看Elasticsearch使用的容量。

這回35M的數據Elasticsearch容量只有13.2mb，其中還有主要的佔比還是Elasticsearch的唯一id，100w的uuid幾乎不佔存儲容積。

所以在Elasticsearch中建立索引的欄位如果基數越大(count distinct)，越佔用磁碟空間。

我們再看看存100w個不一樣的整型會是如何。

從結果可以看到，100w整型數據，Elasticsearch的存儲開銷為13.6mb。如果以int型計算100w數據的長度的話，為400w位元組，大概是3.8mb數據。忽略Elasticsearch唯一id欄位的影響，Elasticsearch實際存儲容量跟整型數據長度差不多。

我們再看一下開啟最佳壓縮參數對存儲空間的影響：

結果中可以發現，只有正排數據會啟動壓縮，壓縮能力確實強勁，不考慮唯一id欄位，存儲容量大概壓縮到接近50%。

我們還做了一些實驗，Elasticsearch默認是開啟_all參數的，_all可以讓用戶傳入的整體json數據作為全文檢索的欄位，可以更方便的檢索，但在現實場景中已經使用的不多，相反會增加很多存儲容量的開銷，可以看下開啟_all的磁碟空間使用情況：

開啟_all比不開啟多了40mb的存儲空間，多的數據都在倒排索引上，大約會增加30%多的存儲開銷。所以線上都直接禁用。

然後我還做了其他幾個嘗試，為了驗證存儲容量是否和數據量成正比，寫入1000w數據的uuid，發現存儲容量基本為100w數據的10倍。我還驗證了數據長度是否和數據量成正比，發現把uuid增長2倍、4倍，存儲容量也響應的增加了2倍和4倍。在此就不一一列出數據了。

文件名為：segments_xxx

該文件為lucene數據文件的元信息文件，記錄所有segment的元數據信息。

該文件主要記錄了目前有多少segment，每個segment有一些基本信息，更新這些信息定位到每個segment的元信息文件。

lucene元信息文件還支持記錄userData，Elasticsearch可以在此記錄translog的一些相關信息。

文件後綴：.si

每個segment都有一個.si文件，記錄了該segment的元信息。

segment元信息文件中記錄了segment的文檔數量，segment對應的文件列表等信息。

文件後綴：.fnm

該文件存儲了fields的基本信息。

fields信息中包括field的數量，field的類型，以及IndexOpetions，包括是否存儲、是否索引，是否分詞，是否需要列存等等。

文件後綴：.fdx, .fdt

索引文件為.fdx，數據文件為.fdt，數據存儲文件功能為根據自動的文檔id，得到文檔的內容，搜索引擎的術語習慣稱之為正排數據，即doc_id -> content，es的_source數據就存在這

索引文件記錄了快速定位文檔數據的索引信息，數據文件記錄了所有文檔id的具體內容。

索引後綴：.tip,.tim

倒排索引也包含索引文件和數據文件，.tip為索引文件，.tim為數據文件，索引文件包含了每個欄位的索引元信息，數據文件有具體的索引內容。

5.5.0版本的倒排索引實現為FST tree，FST tree的最大優勢就是內存空間佔用非常低 ，具體可以參看下這篇文章： http://www.cnblogs.com/bonelee/p/6226185.html

http://examples.mikemccandless.com/fst.py?terms=&cmd=Build+it 為FST圖實例，可以根據輸入的數據構造出FST圖

生成的 FST 圖為:

文件後綴：.doc, .pos, .pay

.doc保存了每個term的doc id列表和term在doc中的詞頻

全文索引的欄位，會有.pos文件，保存了term在doc中的位置

全文索引的欄位，使用了一些像payloads的高級特性才會有.pay文件，保存了term在doc中的一些高級特性

文件後綴：.dvm, .dvd

索引文件為.dvm，數據文件為.dvd。

lucene實現的docvalues有如下類型：

其中SORTED_SET 的 SORTED_SINGLE_VALUED類型包括了兩類數據 ： binary + numeric， binary是按ord排序的term的列表，numeric是doc到ord的映射。