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發行版中，無需額外下載下傳。
# change this to reflect your shard path, the format is
# {path.data}/{cluster_name}/nodes/{node_id}/indices/{index_name}/{shard_id}/index/
$ export SHARD_PATH=data/elasticsearch/nodes/0/indices/foo/0/index/
$ java -cp lib/elasticsearch-*.jar:lib/*:lib/sigar/* -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex $SHARD_PATH
1
2
3
4
5
如果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檔案占用磁盤最大，例如
1.5M _ap9_1w3.liv
5.0G _ap9.fdt
1.9M _ap9.fdx
44K _ap9.fnm
3.1G _ap9_Lucene50_0.doc
4.2G _ap9_Lucene50_0.tim
81M _ap9_Lucene50_0.tip
7.7G _ap9_Lucene54_0.dvd
20K _ap9_Lucene54_0.dvm
4.0K _ap9.si
6
7
8
9
10
另外segment較小時檔案内容是儲存在.cfs檔案中，.cfe檔案儲存Lucene各檔案在.cfs檔案的位置資訊，這是為了減少Lucene打開的檔案句柄數。
es節點上shard過多了會導緻記憶體不夠，可以對靜态的索引進行POST {indexName}/_forcemerge?max_num_segments=1
翻譯參考：
http://t.cn/RsOPjTS補充參考：
https://elasticsearch.cn/question/5173（感謝JackGe）