導(dǎo)讀
一、概述 Elasticsearch提供了豐富的數(shù)據(jù)類型，支持各種復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和復(fù)雜的業(yè)務(wù)場景。為了能夠?qū)崿F(xiàn)更快的索引速度和查詢速度，在設(shè)計索引結(jié)構(gòu)時，會考慮盡量減少字段數(shù)，減小文檔大小，縮短索引過程，以期提高檢索的速度。另外也會結(jié)合業(yè)務(wù)場景在不同數(shù)據(jù)結(jié)構(gòu)之間要有所取舍。 二、優(yōu)化策略 1._id生成策略 _id的生成策略對索引速度影響非常大。索引數(shù)據(jù)時，如果指定_id，Elasticsearch的版本檢查機制會校驗該_id是否存在，并生成新的版本號，默認先從緩存中取版本信息。如緩存中不存在，則要執(zhí)行一次檢索，隨著數(shù)據(jù)量的增加，該過程的耗時將逐步增加，寫入速度逐步下降。如果不指定_id，使用Elasticsearch自增ID，可以跳過版本檢查機制，大大提高索引速度。但是，這種場景主要用于不可變數(shù)據(jù)導(dǎo)入的場景，例如日志導(dǎo)入。而對于大多數(shù)業(yè)務(wù)場景，都需要指定_id,在很多情況下，需要使用文檔中一個或多個字段拼接生成唯一字符串，作為_id。這種情況下，能很好地保證數(shù)據(jù)的唯一性，但是，無規(guī)則的字符串作為_id會明顯拖累索引速度，根據(jù)測試結(jié)果，純數(shù)字的_id，效率最高。 2. text or keyword Elasticsearch中，字符串類型可以選擇text和keyword，text類型在寫入數(shù)據(jù)時，會被分詞。因此，如果沒有分詞查詢的需要，字符串類型一律使用keyword類型更為高效。 3. number or keyword 我們并非一定要用數(shù)值類型的字段（byte、integer、long...）存儲數(shù)字，Elasticsearch在索引數(shù)據(jù)的時候，對不同數(shù)據(jù)類型做了不同優(yōu)化以便于應(yīng)對不同檢索場景，對數(shù)值類型，提高了range query的查詢速度，而對keyword類型，提高了term query 的查詢速度. 因而在設(shè)計索引的時，針對數(shù)字，如各種ID，若不存在range query的情況，優(yōu)先使用keyword類型。 4. 盡量避免join 作為全文檢索的搜索引擎，join查詢，一直是Elasticsearch的弱項。但在日常業(yè)務(wù)中，有些情況下，又不可避免的需要使用join查詢。Elasticsearch 提供了nested、parent-child兩種關(guān)聯(lián)查詢的方式。但不幸的是，這兩種查詢方式極大地降低了查詢效率，nested會是查詢效率下降基本，而會產(chǎn)生幾十上百倍的下降。在doc數(shù)較小，并發(fā)較小的情況下，這種損失可以承受，但是對于億級甚至十億級的集群，這種性能損失是無法忍受的，另外，使用關(guān)聯(lián)查詢，索引結(jié)構(gòu)變得復(fù)雜，索引數(shù)據(jù)的速度同樣受到影響，nested結(jié)構(gòu)的文檔無法進行索引排序(index sorting)，而這種方式可以很好的提高檢索性能。 5.慎用doc_values Elasticsearch使用倒排索引存儲數(shù)據(jù)，能夠提供極高的檢索性能，但有得必有失，這種結(jié)構(gòu)并不能帶來很好的排序性能。Elasticsearch提供了doc_values功能，實現(xiàn)對倒排索引的裝置，這是一種列式存儲，能夠提供高效的排序和聚合，默認情況下，Elasticsearch會個每個字段開啟doc_values，如果某個字段并沒有排序和聚合的需求，可以禁用該字段的doc_values屬性，以減少索引數(shù)據(jù)和存儲的性能消耗。 6._all 字段的使用 _all字段是把其它字段值當(dāng)作一個大字符串來索引的特殊字段，query_string 查詢子句(搜索 ?q=john )在沒有指定字段時默認使用 _all 字段，這種設(shè)置有利于全文檢索，在6.0.0以前的版本里，_all字段默認開啟。實際使用過程中，我們并不一定需要這么大的字段，甚至不需要這個字段。根據(jù)業(yè)務(wù)需求，我們可以考慮禁用_all字段，或者使用使用copy_to指定字段拼接。 7._source 字段的優(yōu)化 _source字段存儲了原始json文檔，默認包含所有字段。雖然在獲取文檔字段或整個文檔內(nèi)容時，非常高效，但同樣也占用了大量存儲空間。如果某些字段只需要進行檢索，無需返回值，那么可以通過在_soucrce 中配置includes和excludes來自定義字段存儲，節(jié)省存儲空間。 8.dynamic mapping的使用 Elasticsearch默認允許在索引數(shù)據(jù)的時候可以動態(tài)新增字段，但是這種配置有相當(dāng)風(fēng)險。因為Elasticsearch的字段不允許刪除和修改數(shù)據(jù)類型，一旦在索引數(shù)據(jù)時出現(xiàn)意外，這可能導(dǎo)致索引結(jié)構(gòu)急速膨脹。而且，為了提高讀寫性能我們需要對很多字段進行特殊設(shè)置，建議禁用dynamic mapping功能，或者通過dynamic_templates預(yù)設(shè)數(shù)據(jù)類型。 9.更少的索引字段 由于Elasticsearch 的join查詢功能的弱項，通常情況下，每個文檔都包含大量字段，有些字段我們需要用來進行檢索過濾，有些字段僅僅用來存儲數(shù)據(jù)。因而在設(shè)計索引的時候，對于無需檢索的字段可以設(shè)置enable=false，這樣只存儲不索引，可以提高索引速度，同時，這種字段可以合并成單個字段。 10.預(yù)索引數(shù)據(jù) 在某些業(yè)務(wù)場景下，為了提高檢索和聚合的速度，我們可以對某些字段的進行預(yù)分組。如年齡字段經(jīng)常有需要按照年齡段進行檢索或聚合，這種情況下，我們可以在每個文檔增加年齡段這個字段，使用keyword類型，這樣可以大大提高檢索和聚合的速度。 三、易觀鋯云產(chǎn)品中ES索引的設(shè)計 易觀鋯云面向企業(yè)級用戶，提供一站式的第三方數(shù)據(jù)交易及算力加持服務(wù)。基于Elasticsearch提供實時/離線數(shù)據(jù)服務(wù)，數(shù)據(jù)總量大，文檔字段多，業(yè)務(wù)復(fù)雜，并發(fā)高，伴隨著高速寫入，讀寫矛盾嚴重。對此我們做了多方位的優(yōu)化，盡最大努力提高集群性能，以下是索引結(jié)構(gòu)方面優(yōu)化總結(jié)： 1. 文檔含數(shù)十個字段，且多個字段中存儲數(shù)十條數(shù)據(jù)。因業(yè)務(wù)需要，唯一標識的字段是無規(guī)則的字符串。索引數(shù)據(jù)時，我們對該字段進行了散列轉(zhuǎn)換、取hash等操作，保證了極低的重復(fù)率，也提高了數(shù)據(jù)索引速度。 2. 大量字段經(jīng)過標準化處理過后，都使用id存儲，在設(shè)計索引結(jié)構(gòu)時，統(tǒng)一使用keyword存儲，提高了檢索和聚合性能；禁用了dynamic mapping，自定義copy_to 。 3. 增加分組字段，如，年齡age按照age_range進行預(yù)處理，提高檢索和聚合性能。 4. 在鋯云產(chǎn)品中，有多個字段，是 id -> [value1，value2...]結(jié)構(gòu)，并且需要進行關(guān)聯(lián)查詢，就需要使用nested Object結(jié)構(gòu)，這大大降低了數(shù)據(jù)寫入速度和查詢速度，同時，nested結(jié)構(gòu)使得我們無法在寫入數(shù)據(jù)時，使用順序存儲（index sorting）。對此，我們將字段合并，避開了object結(jié)構(gòu)，同時，更好的支持了關(guān)聯(lián)查詢。 如, app_tgi:{id:integer, tgi:float},每個app_tgi字段都要存儲幾十條數(shù)據(jù)，業(yè)務(wù)中，需要對id及tgi進行關(guān)聯(lián)查詢過濾，在實際索引中，我們通過將id和tgi分別定長，然后拼裝成一個整數(shù)，如id=1000023,tgi=1.6558 最終生成的app_tgi = 10000230000016558，同時，對app_tgi字段進行索引排序，這樣，在實際使用過程中，如果需要讀檢索 id=id=1000023,tgi> 1.6558,就可以通過 app_tgi > 10000230000016558 && app_tgi < 10000239999999999，nested 查詢轉(zhuǎn)變成數(shù)值的range查詢，大大提高了檢索速度。 綜上所述，針對Elasticsearch索引結(jié)構(gòu)的優(yōu)化就是讓字段更少，文檔更小，讀寫更快。業(yè)務(wù)場景不同，取舍不同，鋯云產(chǎn)品查詢的壓力高于寫入壓力，某些情況下我們犧牲了寫入的性能來獲得更好的查詢性能。Elasticsearch的調(diào)優(yōu)是多方位的，在后續(xù)的文章中，我們將逐步介紹易觀在使用Elasticsearch過程中，在服務(wù)端、客戶端針對讀、寫、穩(wěn)定性等各方面的優(yōu)化經(jīng)驗。 |
|
|
