[elasticsearch]從 Elasticsearch index 與基本概念談起

從 Elasticsearch index 與基本概念談起

"index" 索引 這個詞常常在談論Elasticsearch 的時候被誤用太多，從核心概念談起，很多表現出來的行為就不言自明了。

index (索引)

"index" 在 Elasticsearch 中可以把它類比成關聯式資料庫的資料庫(database)概念。index即是存放與索引資料的一個單位。事實上，在底層中 index 是一個邏輯的namespace，它指向若干個shards(分片)。

"to index" 也意味著，使用Elasticsearch索引你的資料。你的資料會為了要搜尋而索引且存放起來。

inverted index (倒排索引)

倒排索引是一個在Lucene 底層為了加快數據搜索的一種資料結構。

透過處理數據的過程，萃取出獨特的 terms 或是 tokens ，然後記下來 terms 包含了哪些documents。

shard

shard 是一個 Lucene 的實例，也就是說，shard才是實際是上，在Lucene操作的"index"。在Elasticsearch中，一個index可以由若干個shard組成。

"primary shard" 是主要的一個部分， "replica shard" 是 "primary shard"的副本。

"replica shard" 主要的作用就是當 primary shard 失效時的 failover ，還有可以增加讀取的throughpu。

segment (段)

每個shard通常都包還著多個segment，每個segment都是一個"倒排索引"。

當我們在索引文件時，elasticsearch會先把那些資料收集到記憶體當中(當然其中有 trasation log來確保資料不會遺失)，Elasticsearch 預設會在每秒寫一個新的segment到硬碟中，必且刷新(refresh)它，讓使用者可以搜尋到資料。

這也就是，Elasticsearch一直被標榜的Near Realtime search engine。

雖然，這些新的資料已經可以被搜尋，但是並還沒有fsync'ed 到硬碟。 每隔一段時間，Elasticsearch會flush這些資料，也就是意味 fsyncing 這些 segments(也就是說 這些 document已經commited )在此同時也會把 transation log 清掉，因為新的數據已經被寫到硬碟。

一個index包含了越多的segments也就意味著需要更多的search時間。所以，Elasticsearch會在背景中，把大小相似的segment 合併一個更大的segment。(這個過程稱作merge,elasticsearch 預設使用 tier 的 merge policy。) 一旦新的segment產生了，舊的segment就會被棄用。這個 merge的過程中，若是有很多塊相似大小的segment，就會從比較大塊的開始進行merge。

segment具有"不可變更"(immutable)的特性。當index內的documents被更新時，事實上，它只是先標記把舊的document標記成刪除，然後再索引新的document。Merge 進行時，就會順便把這些舊的已經刪除的document實際刪除。(不合併在新的segment內)