Elasticsearch 儲存深入詳解
在本文中，我們將研究Elasticsearch的各個部分寫入資料目錄的檔案。我們將檢視節點，索引和分片級檔案，並簡要說明其內容，以便了解Elasticsearch寫入磁碟的資料。
1、從Elasticsearch路徑說起
Elasticsearch配置了多個路徑：
path.home：執行Elasticsearch程序的使用者的主目錄。預設為Java系統屬性user.dir，它是程序所有者的預設主目錄。
path.conf：包含配置檔案的目錄。這通常通過設定Java系統屬性es.config來設定，因為在找到配置檔案之前它必然會被解析。
path.plugins：子資料夾為Elasticsearch外掛的目錄。這裡支援Sym-links，當從同一個可執行檔案執行多個Elasticsearch例項時，可以使用它來有選擇地啟用/禁用某個Elasticsearch例項的一組外掛。
path.logs：儲存生成的日誌的位置。如果其中一個卷的磁碟空間不足，則將它放在與資料目錄不同的捲上可能是有意義的。
path.data：包含Elasticsearch儲存的資料的資料夾的路徑。
在本文中，我們將仔細研究資料目錄（path.data）的實際內容，並嘗試瞭解所有檔案的用途。
2、檔案從哪裡來？
由於Elasticsearch使用Lucene來處理分片級別的索引和查詢，因此資料目錄中的檔案由Elasticsearch和Lucene寫入。
兩者的職責都非常明確：
-
Lucene負責寫和維護Lucene索引檔案，
-
而Elasticsearch在Lucene之上寫與功能相關的元資料，例如欄位對映，索引設定和其他叢集元資料。 終端使用者和支援功能
-
在低階Lucene中不存在，由Elasticsearch提供。
在深入研究並最終找到Lucene索引檔案之前，讓我們看看Elasticsearch編寫的外部級別資料。
3、節點資料
只需從空資料目錄啟動Elasticsearch即可生成以下目錄樹：
-
node.lock檔案用於確保一次只能從一個數據目錄讀取/寫入一個Elasticsearch相關安裝資訊。
-
有趣的是global-0.st檔案。 global-字首表示這是一個全域性狀態檔案，
-
而.st擴充套件名錶示這是一個包含元資料的狀態檔案。您可能已經猜到，此二進位制檔案包含有關您的叢集的全域性元資料，字首後的數字表示叢集元資料版本，遵循跟隨您的叢集嚴格增加的版本控制方案。
注意：雖然在緊急情況下使用十六進位制編輯器在技術上可以編輯這些檔案，但強烈建議不要這樣做，因為它很快就會導致資料丟失。
4、索引資料
讓我們建立一個分片索引並檢視Elasticsearch更改的檔案。
我們看到已經建立了與索引名稱對應的新目錄。 此目錄有兩個子資料夾：_state和0.
-
前者 state包含所謂的索引狀態檔案（indices / {index-name} / state / state- {version} .st），
其中包含有關索引的元資料，例如 它的建立時間戳。 它還包含唯一識別符號以及索引的設定和對映。 -
後者0包含與索引的第一個（也是唯一的）分片相關的資料（分片0）。
接下來，我們將仔細研究一下。
5、分片資料
分片資料目錄包含分片的狀態檔案，其中包括版本控制以及有關分片是主分片還是副本的資訊。
在早期的Elasticsearch版本中，還在分片資料目錄中找到了單獨的{shard_id} / index / _checksums-檔案（和.cks-files）。在當前版本中，這些校驗和現在可以在Lucene檔案的頁尾中找到，因為Lucene已經為其所有索引檔案添加了端到端校驗和。
{shard_id} / index 目錄包含Lucene擁有的檔案。 Elasticsearch通常不直接寫入此資料夾（除了早期版本中的舊校驗和實現）。這些目錄中的檔案構成了任何Elasticsearch資料目錄的大小。
在我們進入Lucene的世界之前，我們將看一下Elasticsearch 事務日誌，這在每個分片translog目錄中的字首translog-中存在。Translog日誌對於Elasticsearch的功能和效能非常重要，因此我們將在下一節中更詳細地解釋它的用法。
6、每個分片的 事務日誌（Transaction Log）
Elasticsearch事務日誌確保可以安全地將資料索引到Elasticsearch，而無需為每個文件執行低階Lucene提交。提交Lucene索引會在Lucene級別建立一個新的segment，即執行 fsync（） ，會導致大量磁碟I / O影響效能。
為了接受索引文件並使其可搜尋而不需要完整的Lucene提交，Elasticsearch將其新增到Lucene IndexWriter並將其附加到事務日誌中。在每個refresh_interval之後，它將在Lucene索引上呼叫reopen（），這將使資料可以在不需要提交的情況下進行搜尋。這是Lucene Near Real Time API的一部分。當IndexWriter最終由於自動重新整理事務日誌或由於顯式重新整理操作而提交時，先前的事務日誌將被丟棄並且新的事務日誌將取代它。
如果需要恢復，將首先恢復在Lucene中寫入磁碟的segments，然後重放事務日誌，以防止丟失尚未完全提交到磁碟的操作。
7、Lucene索引檔案
Lucene在記錄Lucene索引目錄中的檔案方面做得很好，為了方便起見，這裡重現了這些檔案（Lucene中的連結文件也詳細介紹了這些檔案從Lucene 2.1返回後所經歷的變化，所以檢查一下 出來）：
通常，您還會在Lucene索引目錄中看到一個segments.gen檔案，該檔案是一個幫助檔案，其中包含有關當前/最新segments_N檔案的資訊，並用於可能無法通過目錄列表返回足夠資訊的檔案系統，以確定 最新一代段檔案。在較舊的Lucene版本中，您還可以找到帶有.del字尾的檔案。 它們與Live Documents（.liv）檔案的用途相同 - 換句話說，這些是刪除列表。
8、修復有問題的碎片
由於Elasticsearch分片包含Lucene索引，我們可以使用Lucene的強大的CheckIndex工具（http://t.cn/Rs0gKjCl），這使我們能夠掃描和修復有問題的段，通常只需要很少的資料丟失。 我們通常會建議Elasticsearch使用者簡單地重新索引資料（re-index），但如果由於某種原因這是不可能的並且資料非常重要，那麼這是一條可以採取的路線，即使它需要相當多的手工工作和時間， 取決於碎片的數量和它們的大小。
Lucene CheckIndex工具包含在預設的Elasticsearch發行版中，無需額外下載。
1# change this to reflect your shard path, the format is
2# {path.data}/{cluster_name}/nodes/{node_id}/indices/{index_name}/{shard_id}/index/
3
4$ export SHARD_PATH=data/elasticsearch/nodes/0/indices/foo/0/index/
5$ java -cp lib/elasticsearch-*.jar:lib/*:lib/sigar/* -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex $SHARD_PATH
如果CheckIndex檢測到問題並且其建議修復它看起來很合理，您可以通過新增-fix命令列引數告訴CheckIndex應用修復程式。
9、儲存快照
您可能想知道所有這些檔案如何轉換為快照儲存庫使用的儲存。 不用再想了：拿這個叢集，將它作為我的快照快照到基於檔案系統的閘道器，並檢查儲存庫中的檔案，我們會找到這些檔案（為簡潔起見省略了一些檔案）：
在根目錄下，我們有一個索引檔案，其中包含有關此儲存庫中所有快照的資訊，每個快照都有一個關聯的快照和元資料檔案。
根目錄下的快照檔案包含有關快照狀態，快照包含的索引等資訊。 根目錄下的元資料檔案包含快照時的群集元資料。
當設定compress：true時，使用LZF壓縮元資料和快照檔案，LZF專注於壓縮和解壓縮速度，這使其非常適合Elasticsearch。
資料儲存有標題：ZV + 1位元組，指示資料是否被壓縮。 在標題之後，格式上將存在一個或多個壓縮的64K塊：2位元組塊長度+2位元組未壓縮大小+壓縮資料。 使用此資訊，您可以使用任何相容LibLZF的解壓縮程式。
在索引級別，還有另一個檔案indices / {index_name} / snapshot- {snapshot_name}，其中包含索引元資料，例如快照時索引的設定和對映。
在分片級別，您將找到兩種檔案：重新命名的Lucene索引檔案和分片快照檔案：indices / {index_name} / {shard_id} / snapshot- {snapshot_name}。 此檔案包含有關快照中使用的分片目錄中的哪些檔案的資訊，以及從快照中的邏輯檔名到具體檔名的對映，這些檔名在還原時應儲存為磁碟。 它還包含可用於檢測和防止資料損壞的所有相關檔案的校驗和，Lucene版本控制和大小資訊。 .
您可能想知道為什麼這些檔案已被重新命名而不是僅保留其原始檔名，這可能更容易直接在磁碟上使用。
原因很簡單：可以在再次快照之前對索引進行快照，刪除並重新建立它。 在這種情況下，幾個檔案最終會有相同的名稱，但內容不同。
10、小結
-
在本文中，我們查看了各種級別的Elasticsearch寫入資料目錄的檔案：節點，索引和分片級別。
我們已經看到了Lucene索引儲存在磁碟上的位置，並簡要描述瞭如何使用Lucene CheckIndex工具來驗證和修復有問題的碎片。 -
希望您不需要對Elasticsearch資料目錄的內容執行任何操作，但是瞭解您最喜歡的基於搜尋的資料庫將哪種資料寫入檔案系統總是有幫助的！
-
不需要完整記住每個檔案的確切含義，關鍵的時候知道去哪裡更快的查詢最重要。
11、補充認知
一份資料寫入es會產生多份資料用於不同查詢方式，會比原資料佔用更多磁碟空間。而索引setting裡"codec": "best_compression"是針對_source進行壓縮的，壓縮演算法是deflate壓縮比為6。
對照上面的lucene表進行如下的關聯。
-
儲存 原文_source 的檔案.fdt .fdm .fdx;
-
儲存 倒排索引 的檔案.tim .tip .doc;
-
用於 聚合排序 的列存檔案.dvd .dvm;
-
全文檢索檔案. pos .pay .nvd .nvm等。
-
載入到記憶體 中的檔案有.fdx .tip .dvm，
其中.tip佔用記憶體最大，而.fdt . tim .dvd檔案佔用磁碟最大，例如
11.5M _ap9_1w3.liv 25.0G _ap9.fdt 31.9M _ap9.fdx 444K _ap9.fnm 53.1G _ap9_Lucene50_0.doc 64.2G _ap9_Lucene50_0.tim 781M _ap9_Lucene50_0.tip 87.7G _ap9_Lucene54_0.dvd 920K _ap9_Lucene54_0.dvm 104.0K _ap9.si
另外segment較小時檔案內容是儲存在.cfs檔案中，.cfe檔案儲存Lucene各檔案在.cfs檔案的位置資訊，這是為了減少Lucene開啟的檔案控制代碼數。
es節點上shard過多了會導致記憶體不夠，可以對靜態的索引進行
POST {indexName}/_forcemerge?max_num_segments=1
翻譯參考：http://t.cn/RsOPjTS
補充參考：http://t.cn/RsWQAiV
推薦閱讀：
Elasticsearch實戰 | 必要的時候，還得空間換時間!
