文檔地址：

https://www.elastic.co/guide/en/elasticsearch/reference/2.4/doc-values.html

https://www.elastic.co/guide/en/elasticsearch/guide/2.x/docvalues-intro.html

https://www.elastic.co/guide/en/elasticsearch/guide/2.x/docvalues.html

https://www.elastic.co/guide/en/elasticsearch/guide/2.x/_deep_dive_on_doc_values.html#_deep_dive_on_doc_values

doc_values介紹

doc values是一個(gè)我們?cè)偃貜?fù)的重要話(huà)題了，你是否意識(shí)到一些東西呢？

• 搜索時(shí)，我們需要一個(gè)“詞”到“文檔”列表的映射
• 排序時(shí)，我們需要一個(gè)“文檔”到“詞“列表的映射，換句話(huà)說(shuō)，我們需要一個(gè)在倒排索引的基礎(chǔ)上建立的“正排索引”

這里的“正排索引”結(jié)構(gòu)通常在其他系統(tǒng)中（如關(guān)系型數(shù)據(jù)庫(kù)）被稱(chēng)為“列式存儲(chǔ)”。本質(zhì)上，它是在數(shù)據(jù)字段的一列上存儲(chǔ)所有value，這種結(jié)構(gòu)在某些操作上會(huì)表現(xiàn)得很高效，比如排序。
在ES里這種“列式存儲(chǔ)”就是我們熟悉的“doc values”，默認(rèn)情況下它是被啟用的，doc values在index-time（索引期）被創(chuàng)建：當(dāng)一個(gè)字段被索引時(shí)，ES會(huì)把“詞”加入到倒排索引中，同時(shí)把這些詞也加入到面向“列式存儲(chǔ)”的doc values中（存儲(chǔ)在硬盤(pán)上）。 doc values通常被應(yīng)用在以下幾個(gè)方面：

• 基于一個(gè)字段排序
• 基于一個(gè)字段聚合
• 執(zhí)行某些filter上（如：geolocation filter）
• 在script（腳本）中引用了一個(gè)或多個(gè)字段

由于doc values在索引期被序列化到硬盤(pán)上，我們可以利用操作系統(tǒng)去快速的訪(fǎng)問(wèn)它們，關(guān)于doc values在磁盤(pán)上是如何被管理的，后面會(huì)講到。

doc_values

大多數(shù)的字段默認(rèn)情況下都會(huì)被索引，這使得他們可以被搜索到，倒排索引允許一個(gè)查詢(xún)基于一個(gè)詞表排序，也可以快速訪(fǎng)問(wèn)包含某個(gè)詞的文檔列表。 排序、聚合，和在腳本中訪(fǎng)問(wèn)一些字段值時(shí)都需要另一種不同的訪(fǎng)問(wèn)方式，因?yàn)榈古潘饕恢С诌@種訪(fǎng)問(wèn)，所以我們需要一種結(jié)構(gòu)能查詢(xún)到文檔到詞的映射。 doc values是在索引期創(chuàng)建基于磁盤(pán)的數(shù)據(jù)結(jié)構(gòu)，這種結(jié)構(gòu)使得上述訪(fǎng)問(wèn)成為可能。doc values支持絕大部分字段類(lèi)型，除了“analyzed”類(lèi)型的string字段。 所有的字段都默認(rèn)支持doc values，如果你確定你不需要在某個(gè)字段上排序或者聚合或者在腳本中訪(fǎng)問(wèn)，你可以disable掉： PUT my_index {"mappings": {"my_type": {"properties": {"status_code": { "type": "string","index": "not_analyzed"},"session_id": { "type": "string","index": "not_analyzed","doc_values": false}}}} }

status_code字段默認(rèn)開(kāi)啟doc_values

session_id字段禁用了doc_values，雖然被禁用但是還是可以被查詢(xún)

TIP：doc_values可以在同一個(gè)索引的同名字段上設(shè)置不同值，它也可以基于一個(gè)已存在的字段使用put mapping api來(lái)禁用它。
看如下的倒排索引結(jié)構(gòu) Term Doc_1 Doc_2 Doc_3 ------------------------------------ brown | X | X | dog | X | | X dogs | | X | X fox | X | | X foxes | | X | in | | X | jumped | X | | X lazy | X | X | leap | | X | over | X | X | X quick | X | X | X summer | | X | the | X | | X ------------------------------------如果我們想為每一個(gè)包含“brown”的文檔編輯一份完整的詞列表，我們可能會(huì)用如下查詢(xún) GET /my_index/_search {"query" : {"match" : {"body" : "brown"}},"aggs" : {"popular_terms": {"terms" : {"field" : "body"}}} }看上面的查詢(xún)部分。倒排索引通過(guò)詞條排好了序，所以我們首先找到包含“brown”的詞條列表，然后跨列掃描所有包含“brown”的文檔，這里我們很幸運(yùn)的找到了“Doc_1”和“Doc_2”。 然后在聚合部分，我們需要找Doc_1和Doc_2中找到所有的詞，在倒排索引的去做這個(gè)操作很非常昂貴的：意味著我們不得不迭代索引中的每一個(gè)詞，看它們是否包含在doc_1和doc_2中，這個(gè)過(guò)程是非常緩慢的，而且也是非常愚蠢的：因?yàn)殡S著文檔詞量的增加，我們聚合的執(zhí)行時(shí)間也會(huì)增加。 讓我們看看下面的結(jié)構(gòu)： Doc Terms ----------------------------------------------------------------- Doc_1 | brown, dog, fox, jumped, lazy, over, quick, the Doc_2 | brown, dogs, foxes, in, lazy, leap, over, quick, summer Doc_3 | dog, dogs, fox, jumped, over, quick, the -----------------------------------------------------------------有了這個(gè)結(jié)構(gòu)我們就會(huì)很容易得到doc_1和doc_2所包含的詞條，我們只需要通過(guò)上面的結(jié)構(gòu)把兩個(gè)集合合并起來(lái)就行了。
因此，查詢(xún)和聚合是非常復(fù)雜的，查詢(xún)文檔使用的是倒排索引，聚合文檔使用的是正排索引（doc_values） note：doc values不僅僅是用在聚合中，還被用在排序、腳本、子父文檔關(guān)系（這里暫不做介紹）。

深入Doc Values

前面講到的doc values給我們幾個(gè)印象：快速訪(fǎng)問(wèn)、高效、基于硬盤(pán)。現(xiàn)在我們來(lái)看看doc values到底是如何工作的？ doc values是在“索引期“隨著倒排索引一起生成的，也就是說(shuō)doc values是基于每個(gè)索引段生成且是不可改變的（immutable），和倒排索引一樣，doc values也會(huì)被序列化到磁盤(pán)上，這使得它具有了高效性和可擴(kuò)展性。 通過(guò)序列化一個(gè)數(shù)據(jù)結(jié)構(gòu)到磁盤(pán)上，我們可以依賴(lài)操作系統(tǒng)的file system cache 替代JVM的堆內(nèi)存，當(dāng)我們的“工作集”小于OS可用內(nèi)存時(shí)，操作系統(tǒng)會(huì)自然的加載這些doc values到內(nèi)存。這時(shí)doc values的性能和在JVM堆內(nèi)存中表現(xiàn)是一樣的。 但是當(dāng)工作集大于操作系統(tǒng)可用內(nèi)存時(shí)，操作系統(tǒng)將會(huì)按需加載doc values，這種情況下的訪(fǎng)問(wèn)速度會(huì)明顯的慢于全量加載doc values的時(shí)候。但這種操作使得我們的服務(wù)器內(nèi)存利用率遠(yuǎn)超過(guò)服務(wù)器最大內(nèi)存限制。試想一下，如果全量加載到doc values到內(nèi)存中勢(shì)必會(huì)造成ES OutOfMemery。 NOTE：由于doc values不受JVM堆內(nèi)存管理，所以我們可以把ES對(duì)內(nèi)存設(shè)置得小一點(diǎn)，把更多的內(nèi)存留給操作系統(tǒng)來(lái)?yè)Q出（doc values），同時(shí)這也可以使JVM的GC工作在更小的堆內(nèi)存上，更快更高效的執(zhí)行GC。
通常，我們配置JVM的堆內(nèi)存基本和操作系統(tǒng)內(nèi)存各占一半（50%），由于引進(jìn)了doc values所以我們可以考慮把JVM的堆內(nèi)存設(shè)置得小一些，比如我們可以在一個(gè)64G的服務(wù)器上設(shè)置JVM堆內(nèi)存為4 - 16GB比設(shè)置堆內(nèi)存為32G更加高效。

Column-store compression（列式存儲(chǔ)壓縮）

本質(zhì)上doc values是一個(gè)被序列化的面向“列式儲(chǔ)存”的結(jié)構(gòu)，我們前面討論過(guò)列式存儲(chǔ)在某些查詢(xún)操作上是有優(yōu)勢(shì)的，不僅如此它們也更擅長(zhǎng)數(shù)據(jù)壓縮，特別是數(shù)字，這對(duì)磁盤(pán)存儲(chǔ)和快速訪(fǎng)問(wèn)來(lái)說(shuō)是及其重要的。 為了了解它是如何壓縮數(shù)據(jù)的，我們看下面簡(jiǎn)單的doc values結(jié)構(gòu) Doc Terms ----------------------------------------------------------------- Doc_1 | 100 Doc_2 | 1000 Doc_3 | 1500 Doc_4 | 1200 Doc_5 | 300 Doc_6 | 1900 Doc_7 | 4200 -----------------------------------------------------------------像上面這種每行一條數(shù)據(jù)的形式，我們可以得到連續(xù)的數(shù)字塊，如：[100,1000,1500,1200,300,1900,4200]。因?yàn)槲覀冎浪鼈兌际菙?shù)字值可以被排列在一起通過(guò)一個(gè)一致的偏移量。 跟深層次的，這里有幾種壓縮方法可以運(yùn)用在這些數(shù)字上。你可能知道上面的數(shù)字都是100的倍數(shù)，如果索引段上所有的的數(shù)字都共享一個(gè)“最大公約數(shù)”，那么就可以用這個(gè)最大公約數(shù)去壓縮數(shù)據(jù)。如上面的數(shù)字我們可以除以100，得到的數(shù)據(jù)是[1,10,15,12,3,19,42]。這樣這些數(shù)字會(huì)變得小一些，存儲(chǔ)時(shí)占用的比特?cái)?shù)也會(huì)小一些。 doc values使用幾種手段來(lái)壓縮數(shù)字。

如果所有的數(shù)字值都相等（或者缺失），會(huì)設(shè)置一個(gè)標(biāo)記來(lái)表示該值

如果所有數(shù)字值的個(gè)數(shù)小于256個(gè)，將會(huì)使用一個(gè)簡(jiǎn)單的編碼表來(lái)壓縮

如果大于了256個(gè)，看看是否存在最大公約數(shù)，存在則使用最大公約數(shù)壓縮

如果不存在最大公約數(shù)，則存儲(chǔ)偏移量來(lái)壓縮數(shù)字。

如你看到的，你可能會(huì)想“這樣做對(duì)數(shù)值型字段做壓縮確實(shí)很好，那么對(duì)字符串類(lèi)型呢？”，其實(shí)字符串壓縮也是和數(shù)字壓縮一樣采用同樣的方法通過(guò)一個(gè)序數(shù)表來(lái)壓縮，字符串被去重、排序后被賦予了一個(gè)ID，這些ID就是數(shù)字，這樣就可以采用上面的方案進(jìn)行壓縮了。對(duì)于序數(shù)表本身也會(huì)采用壓縮存儲(chǔ)。

轉(zhuǎn)載于:https://www.cnblogs.com/chennanlcy/p/6591788.html

總結(jié)

以上是生活随笔為你收集整理的Elasticsearch2.x Doc values的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。