【原】Elasticsearch存儲(chǔ)深入詳解

在本文中，我們將研究Elasticsearch的各個(gè)部分寫入數(shù)據(jù)目錄的文件。我們將查看節(jié)點(diǎn)，索引和分片級文件，并簡要說明其內(nèi)容，以便了解Elasticsearch寫入磁盤的數(shù)據(jù)。

1、從Elasticsearch路徑說起

Elasticsearch配置了多個(gè)路徑：

path.home：運(yùn)行Elasticsearch進(jìn)程的用戶的主目錄。默認(rèn)為Java系統(tǒng)屬性user.dir，它是進(jìn)程所有者的默認(rèn)主目錄。

path.conf：包含配置文件的目錄。這通常通過設(shè)置Java系統(tǒng)屬性es.config來設(shè)置，因?yàn)樵谡业脚渲梦募八厝粫?huì)被解析。

path.plugins：子文件夾為Elasticsearch插件的目錄。這里支持Sym-links，當(dāng)從同一個(gè)可執(zhí)行文件運(yùn)行多個(gè)Elasticsearch實(shí)例時(shí)，可以使用它來有選擇地啟用/禁用某個(gè)Elasticsearch實(shí)例的一組插件。

path.logs：存儲(chǔ)生成的日志的位置。如果其中一個(gè)卷的磁盤空間不足，則將它放在與數(shù)據(jù)目錄不同的卷上可能是有意義的。
path.data：包含Elasticsearch存儲(chǔ)的數(shù)據(jù)的文件夾的路徑。

在本文中，我們將仔細(xì)研究數(shù)據(jù)目錄（path.data）的實(shí)際內(nèi)容，并嘗試了解所有文件的用途。

2、文件從哪里來？

由于Elasticsearch使用Lucene來處理分片級別的索引和查詢，因此數(shù)據(jù)目錄中的文件由Elasticsearch和Lucene寫入。
兩者的職責(zé)都非常明確：

• Lucene負(fù)責(zé)寫和維護(hù)Lucene索引文件，

• 而Elasticsearch在Lucene之上寫與功能相關(guān)的元數(shù)據(jù)，例如字段映射，索引設(shè)置和其他集群元數(shù)據(jù)。 最終用戶和支持功能

• 在低級Lucene中不存在，由Elasticsearch提供。

在深入研究并最終找到Lucene索引文件之前，讓我們看看Elasticsearch編寫的外部級別數(shù)據(jù)。

3、節(jié)點(diǎn)數(shù)據(jù)

只需從空數(shù)據(jù)目錄啟動(dòng)Elasticsearch即可生成以下目錄樹：

• node.lock文件用于確保一次只能從一個(gè)數(shù)據(jù)目錄讀取/寫入一個(gè)Elasticsearch相關(guān)安裝信息。

• 有趣的是global-0.st文件。 global-前綴表示這是一個(gè)全局狀態(tài)文件，

• 而.st擴(kuò)展名表示這是一個(gè)包含元數(shù)據(jù)的狀態(tài)文件。您可能已經(jīng)猜到，此二進(jìn)制文件包含有關(guān)您的集群的全局元數(shù)據(jù)，前綴后的數(shù)字表示集群元數(shù)據(jù)版本，遵循跟隨您的集群嚴(yán)格增加的版本控制方案。

注意：雖然在緊急情況下使用十六進(jìn)制編輯器在技術(shù)上可以編輯這些文件，但強(qiáng)烈建議不要這樣做，因?yàn)樗芸炀蜁?huì)導(dǎo)致數(shù)據(jù)丟失。

4、索引數(shù)據(jù)

讓我們創(chuàng)建一個(gè)分片索引并查看Elasticsearch更改的文件。

我們看到已經(jīng)創(chuàng)建了與索引名稱對應(yīng)的新目錄。 此目錄有兩個(gè)子文件夾：_state和0.

1. 前者state包含所謂的索引狀態(tài)文件（indices / {index-name} / state / state- {version} .st），
   其中包含有關(guān)索引的元數(shù)據(jù)，例如 它的創(chuàng)建時(shí)間戳。 它還包含唯一標(biāo)識(shí)符以及索引的設(shè)置和映射。

2. 后者0包含與索引的第一個(gè)（也是唯一的）分片相關(guān)的數(shù)據(jù)（分片0）。

接下來，我們將仔細(xì)研究一下。

5、分片數(shù)據(jù)

分片數(shù)據(jù)目錄包含分片的狀態(tài)文件，其中包括版本控制以及有關(guān)分片是主分片還是副本的信息。

在早期的Elasticsearch版本中，還在分片數(shù)據(jù)目錄中找到了單獨(dú)的{shard_id} / index / _checksums-文件（和.cks-files）。在當(dāng)前版本中，這些校驗(yàn)和現(xiàn)在可以在Lucene文件的頁腳中找到，因?yàn)長ucene已經(jīng)為其所有索引文件添加了端到端校驗(yàn)和。

{shard_id} / index目錄包含Lucene擁有的文件。 Elasticsearch通常不直接寫入此文件夾（除了早期版本中的舊校驗(yàn)和實(shí)現(xiàn)）。這些目錄中的文件構(gòu)成了任何Elasticsearch數(shù)據(jù)目錄的大小。

在我們進(jìn)入Lucene的世界之前，我們將看一下Elasticsearch 事務(wù)日志，這在每個(gè)分片translog目錄中的前綴translog-中存在。Translog日志對于Elasticsearch的功能和性能非常重要，因此我們將在下一節(jié)中更詳細(xì)地解釋它的用法。

6、每個(gè)分片的 事務(wù)日志（Transaction Log）

Elasticsearch事務(wù)日志確?？梢园踩貙?shù)據(jù)索引到Elasticsearch，而無需為每個(gè)文檔執(zhí)行低級Lucene提交。提交Lucene索引會(huì)在Lucene級別創(chuàng)建一個(gè)新的segment，即執(zhí)行fsync（），會(huì)導(dǎo)致大量磁盤I / O影響性能。

為了接受索引文檔并使其可搜索而不需要完整的Lucene提交，Elasticsearch將其添加到Lucene IndexWriter并將其附加到事務(wù)日志中。在每個(gè)refresh_interval之后，它將在Lucene索引上調(diào)用reopen（），這將使數(shù)據(jù)可以在不需要提交的情況下進(jìn)行搜索。這是Lucene Near Real Time API的一部分。當(dāng)IndexWriter最終由于自動(dòng)刷新事務(wù)日志或由于顯式刷新操作而提交時(shí)，先前的事務(wù)日志將被丟棄并且新的事務(wù)日志將取代它。

如果需要恢復(fù)，將首先恢復(fù)在Lucene中寫入磁盤的segments，然后重放事務(wù)日志，以防止丟失尚未完全提交到磁盤的操作。

7、Lucene索引文件

Lucene在記錄Lucene索引目錄中的文件方面做得很好，為了方便起見，這里重現(xiàn)了這些文件（Lucene中的鏈接文檔也詳細(xì)介紹了這些文件從Lucene 2.1返回后所經(jīng)歷的變化，所以檢查一下 出來）：

通常，您還會(huì)在Lucene索引目錄中看到一個(gè)segments.gen文件，該文件是一個(gè)幫助文件，其中包含有關(guān)當(dāng)前/最新segments_N文件的信息，并用于可能無法通過目錄列表返回足夠信息的文件系統(tǒng)，以確定 最新一代段文件。在較舊的Lucene版本中，您還可以找到帶有.del后綴的文件。 它們與Live Documents（.liv）文件的用途相同 - 換句話說，這些是刪除列表。

8、修復(fù)有問題的碎片

由于Elasticsearch分片包含Lucene索引，我們可以使用Lucene的強(qiáng)大的CheckIndex工具（http:///Rs0gKjCl），這使我們能夠掃描和修復(fù)有問題的段，通常只需要很少的數(shù)據(jù)丟失。 我們通常會(huì)建議Elasticsearch用戶簡單地重新索引數(shù)據(jù)（re-index），但如果由于某種原因這是不可能的并且數(shù)據(jù)非常重要，那么這是一條可以采取的路線，即使它需要相當(dāng)多的手工工作和時(shí)間， 取決于碎片的數(shù)量和它們的大小。

Lucene CheckIndex工具包含在默認(rèn)的Elasticsearch發(fā)行版中，無需額外下載。

如果CheckIndex檢測到問題并且其建議修復(fù)它看起來很合理，您可以通過添加-fix命令行參數(shù)告訴CheckIndex應(yīng)用修復(fù)程序。

9、存儲(chǔ)快照

您可能想知道所有這些文件如何轉(zhuǎn)換為快照存儲(chǔ)庫使用的存儲(chǔ)。 不用再想了：拿這個(gè)集群，將它作為我的快照快照到基于文件系統(tǒng)的網(wǎng)關(guān)，并檢查存儲(chǔ)庫中的文件，我們會(huì)找到這些文件（為簡潔起見省略了一些文件）：

在根目錄下，我們有一個(gè)索引文件，其中包含有關(guān)此存儲(chǔ)庫中所有快照的信息，每個(gè)快照都有一個(gè)關(guān)聯(lián)的快照和元數(shù)據(jù)文件。 

根目錄下的快照文件包含有關(guān)快照狀態(tài)，快照包含的索引等信息。 根目錄下的元數(shù)據(jù)文件包含快照時(shí)的群集元數(shù)據(jù)。

當(dāng)設(shè)置compress：true時(shí)，使用LZF壓縮元數(shù)據(jù)和快照文件，LZF專注于壓縮和解壓縮速度，這使其非常適合Elasticsearch。

數(shù)據(jù)存儲(chǔ)有標(biāo)題：ZV + 1字節(jié)，指示數(shù)據(jù)是否被壓縮。 在標(biāo)題之后，格式上將存在一個(gè)或多個(gè)壓縮的64K塊：2字節(jié)塊長度+2字節(jié)未壓縮大小+壓縮數(shù)據(jù)。  使用此信息，您可以使用任何兼容LibLZF的解壓縮程序。

在索引級別，還有另一個(gè)文件indices / {index_name} / snapshot- {snapshot_name}，其中包含索引元數(shù)據(jù)，例如快照時(shí)索引的設(shè)置和映射。

在分片級別，您將找到兩種文件：重命名的Lucene索引文件和分片快照文件：indices / {index_name} / {shard_id} / snapshot- {snapshot_name}。 此文件包含有關(guān)快照中使用的分片目錄中的哪些文件的信息，以及從快照中的邏輯文件名到具體文件名的映射，這些文件名在還原時(shí)應(yīng)存儲(chǔ)為磁盤。 它還包含可用于檢測和防止數(shù)據(jù)損壞的所有相關(guān)文件的校驗(yàn)和，Lucene版本控制和大小信息。.

您可能想知道為什么這些文件已被重命名而不是僅保留其原始文件名，這可能更容易直接在磁盤上使用。

原因很簡單：可以在再次快照之前對索引進(jìn)行快照，刪除并重新創(chuàng)建它。 在這種情況下，幾個(gè)文件最終會(huì)有相同的名稱，但內(nèi)容不同。

10、小結(jié)

1. 在本文中，我們查看了各種級別的Elasticsearch寫入數(shù)據(jù)目錄的文件：節(jié)點(diǎn)，索引和分片級別。
   我們已經(jīng)看到了Lucene索引存儲(chǔ)在磁盤上的位置，并簡要描述了如何使用Lucene CheckIndex工具來驗(yàn)證和修復(fù)有問題的碎片。

2. 希望您不需要對Elasticsearch數(shù)據(jù)目錄的內(nèi)容執(zhí)行任何操作，但是了解您最喜歡的基于搜索的數(shù)據(jù)庫將哪種數(shù)據(jù)寫入文件系統(tǒng)總是有幫助的！

3. 不需要完整記住每個(gè)文件的確切含義，關(guān)鍵的時(shí)候知道去哪里更快的查找最重要。

11、補(bǔ)充認(rèn)知

一份數(shù)據(jù)寫入es會(huì)產(chǎn)生多份數(shù)據(jù)用于不同查詢方式，會(huì)比原數(shù)據(jù)占用更多磁盤空間。而索引setting里"codec": "best_compression"是針對_source進(jìn)行壓縮的，壓縮算法是deflate壓縮比為6。

對照上面的lucene表進(jìn)行如下的關(guān)聯(lián)。

• 存儲(chǔ)原文_source的文件.fdt .fdm .fdx;

• 存儲(chǔ)倒排索引的文件.tim .tip .doc;

• 用于聚合排序的列存文件.dvd .dvm;

• 全文檢索文件.pos .pay .nvd .nvm等。

• 加載到內(nèi)存中的文件有.fdx .tip .dvm，

其中.tip占用內(nèi)存最大，而.fdt . tim .dvd文件占用磁盤最大，例如

另外segment較小時(shí)文件內(nèi)容是保存在.cfs文件中，.cfe文件保存Lucene各文件在.cfs文件的位置信息，這是為了減少Lucene打開的文件句柄數(shù)。

es節(jié)點(diǎn)上shard過多了會(huì)導(dǎo)致內(nèi)存不夠，可以對靜態(tài)的索引進(jìn)行

POST {indexName}/_forcemerge?max_num_segments=1

翻譯參考：http:///RsOPjTS
補(bǔ)充參考：http:///RsWQAiV