• 開通與購買

  • 為什么已購買搜索引擎，使用搜索索引還需要單獨(dú)開通？

• 功能特性

  • 什么是搜索索引？

  • 搜索索引的適用場景有哪些？

  • 搜索索引與二級索引的區(qū)別是什么？

  • 模糊查詢和分詞查詢的區(qū)別及適用的場景有哪些？

  • 分區(qū)索引的適用場景和不適用場景有哪些？

• 參數(shù)配置

  • 創(chuàng)建搜索索引時(shí)，需要關(guān)注哪些參數(shù)？

  • 創(chuàng)建分區(qū)索引時(shí)，需要關(guān)注哪些參數(shù)？

• 性能調(diào)優(yōu)

  • 如果有分頁的需求，怎么做比較好？

  • 如果有導(dǎo)出的需求，怎么做比較好？

  • 如何優(yōu)化數(shù)據(jù)同步速度？

  • 如何通過調(diào)整數(shù)據(jù)類型來提升查詢性能？

• 性能分析和資源評估

  • 分區(qū)索引是如何提升查詢RT和QPS的？

  • 如何評估查詢性能？

  • 分片數(shù)量對查詢和寫入性能有什么影響？

  • 如何評估搜索索引所需要的資源？

• 數(shù)據(jù)遷移

  • 搜索索引數(shù)據(jù)可以通過LTS遷移嗎？

什么是搜索索引？

搜索索引是寬表引擎的一種新型索引，可以對查詢進(jìn)行加速。主要面向復(fù)雜的多維查詢場景，能夠覆蓋分詞、模糊查詢、聚合分析、排序翻頁、向量檢索等場景。詳細(xì)介紹，請參見搜索索引介紹。

如果您想要更深入地了解搜索索引的技術(shù)細(xì)節(jié)，請參見如何破解HBase+Elasticsearch組合使用遇到的難題和深度解析Lindorm全文索引（SearchIndex）特性。

搜索索引的適用場景有哪些？

搜索索引與二級索引的區(qū)別是什么？

• 搜索索引是寬表引擎與搜索引擎深度融合的特性，需要單獨(dú)開通購買，核心功能為倒排索引和列存，適合較為復(fù)雜的多維查詢場景，一個(gè)寬表只能創(chuàng)建一個(gè)搜索索引表，索引列個(gè)數(shù)最多1000個(gè)（默認(rèn)）。

  二級索引是Lindorm寬表內(nèi)置的特性，無需開通即可使用，適合較為固定的查詢場景，一個(gè)寬表默認(rèn)最多有5個(gè)二級索引表。

• 搜索索引的數(shù)據(jù)一致性默認(rèn)為最終一致，數(shù)據(jù)寫入寬表后需等待1-15秒后才可查詢，如果希望數(shù)據(jù)能更快可查詢，請提交工單咨詢。

  二級索引的數(shù)據(jù)一致為強(qiáng)一致，數(shù)據(jù)寫入寬表即可查詢。

為什么已購買搜索引擎，使用搜索索引還需要單獨(dú)開通？

搜索引擎是一個(gè)獨(dú)立的引擎，可以不依賴寬表引擎和LTS單獨(dú)使用。而搜索索引是寬表引擎的一個(gè)索引功能，開通時(shí)不僅需要購買搜索引擎，還需要購買LTS數(shù)據(jù)同步節(jié)點(diǎn)。所以僅僅購買搜索引擎，還無法使用搜索索引功能。LTS數(shù)據(jù)同步節(jié)點(diǎn)的價(jià)格，請參見LTS。

模糊查詢和分詞查詢的區(qū)別及適用的場景有哪些？

• 模糊查詢：通常是指使用SQL中的LIKE通配符匹配關(guān)鍵詞的查詢。這種查詢方式在搜索索引創(chuàng)建后可以直接使用。但是當(dāng)需要匹配的數(shù)據(jù)量較大或本身存儲的字符串內(nèi)容較長時(shí)，查詢性能可能會隨著數(shù)據(jù)量的增大而降低。

• 分詞查詢：數(shù)據(jù)查詢時(shí)，搜索引擎會先對原始字符串進(jìn)行分詞，再對分詞字段執(zhí)行關(guān)鍵詞匹配操作，例如在通用搜索引擎產(chǎn)品中進(jìn)行關(guān)鍵詞檢索。這種查詢方式通常無法保證每次檢索都一定能匹配到數(shù)據(jù)，即使原始寫入的數(shù)據(jù)中包含檢索內(nèi)容，但這些數(shù)據(jù)在存儲時(shí)經(jīng)過分詞或過濾停詞等操作后導(dǎo)致最終構(gòu)建的索引字段中沒有對應(yīng)的檢索內(nèi)容，那么檢索結(jié)果也仍舊為空。另外，不同分詞器的分詞效果也不相同。

如果在業(yè)務(wù)上使用分詞查詢可以滿足模糊查詢的需求，建議您優(yōu)先選擇分詞查詢。

中文分詞建議使用IK分詞器，英文分詞建議使用English分詞器。使用分詞查詢代替模糊查詢時(shí)，可以使用雙引號（""）將關(guān)鍵詞括起來以提高匹配度，例如where fieldName='"hello world"'。

如果業(yè)務(wù)上確定是需要模糊查詢，不是分詞查詢，可以參考以下方法處理：

• 方法一：

  轉(zhuǎn)換字段內(nèi)容，使分詞查詢達(dá)到近似模糊查詢的效果。例如，使用逗號或空格將需要檢索的關(guān)鍵詞分隔開，并在創(chuàng)建搜索索引時(shí)配置whitespace或comma分詞。這種查詢可以直接使用等值過濾并有效規(guī)避LIKE查詢可能造成的性能瓶頸。

• 方法二：

  定義字段的數(shù)據(jù)類型為String，并在SQL中使用LIKE通配符查詢。

  說明

  使用LIKE通配符查詢在數(shù)據(jù)量增大時(shí)可能會產(chǎn)生性能降低問題，建議您在使用時(shí)及時(shí)關(guān)注查詢性能。

• 方法三：

  如果上述兩種方法都無法滿足業(yè)務(wù)需求，您可以使用ngram分詞器。在創(chuàng)建搜索索引時(shí)，設(shè)置analyzer=ngram。

  說明

  • 使用ngram分詞器查詢時(shí)，查詢語句需要使用search_query高級語法。詳細(xì)介紹，請參見高級查詢語法。

  • 查詢時(shí)需要使用雙引號（""）將關(guān)鍵詞括起來，同時(shí)，WHERE條件中的各種組合條件都需要寫在search_query語法中。例如where search_query='fieldName:"123"'。

如何評估搜索索引所需要的資源？

使用搜索索引前，除了寬表引擎，您還需要購買LTS數(shù)據(jù)同步節(jié)點(diǎn)和搜索引擎。

LTS數(shù)據(jù)同步節(jié)點(diǎn)在整體資源占比中較小，您可以根據(jù)寫入峰值TPS評估所需的節(jié)點(diǎn)數(shù)量。例如，通常情況下，2個(gè)低配的LTS節(jié)點(diǎn)可以滿足有20個(gè)索引列且寫入峰值TPS每秒不超過5萬個(gè)的業(yè)務(wù)需求。索引列越多，寫入峰值TPS越高，需要的LTS節(jié)點(diǎn)越多。

搜索引擎的資源評估與查詢和寫入模型是強(qiáng)相關(guān)的，需要根據(jù)具體的業(yè)務(wù)場景進(jìn)行評估。

對于搜索引擎所需資源的評估，建議您先購買部分節(jié)點(diǎn)進(jìn)行性能測試，再根據(jù)測試結(jié)果選擇合理的規(guī)格和節(jié)點(diǎn)數(shù)量。數(shù)據(jù)量在20億規(guī)模以上時(shí)，建議搜索引擎的規(guī)格選擇16核64 GB。

如果您在資源評估時(shí)需要幫助，請聯(lián)系Lindorm技術(shù)支持（釘釘號：s0s3eg3）。

創(chuàng)建搜索索引時(shí)，需要關(guān)注哪些參數(shù)？

• 如果只是想體驗(yàn)搜索索引，并無嚴(yán)格的業(yè)務(wù)需求，請參見管理搜索索引。

• 如果有分詞需求，創(chuàng)建搜索索引時(shí)，需要關(guān)注analyzer參數(shù)的設(shè)置。analyzer參數(shù)的詳細(xì)介紹，請參見CREATE SEARCH INDEX。

• 如果您確定某個(gè)字段在查詢語句中只是簡單的等值過濾查詢，不會涉及排序、聚合（MAX、MIN、AVG或SUM等）、GROUP BY或范圍查詢時(shí)，可以將該字段的columnStored參數(shù)值設(shè)置為false，以減少構(gòu)建列式索引帶來的資源消耗。

• 如果單表數(shù)據(jù)量超過2億則需要關(guān)注numShards參數(shù)。單個(gè)Shard（分片）的數(shù)據(jù)量通常控制在3千萬到1億條之間（一般在30 GB以內(nèi)），實(shí)際數(shù)據(jù)量控制需要根據(jù)實(shí)際業(yè)務(wù)情況確定。分片數(shù)對查詢或?qū)懭胄阅艿挠绊懀垍⒁?a title="" class="xref" href="#section-0tq-4rq-2vx">分片數(shù)量對查詢和寫入性能有什么影響？。

• 如果單表數(shù)據(jù)量超過10億，或查詢RT和查詢QPS無法滿足要求時(shí)可以通過創(chuàng)建分區(qū)索引來解決相關(guān)問題。分區(qū)索引需要關(guān)注的內(nèi)容，請參見分區(qū)索引的適用場景和不適用場景有哪些？和創(chuàng)建分區(qū)索引時(shí)，需要關(guān)注哪些參數(shù)？。

分區(qū)索引的適用場景和不適用場景有哪些？

分區(qū)索引的適用場景：

單表數(shù)據(jù)量較大，例如超過10億，或查詢RT和查詢QPS無法滿足要求時(shí)，推薦您使用分區(qū)索引。

分區(qū)索引的不適用場景：

針對全部數(shù)據(jù)進(jìn)行檢索且沒有固定的過濾字段或明顯的時(shí)間屬性的場景，不適合使用分區(qū)索引。這種場景下，如果數(shù)據(jù)量很大且存在查詢性能問題，可以考慮合理設(shè)置分片數(shù)量，或在業(yè)務(wù)上進(jìn)行分表操作。

如果您想要更深入的了解分區(qū)索引對查詢性能的影響，請參見分區(qū)索引是如何提升查詢RT和QPS的？。

如果在創(chuàng)建分區(qū)索引時(shí)對參數(shù)的設(shè)置有疑問，請參見創(chuàng)建分區(qū)索引時(shí)，需要關(guān)注哪些參數(shù)？。

分區(qū)索引是如何提升查詢RT和QPS的？

• 對HASH分區(qū)來說，默認(rèn)是根據(jù)一個(gè)內(nèi)置的主鍵字段進(jìn)行HASH分區(qū)，每次查詢都需要掃描所有分區(qū)。根據(jù)木桶效應(yīng)，整體查詢的時(shí)延取決于最慢的分區(qū)。另外，當(dāng)數(shù)據(jù)量很大時(shí)，單機(jī)分區(qū)數(shù)也會很多，服務(wù)端的并發(fā)請求可能會出現(xiàn)排隊(duì)現(xiàn)象。如果設(shè)置固定查詢字段進(jìn)行HASH分區(qū)，則查詢時(shí)只需要掃描某一個(gè)或某幾個(gè)分區(qū)。因此，當(dāng)分區(qū)數(shù)量較多時(shí)，設(shè)置固定字段會帶來明顯的RT和QPS提升。

  說明

  • 為提升查詢性能，建議設(shè)置為HASH分區(qū)的字段的值盡量豐富，同時(shí)避免同一個(gè)分區(qū)鍵下的數(shù)據(jù)過多（例如不要超過1億）。

  • 如果數(shù)據(jù)量過大，建議使用多級HASH分區(qū)。詳細(xì)內(nèi)容，請參見多級HASH分區(qū)（高級用法）。

• 對時(shí)間分區(qū)來說，會根據(jù)設(shè)置的RANGE_TIME_PARTITION_INTERVAL參數(shù)的值按時(shí)間范圍創(chuàng)建分區(qū)。數(shù)據(jù)查詢過程中根據(jù)某個(gè)時(shí)間范圍過濾數(shù)據(jù)時(shí)，則只需要查詢對應(yīng)時(shí)間范圍的分區(qū)。如果查詢場景有明顯的時(shí)間屬性，并且有較大比例的查詢限定在一個(gè)時(shí)間范圍時(shí)，會帶來明顯的RT和QPS提升。

創(chuàng)建分區(qū)索引時(shí)，需要關(guān)注哪些參數(shù)？

需要重點(diǎn)關(guān)注的參數(shù)有：

• partitions：

  • 如果只有HASH分區(qū)，建議將分區(qū)數(shù)量partitions設(shè)置為較大的值，例如64、128等，可以使數(shù)據(jù)分布至更多的分區(qū)。數(shù)據(jù)查詢時(shí)，如果查詢語句通常會攜帶分區(qū)字段，那么系統(tǒng)只需要在某一個(gè)或某幾個(gè)分區(qū)中查找數(shù)據(jù)即可；如果查詢語句不攜帶分區(qū)字段，系統(tǒng)將在所有分區(qū)中查找數(shù)據(jù)。

  • 如果有時(shí)間分區(qū)，可以將partitions設(shè)置為較小的值，例如節(jié)點(diǎn)數(shù)的2倍。達(dá)到RANGE_TIME_PARTITION_INTERVAL參數(shù)設(shè)置的時(shí)間后，服務(wù)端會自動增加分區(qū)，增加的分區(qū)數(shù)量就是設(shè)置的partitions參數(shù)的值。

• RANGE_TIME_PARTITION_INTERVAL：決定多數(shù)查詢的時(shí)間范圍，建議設(shè)置為較大概率出現(xiàn)的、較短的時(shí)間范圍。您可以根據(jù)查詢習(xí)慣，合理設(shè)置參數(shù)的值。例如，大部分查詢語句過濾的時(shí)間范圍在一周以內(nèi)，或一次查詢的跨度為一個(gè)月，但是一周內(nèi)的查詢更多，可以將參數(shù)的值設(shè)置為7。

• HASH分區(qū)字段或時(shí)間分區(qū)字段：HASH分區(qū)字段建議選擇多數(shù)查詢會攜帶的固定字段，時(shí)間分區(qū)字段建議選擇用來指定時(shí)間范圍的字段。

  說明

  • 分區(qū)字段寫入后強(qiáng)行更新可能會導(dǎo)致數(shù)據(jù)紊亂。因此查詢時(shí)選取的時(shí)間字段不能是支持更新的時(shí)間字段。

  • 時(shí)間字段請盡量使用LONG類型，否則可能會影響查詢性能。

如果有分頁的需求，怎么做比較好？

如果有導(dǎo)出的需求，怎么做比較好？

您可以針對以下場景使用SQL查詢：

• 需要將匹配數(shù)據(jù)全部導(dǎo)出：可以不設(shè)置LIMIT，OFFSET參數(shù)。

• 需要導(dǎo)出N條數(shù)據(jù)：設(shè)置limit N條件。

使用SQL查詢，在獲取數(shù)據(jù)時(shí)通過迭代器每次僅獲取一條數(shù)據(jù)，并流式返回查詢結(jié)果。對于匹配數(shù)據(jù)，服務(wù)端會自動分批拉取。客戶端在處理數(shù)據(jù)時(shí)，為了防止客戶端內(nèi)存溢出，可以在迭代器中獲取到N條數(shù)據(jù)后，增加一個(gè)數(shù)據(jù)處理邏輯，再繼續(xù)在迭代器中獲取其他數(shù)據(jù)。

如何優(yōu)化數(shù)據(jù)同步速度？

如果在很長一段時(shí)間內(nèi)無法查詢到寫入寬表的數(shù)據(jù)，可能是由于服務(wù)端資源難以支撐當(dāng)前的寫入TPS，導(dǎo)致數(shù)據(jù)同步較慢。

您可以通過以下步驟，在LTS管理頁面查看實(shí)時(shí)數(shù)據(jù)同步的延遲情況。

1. 登錄Lindorm管理控制臺。

2. 在頁面左上角，選擇實(shí)例所屬的地域。

3. 在實(shí)例列表頁，單擊目標(biāo)實(shí)例ID或者目標(biāo)實(shí)例所在行操作列的管理。

4. 在左側(cè)導(dǎo)航欄，單擊寬表引擎。

5. 單擊搜索索引頁簽。

6. 在LTS WebUI訪問區(qū)域中，單擊ClusterManager公網(wǎng)或ClusterManager專有網(wǎng)絡(luò)。

7. 在左側(cè)導(dǎo)航欄，選擇Lindorm Search > 實(shí)時(shí)同步。

如何評估查詢性能？

如果您的查詢場景不屬于以上列舉的場景，請聯(lián)系Lindorm技術(shù)支持（釘釘號：s0s3eg3）。

分片數(shù)量對查詢和寫入性能有什么影響？

對查詢的影響：

查詢時(shí)，一個(gè)分片下的數(shù)據(jù)是串行掃描的，如果一個(gè)分片下的數(shù)據(jù)很多，就會影響單次查詢的RT。多個(gè)分片之間是并行查詢的，如果分片數(shù)很多，一次查詢給服務(wù)端造成的并發(fā)就會比較高。所以分片數(shù)不能設(shè)置太多，也不能太少。設(shè)置多少比較合適，需要結(jié)合業(yè)務(wù)對查詢RT和QPS的需求進(jìn)行評估。

一般來說，單個(gè)分片承載的數(shù)據(jù)量在3千萬到1億之間比較合適。如果單表數(shù)據(jù)量超過10億，或者查詢RT、查詢QPS無法滿足要求時(shí)，一般需要關(guān)注分區(qū)索引。分區(qū)索引的詳細(xì)介紹，請參見分區(qū)索引。

對寫入的影響：

通常情況下，在滿足上述查詢需求的前提下，分片數(shù)越多，寫入性能越好。

如何通過調(diào)整數(shù)據(jù)類型來提升查詢性能？

• 對于范圍查詢字段：建議將數(shù)據(jù)類型設(shè)置為數(shù)值類型，盡量不要設(shè)置為VARCHAR。相比于數(shù)值類型，VARCHAR類型的范圍查詢性能較差，且數(shù)據(jù)量越大，性能差距越明顯。

• 對于Type、Status等枚舉類型的值：建議設(shè)置為VARCHAR類型。如果只有兩種類型，建議將數(shù)據(jù)類型設(shè)置為BOOLEAN。

• 業(yè)務(wù)上是數(shù)值類型的字段，如果查詢時(shí)都是等值查詢，也建議設(shè)置為VARCHAR。

搜索索引數(shù)據(jù)可以通過LTS遷移嗎？

不可以。Lindorm暫不支持通過LTS遷移搜索索引數(shù)據(jù)。