一、引言
Lindorm提供海量資料下的高性能、低成本、彈性的存儲能力，被廣泛應用在風控、推薦、曆史訂單等場景中，成為阿裡經濟體的核心資料庫産品之一。随着集團雲化的戰略推進和雲原生時代的到來，為了更好的服務内外客戶，Lindorm品牌全新更新，融合寬表、時序、搜尋、檔案四種模型，演變為一款
雲原生多模資料庫，關于Lindorm的産品介紹，可參考
存的起，看得見—雲原生多模資料庫Lindorm技術解析。
寬表模型相容開源HBase接口，适合存儲海量資料，并提供極高吞吐的鍵值查詢。本篇文章介紹的全文索引SearchIndex是依托搜尋引擎為寬表模型提供更進階的查詢能力，是Lindorm寬表引擎和搜尋引擎的深度融合特性。本文主要介紹SearchIndex的技術原理和核心能力，分享過去我們遇到的關鍵問題以及解決思路。
-
什麼是SearchIndex？
1）Lindorm寬表的一種新型索引，用來加速多條件查詢，是Lindorm在資料可見性上的全新探索。
2）索引引擎基于Lucene，可同時提供倒排和正排索引，具備多元查詢、文字檢索等基礎功能。
二、現狀與挑戰
2.1 多樣化的資料查詢需求
Lindorm依托其彈性的擴充能力和低成本，成為海量資料存儲的首選，在過去的2020年，Lindorm資料存儲規模接近400PB，平均壓縮率在5:1。在海量資料存儲的背景下，伴随着雲原生、5G/IOT時代的到來，新的業務模型在不斷湧現，除了簡單的主鍵查詢和範圍查詢外，簡單分析、多元檢索成為業務的基本需求。
以Lindorm客戶收錢吧的線上訂單場景為例，每天接近5千萬筆訂單資料，需要儲存3年之久，通過Lindorm的冷熱分離、生命周期自動管理以及高效壓縮顯著的降低了業務的存儲成本，良好的擴充性可以随時應對業務峰值，毫秒級擷取訂單詳情。随着業務的發展，訂單系統需要提供更豐富的查詢入口，幫助商家從多個次元檢索出訂單清單，并進行基礎的統計分析，可以結算每天的營業總額、總的訂單數，以及曆史的曲線變化。如何高效的支援這些多樣化的查詢是Lindorm在服務衆多客戶過程中需要重點解決的，常見的一些查詢需求如下：
1）多元查詢。 即席查詢(adhoc)，一般是不固定的列随機組合。
2）count計數。 擷取資料表的總行數，或者傳回一次查詢命中的資料條數。
3）指定列排序。 按照指定列降序或升序，比方說按照訂單時間降序輸出結果。
4）分詞檢索。 支援文本字段的分詞檢索，傳回相關性較高的結果資料。
5）統計聚合。 按照某個字段進行聚類統計，求取sum/max/min/avg等，或者傳回去重後的結果集。
6）模糊查詢。 查詢以'阿裡'開頭的資料，可以比對出'阿裡巴巴'的結果集，類似MySQL的like文法。
諸如此類的海量資料低成本存儲+檢索多樣化的需求成為越來越多業務的基本訴求，如何在Lindorm系統本身的高擴充、低成本的優勢之上，同時去支撐業務的多樣化查詢場景，成為客戶和我們一直思考去解決的問題。
2.2 Lindorm現有方案
面對複雜的查詢需求，在Lindorm上的使用者通常會選擇如下幾個解決方案：
1）主鍵索引。Lindorm天然具備主鍵索引，可以很好的滿足業務基于主鍵的整行比對、字首比對、範圍查詢等場景。
2）原生二級索引。在多元查詢的場景中，通過建立多個二級索引來滿足。二級索引适用查詢模式較為固定的場景，一個主表建議控制在5個二級索引表以内最佳。
3）聚合Aggregate。使用Lindorm Aggregate文法，支援count/sum/avg/min/max。
4）自然排序。目前僅支援主鍵列或索引列排序，按照最左字首比對，隻能排序
等值查詢後的第一個主鍵列或索引列
。例如：
CREATE TABLE myTable (pk1 int, pk2 text, c1 text, c2 bigint, PRIMARY KEY (pk1, pk2));
SELECT * FROM myTable WHERE pk1=? ORDER BY pk2; // 合法
SELECT * FROM myTable WHERE pk1=? ORDER BY c1; // 非法
CREATE INDEX myIndex ON myTable (c1, c2);
SELECT * FROM myTable WHERE c1=? ORDER BY c2; // 合法
SELECT * FROM myTable WHERE c2=? ORDER BY c1; // 非法 主鍵和索引的設計遵循
最左字首比對
，關于二級索引可參考
高性能原生二級索引5）Like查詢。對于字元串類型的資料，可以使用Lindorm Like文法實作模糊查詢，支援通配符
%
和
_
上述方案最大的優點就是簡單、開發便捷，但不可避免在規模和成本制約下，會存在瓶頸，例如全表的count需要消耗大量IO資源、過多的二級索引會導緻寫入吞吐的下降。如何在有限的資源下盡可能高效的滿足業務複雜查詢的訴求成為我們下一步重點考慮的問題，業界同樣也面臨這樣的問題。
2.3 業界解決方案
搜尋引擎是解決複雜查詢的最佳實踐之一，業界通常會選擇将資料轉儲到搜尋引擎Elasticsearch/Solr中，或者内置Lucene引擎來提供複雜查詢的支援。
1）資料轉儲到外部搜尋引擎
1.1）應用雙寫
資料雙寫是最為簡單的實作方式，通過前端接入Kafka等消息系統，多個消費者雙寫到不同的應用系統中。在我們接觸的客戶中，有非常多的業務是雙寫HBase和Elasticsearch/Solr，查詢時，先從搜尋引擎中查詢出主鍵，然後回查HBase擷取完整的結果資料。雖然簡單快捷，但不可避免會面臨非常多的痛點。
- 開發成本高。需要學習了解兩套系統的API，多語言的支援也不盡相同。
- 資源消耗高。雙寫相當于寫入雙份的資料，用戶端需要更多的資源才可以確定兩套系統的寫入均衡，防止出現木桶效應影響全局的寫入穩定。
- 缺少資料一緻性保障。任何一個系統的資料寫入失敗需要自主處理重試，否則會導緻資料丢失；HBase支援部分更新，而搜尋引擎隻能整行更新，是以更新場景必須讀取出原始資料才能組裝出索引資料，這在高并發的寫入場景下很容易出現資料不一緻問題。
1.2）資料自動同步（LilyIndexer+Apache Solr）
開源HBase可以借助LilyIndexer将資料同步到Solr中提供全文檢索的能力，它的基本架構如下圖，整體的流程是：先通過HBase Replication（資料複制）将表的WAL日志資料推送到LilyIndexer，LilyIndexer按照事先配置好的映射Schema解析出資料，最後同步寫入到Solr中。
通過自動同步省去了業務用戶端的開發成本，但同時也會帶來維護的複雜。
- 運維複雜，難以維護。LilyIndexer已經多年無人維護，鍊路操作比較繁瑣，需要同時操作三個服務HBase/LilyIndexer/Solr。目前主要是大資料釋出商Cloudera内部維護，沒有形成應用生态。
- 同步效率低，鍊路不可見。一行資料寫入到HBase後，需要經過多次序列化/反序列化才能寫入Solr，整個過程高度依賴HBase的Replication能力，很容易達到瓶頸；同時，每個HBase表的Replication通道彼此隔離，如果有多張表需要同步，那麼一個WAL将會被重複讀取多次，存在嚴重的木桶效應，給HDFS帶來無效的IO壓力。并且同步鍊路是個黑盒，一旦出現同步阻塞，隻能從背景運作日志中檢視原由。
- 資料一緻性難以保障。HBase支援多版本，每個KV都具有獨立的時間戳ts，可以確定時間戳ts大的優先可見。但是在Solr中并沒有時間戳的概念，資料以後寫的為準。加之HBase Replication消費WAL存在亂序的問題，就會導緻資料寫入Solr的順序錯亂，引起HBase表的資料與Solr索引資料的不一緻。
2）内置搜尋引擎
通過對架構重新設計，内嵌搜尋引擎的支援，進而達到系統的整體統一，這樣既能繼承原始的查詢功能，又可以擴充支援較為複雜的查詢。例如MongoDB，開源的版本不具備全文檢索的能力，隻提供基礎的Text索引功能，而它背後的公司MongoDB Inc.推出的企業版Atlas新增一個Search的功能，依托Lucene實作了全文檢索的能力。最初由Facebook開源的分布式NoSQL資料庫Cassandra同樣是在架構上進行更新，開源的Solandra方案便是引入搜尋引擎Solr解決複雜的查詢問題，其背後的公司Datastax也是在此基礎上推出商業化的DSE Search特性，它的基本架構如下圖，通過深度修改Cassandra和Solr的源碼，将兩者融合在一個程序中提供服務，對外提供統一的CQL查詢文法。
将搜尋引擎與原始架構深度融合是一種非常好的方案，但也會面臨一系列的問題。
- 系統隔離性。運作時的部署形态能否做到真正的隔離，搜尋引擎的查詢對資源要求較高，如果缺少合理的資源配比，很容易出現資源的浪費和運作時的互相影響。
- 資料一緻性。因為Lucene天然的設計限制，資料寫入後無法立即可見，即使内置搜尋引擎沒有了資料同步的延遲，依然無法提供強一緻的語義，業務必須忍受最終一緻帶來的通路延遲。
通過對業界方案的調研分析，我們看到了一些優秀的實踐以及融合Lucene過程中會存在的一些問題，為了解決這些問題，我們期望在Lindorm上設計一種新的索引，以資料庫特性的方式即開即用，幫助業務解決海量資料下的複雜查詢問題。
三、Lindorm SearchIndex 設計思路
索引通常用來加速查詢，可以通過增加一種新的索引類型來解決海量資料的複雜查詢問題，Lindorm作為一個多模資料庫，原生支援搜尋引擎，天然具備全文索引能力。是以，我們通過融合搜尋引擎，為Lindorm寬表增加了一種新型索引：SearchIndex。使得業務不感覺底層的多個引擎以及資料的流轉，隻需要申請一個新的索引即可解決複雜的查詢問題，就像使用Lindorm二級索引一樣友善快捷。SearchIndex重點建構以下能力：
1）統一進制資料
多套系統運維複雜的根因是各自的中繼資料不統一，需要使用各自專用的指令才可以操作，例如在一個系統中建完表，還需要在另外一個系統中建索引。通過維護統一的分布式中繼資料，我們可以屏蔽掉不同引擎間的Schema差異，提供統一的指令完成DDL類的操作。
2）統一接口
多個系統間的接口存在差異，通過實作一套專有的統一接口可以有效降低開發的複雜度，但這也需要業務學習和了解新的接口，應用開發成本沒有明顯的降低。SQL作為衆多資料庫系統的開發語言，使用和學習成本都較低，Lindorm SearchIndex原生支援類SQL接口：CQL，業務開發過程中不感覺索引的存在，在使用體驗上與原始的寬表通路保持一緻。
3）強一緻性
資料在多個引擎間流轉必然會涉及到一緻性問題，通常隻能提供最終一緻性的語義，資料的正确性和通路延遲無法有效保障。Lindorm SearchIndex提供了最終一緻性和強一緻性兩種語義，對于通路量大、資料延遲性要求不高的場景采用最終一緻性，可以提供非常高的吞吐和可用性，而業務通路延遲敏感的業務可以選擇強一緻性模型，資料寫入成功後，索引立即可查。
4）資源隔離
異構系統對資源的使用各不相同，必須建立有效的隔離機制確定資源使用最大化，Lindorm通過
存儲和索引
分離的模式來保障系統的健壯和彈性。寬表引擎負責存儲原始資料，具備極低的存儲成本，搜尋引擎負責索引和檢索，兩個引擎可以配置不同的CPU、記憶體資源，并且可以獨立擴縮容。
接下來，我們将重點介紹SearchIndex的架構設計以及具體的功能實作。
四、Lindorm SearchIndex 功能解析
4.1 使用舉例
SearchIndex的使用非常簡單，建立索引表時隻需要枚舉出索引列名即可，查詢時不需要感覺索引表的存在。下面先給出一個具體的例子，介紹如何使用Lindorm CQL(CQL是Cassandra的查詢語言，Lindorm無縫相容Cassandra API)操作SearchIndex。
- 原始表
CREATE TABLE myTable (
id bigint,
name text,
age int,
sex text,
city text，
address text,
PRIMARY KEY (id)
) WITH compression = {'class': 'ZstdCompressor'}; - 需求
對 姓名(name)、年齡(age)、性别(sex)、城市(city)、位址(address) 建立全文索引
CREATE SEARCH INDEX myIndex ON myTable WITH COLUMNS (name, age, sex, city, address); 注意：索引列的先後順序不影響，即索引列(c3, c2, c1)與索引列(c1, c2, c3)最終的效果是一緻的。
- 查詢
1）标準查詢語句
模糊查詢：SELECT * FROM myTable WHERE name LIKE '小%'
多元查詢排序：SELECT * FROM myTable WHERE city='杭州' AND age>=18 ORDER BY age ASC
多元查詢翻頁：SELECT * FROM myTable WHERE name='小劉' AND sex=false OFFSET 100 LIMIT 10 ORDER BY age DESC 查詢編譯層會自動将符合條件的查詢路由到索引節點，除了上述比較Native的查詢方式，我們同時提供更貼近搜尋的查詢方式
search_query
，後續的章節我們也會介紹到。
2）進階查詢語句
多元查詢排序：SELECT * FROM myTable WHERE search_query='+city:杭州 +age:[18 TO *] ORDER BY age ASC'
文字檢索：SELECT * FROM myTable WHERE search_query='address:西湖區' 從上面的例子可以看到，SearchIndex的使用非常簡單，基本可以做到拿來即用。
4.2 适用場景
SearchIndex在阿裡内部已經成功應用多個業務場景，目前該特性在公有雲上已經釋出，支援的重要功能清單如下：
1）多元查詢：多個條件任意組合的精确查詢、範圍查詢等。
2）通配符查詢：* 代表任意個字元；? 代表任意單個字元。
3）統計聚合：求最小值、求最大值、求和、求平均值、統計行數。
4）排序分頁：任意索引列的排序輸出。
5）文本分詞：支援中文/英文分詞，分隔符分詞，拼音分詞等。
6）地理位置：距離查詢、長方形/多邊形範圍查詢。（即将到來）
有了這些功能，可以很容易的将Lindorm應用到多樣化的業務場景中，目前我們已經在公有雲上積累了大量的客戶案例，經典的使用場景主要有以下幾個：
1）訂單詳情，例如物流訂單、交易賬單，支援訂單的多元查詢、排序等。
2）标簽畫像，例如基于商家對買家進行标簽圈選，定向投遞資訊。
3）文本搜尋：例如日志分析，異常資訊檢索等。
4.3 實作原理
Lindorm作為一款多模資料庫，同時支援多種模型，在總結過往的經驗和業界實踐後，我們将搜尋引擎與寬表模型深度融合，對外提供簡單易用的SearchIndex，整體的分層架構如下：
- 查詢接入：由多個QueryProcessor節點組成，主要負責查詢接入，進行SQL解析，基于RBO自動選擇合适的索引。
- 索引預處理：基于索引列的元資訊将新插入或者更新的原始資料轉換為索引資料，并且針對不同的場景可以選擇與之比對的Mutability屬性，比較典型的例如日常監控，資料寫入後不更新，可以選擇Immutable模式，直接生成索引原始資料；而那些有狀态的資料，大多需要局部更新，此時通過回讀曆史資料組裝成索引原始資料，并且能夠支援業務自定義時間戳的寫入，確定資料不亂序。
- 索引同步：對于最終一緻模式(預設)，LTS(Lindorm Tunnel Service)作為Lindorm生态的資料同步服務，具備高效的實時同步和全量遷移能力。可以實時監聽WAL的變化，将索引原始資料轉換後寫入到搜尋引擎，同時支援一讀多寫，即一份WAL可以同步到多個索引表中，極大提升同步效率；對于強一緻模式，索引原始資料建構完畢後同步寫入到搜尋引擎，由搜尋引擎實時生成全文索引，為業務提供寫入即可查的強一緻體驗。
- 索引引擎：由多個節點組成的分布式Lucene叢集，資料按照Hash或者Range來劃分為多個Shard，對外提供全文檢索能力。
- 索引存儲：索引資料存儲在分布式檔案系統Lindorm DFS上，存算分離的架構具有極好的擴充性，同時存儲層的透明壓縮和智能冷熱分離可以顯著降低索引的存儲成本。
4.4 核心特性
4.4.1 Online DDL Operations
作為一個分布式資料庫，Lindorm可以橫向擴充支援高達億次每秒的處理能力，如果我們的索引DDL需要阻塞DML，對高并發的業務應用影響将會被放大。借助Lindorm的分布式中繼資料管理，SearchIndex通過合理的擴充，可以支援線上DDL操作，并且不會破壞資料的完整性。
1）動态增加、删除索引列
在寬表的應用場景中，列可能不會固定，尤其是标簽畫像場景，需要經常性的增加或删除索引列。SearchIndex提供Java API/CQL接口來動态操作索引列。
2）線上變更索引列屬性
每個索引列支援多種屬性：indexed（是否索引，預設true）、stored（是否存儲原始值，預設false）、docvalues（是否維護正排索引，預設true）、分詞類型等。例如某個索引列起初并未設定stored，那麼在索引表中是不會存儲原始值的，服務端會自動回查Lindorm寬表擷取原始資料。此時，可以通過接口變更索引列的stored為true。
3）動态修改壓縮
Lindorm寬表在建立時可以設定壓縮算法（例如ZSTD、Snappy），也可以建立表後動态修改。SearchIndex是一個獨立的索引表，底層依賴Lucene，僅支援LZ4和ZLIB兩種壓縮算法，為了保證原始主表與索引表的屬性統一，我們通過修改Lucene，讓其支援ZSTD、Snappy壓縮算法。是以，在修改原始主表壓縮算法時，也會關聯修改SearchIndex，有效降低索引的存儲大小。
4）動态修改TTL
為了自動淘汰曆史資料，Lindorm支援動态修改表的TTL，例如設定TTL=30days，代表從此刻起30天前的資料将會被淘汰，并且無法查詢。我們在Lucene的基礎上實作了行級TTL能力，可以與原始主表的TTL關聯，自動淘汰過期資料，確定主表和索引表的資料一緻。
5）動态修改索引表狀态
索引表的狀态主要有三種：DISABLED（不可寫，不可查）、BUILDING（可寫不可查）、ACTIVE（可寫可查）。在建立、删除索引或者對曆史資料建構索引時，我們經常需要動态變更索引的狀态，此時也不能夠影響到運作中的DML請求。
4.4.2 多一緻性
Lindorm寬表針對不同的業務場景，使用一套架構提供了不同的資料一緻性模型，常用的是EC和SC模式：
1）最終一緻 Eventual Consistency
資料寫入後，可能需要等待一段時間後(ms，通常就近讀取最新資料)才能被讀到，可以規避任何毛刺和抖動。
2）強一緻 Strong Consistency
資料寫入後，可以立即讀到。
在設計SearchIndex時，針對不同的業務場景，我們也提供了多一緻性的支援。
1）最終一緻性（預設）
1.1）使用者寫入操作成功傳回後，原表資料立即可見，索引表資料不保證立即可查，需要等待一定的時間（可調節的時間，最低可配置為1秒）。
1.2）可見時間=LTS同步時間(ms)+搜尋引擎資料可見時間(最低1秒)。
2）強一緻性
2.1）使用者寫入操作成功傳回後，主表和索引表中的資料一定可見，依賴Lindorm Search的
實時可查
特性，可參考下面章節的介紹。
2.2）寫入過程中，或者寫入未成功（抛錯或者逾時）時：不保證主表和索引表資料同時可見，但可以保證最終一緻性，主表和索引表資料要麼全執行成功，要麼全不執行。
4.4.3 可選的索引建構成本
索引可以加速查詢，助力業務進一步挖掘資料的價值，但它不是銀彈，會帶來寫入成本和存儲成本的增加。我們可以通過多種高效的壓縮算法顯著降低索引的存儲體積，但如何降低索引建構對寫入吞吐的影響呢？
上面是資料寫入的主要流程，其中
索引WAL的建構
快慢将直接影響到原始資料的寫入性能。Lindorm寬表是一個KV資料庫，天然支援更新部分列，但是搜尋引擎Lucene隻能整行更新，不能夠局部更新。是以，在建構索引時需要回讀原表擷取曆史資料，才能夠拼接出完整的索引WAL。我們将這個回讀操作按照業務場景進行分類，支援不同的選擇。
1）IMMUTABLE（成本最低）
1.1）适用場景：資料隻增不删的場景（可以TTL淘汰資料）。例如監控資料/日志資料，資料寫入後不會更新和删除。
1.2）索引建構非常高效，不需要回查舊資料，直接依據目前的資料生成索引。
2）MUTABLE_LATEST（成本中等）
2.1）适用場景：普适的場景，大衆的選擇（除UDT）。
2.2）例如索引列為c1,c2，第一次寫入c1列，第二次寫入c2列。那麼在第二次寫入c2的值時，需要讀出原始的c1值，才能夠拼接出完整的索引資料c1,c2。
3）MUTABLE_ALL（成本最高）
3.1）适用場景：寫入資料時，業務自定義時間戳（User-Defined Timestamp）。例如：全量任務和增量并存的場景，往往需要在全量任務時攜帶時間戳，這樣可以確定不會覆寫增量寫入的資料
3.2）存儲引擎層每個KV都有時間戳，如果業務寫入時沒有顯示的設定，服務端會自動設定為系統時間戳，遵循"時間戳大的優先可見"的原則。
3.3）業務自定義時間戳的寫入，在建構索引時需要擷取到所有的曆史資料（包括删除的資料），才能準确判斷目前的寫入是否為有效資料。如果時間戳小，則直接丢棄掉，不建構索引。
4.4.4 高效同步
在最終一緻性的模型中，索引資料同步依賴LTS服務。LTS服務作為Lindorm生态的資料通道，具備高效的實時同步和全量遷移能力，寫入寬表的資料，可以在毫秒内感覺到，快速的同步到搜尋引擎中。
1）同步可視化。LTS提供WEB通路，可以檢視到索引同步的詳細資訊。例如同步的耗時、索引表資訊、同步的資料量等。另外，LTS可以将這些資訊對外吐出監控名額，對接告警體系，實時監測同步鍊路的健康度。
2）同步高效率。LTS内部通過高并發的生産者/消費者模式，支援快速消化大量的資料，一份WAL隻需要讀取一次。并且支援橫向擴充，新加入的節點可以快速加入到同步鍊路中，加速索引資料的同步。
3）WAL保序。通過隐藏的時間戳屬性，保證在寬表中先寫入的資料先寫入搜尋，後寫入的資料後寫入搜尋，確定寬表和搜尋的資料一緻性，徹底解決LilyIndexer存在的資料錯亂問題。
4）全量建構快。對于已有的曆史資料，可以借助LTS的全量任務運作機制，高效的從寬表中擷取原始資料生成索引，TB級别的資料量分鐘内即可完成索引建構。
5）資料快速校驗。支援對已有資料的比對校驗，可以快速篩選出不一緻的索引資料，幫助業務及時發現問題。
4.4.5 索引實時可見（RealTime Search）
寫入成功後的索引資料可以立即可查，我們稱之為索引的實時可見，是一種強一緻的模型。SearchIndex底層依賴Lucene，Lucene有一個明顯的"缺陷"：資料寫入後不能立即可查，必須要顯示的執行Flush或者Commit操作才可以查詢到。這導緻基于Lucene的服務無法應用到實時業務場景，隻能适用于監控、日志等弱實時的場景。在業界，基于Lucene的分布式搜尋引擎Elasticsearch/Solr為了緩解這個問題，提供
近實時查詢（NRT）
功能，可以確定索引資料在某個時間範圍内（通常在秒級）一定可查，但還是達不到實時性的要求。
為了解決
寫入的資料無法立即可查
的問題，我們基于Lucene實作了一種索引實時可見的方案，通過精細化的資料結構設計和動态的記憶體管理機制，可以保證索引資料一旦寫入成功後可以立即查詢到，真正做到實時性。
4.4.6 CQL API
CQL是Cassandra的官方查詢語言，是一種适合NoSQL資料庫特點的SQL方言，由于Lindorm無縫相容Cassandra，面向客戶我們預設推薦使用CQL來通路SearchIndex。當然，集團内部使用者也可以繼續使用Lindorm的TableService API來通路SearchIndex
1）DDL
1.1）建立索引
CREATE SEARCH INDEX index_name [ IF NOT EXISTS ] ON [keyspace_name.]table_name
| [ WITH [ COLUMNS （column1,...,columnn） ]
| [ WITH [ COLUMNS （*） ] 1.2）删除索引
DROP SEARCH INDEX [IF EXISTS] ON [keyspace_name.]table_name; 1.3）重構索引
REBUILD SEARCH INDEX [IF EXISTS] ON [keyspace_name.]table_name; 1.4）修改索引
ALTER SEARCH INDEX SCHEMA [IF EXISTS] ON [keyspace_name.]table_name
( ADD column_name
| DROP column_name) ; 2）DML
2.1）标準查詢，WHERE後面緊跟具體的條件。
2.2）search_query查詢，文法如下：
SELECT selectors
FROM table
WHERE (indexed_column_expression | search_query = 'search_expression')
[ LIMIT n ]
[ ORDER BY column_name ] 當标準的查詢文法無法滿足檢索需求時，可以考慮通過
search_query
來直接從搜尋引擎中檢索資料，使用的文法也是Lucene的文法。例如，下面的用例中，相當于檢索city為'hangzhou'，并且age在1到18（包含）的資料。
SELECT name,id FROM myTable WHERE search_query = '+city:hangzhou +age:[1 TO 18]'; 詳細的CQL文法，可參考
文法介紹五、案例介紹
Lindorm經過多年的發展和曆練，在集團内部和公有雲形成了良好的口碑，通過不斷的夯實存儲引擎，讓業務資料真真正正的"存得起"，
海量資料存儲找Lindorm
已成為各個業務選型的重要參考，非常感謝各位業務方的信任與支援。除了支援淘寶、支付寶、菜鳥、優酷、高德等業務中的核心應用外，我們也在不斷探索新的業務場景，今天介紹的SearchIndex特性可以進一步讓業務資料"看得見"，隻有看得見才能挖掘資料的價值，形成資料驅動業務的良性循環。特性上線之後受到了很多使用者的喜愛，在此也列舉下目前線上上跑的一些場景，幫助大家進一步了解SearchIndex的使用場景。
5.1 訂單場景
不管是傳統行業，還是網際網路行業，訂單資料的存儲是核心需求。而且訂單資料往往有其特殊的天然屬性：
- 高增長：資料可能随時會爆發式的增長，例如雙11或大促節日。
- 低成本：訂單資料一般不會直接産生經濟效益，是業務對外呈現的附加價值，需要低成本存儲。
- 多元查詢：對于C端使用者而言，往往會從不同角度對訂單進行分類、标記以及檢視和過濾自己的訂單。
在之前，面對上面的訴求，一般的解決方案就是MySQL+搜尋引擎。業務雙寫到兩個系統中，或者借助binlog進行實時同步，查詢時分别從不同的系統中擷取結果。随着資料量的增長，可能會演變為MySQL熱資料+Lindorm冷資料+搜尋引擎的架構，基于多套系統可以有效解決業務問題，但需要面臨多套系統維護的時間成本和人力成本。
現在，一套Lindorm即可解決問題，不用關心資料的流轉，統一的API通路。
1）通過冷熱分離、壓縮優化等手段顯著降低存儲成本。
2）橫向彈性擴充适應海量資料的寫入。
3）SearchIndex CQL提供豐富的查詢文法。
客戶群體：物流、第三方支付、移動出行。
某物流公司基于Lindorm實作的訂單查詢系統。
5.2 使用者畫像
使用者畫像的資料一般有兩種：一個是基礎資料，另一個是經過分析得到的标簽資料。這些資料可以被應用到營銷、推薦等場景中，可以助力企業營收快速增長。畫像資料的主要痛點如下：
- 資料量大：畫像資料與使用者基數強相關，往往在千萬甚至億級别，而且資料次元非常高，在我們服務的客戶中，有的場景支援的标簽數在5000個以上。
- 高并發。畫像資料通常需要全量重新整理，需要在基線的時間内完成才能有效輔助後續的推薦、廣告投放等。
- 動态列。資料次元在不斷的變化中，是以需要支援動态增/删列。
- 多元查詢。面向不同的業務需求，畫像資料查詢需求也會有差異，營運人員通常會統計任意一個次元的資料。
畫像場景一般沒有強事務需求，而是大資料量、高并發讀寫的場景，關系資料庫不太适合。Lindorm作為一款NoSQL資料庫，非常适合這樣的場景。
1）多列族、動态列、TTL等特性，适合表結構不固定，經常需要進行變更的業務場景。
2）高性能吞吐。
3）SearchIndex CQL支援任意次元的查詢和統計。
客戶群體：線上教育、網際網路車險。
某線上教育公司基于Lindorm實作的學生畫像系統。
5.3 日志檢索
日志的來源非常廣泛，例如系統日志、資料庫審計日志、使用者行為日志等，這些資料在網際網路公司中通常存儲于開源Elasticsearch（ES）中，借助ELK體系建構一站式的日志平台。但ES的存儲成本是非常高的，而且存儲和計算往往需要同機部署，在海量資料下系統運維面臨非常多的挑戰，資料遷移、節點擴縮容等都需要人工介入。多模資料庫Lindorm的SearchIndex是日志檢索場景的更優選擇，通過寬表引擎存儲海量資料降低成本，搜尋引擎建構合适的索引加速查詢，統一的API操作進一步降低業務開發成本。
客戶群體：日志資料量大、成本敏感的客戶。
六、總結與展望
SearchIndex作為Lindorm寬表的一種新型索引，進一步增強了寬表的查詢能力，業務使用統一的CQL API即可享受SearchIndex帶來的查詢便利，無需感覺底層的多模引擎以及資料同步問題。未來，我們将在以下方面繼續發力：
1）持續豐富SearchIndex的查詢能力，例如：支援地理位置查詢等。
2）SearchIndex Serverless隔離排程，持續降低業務接入成本。
3）融合時序引擎，加速時序引擎的tag檢索等。
七、結語
感謝大家百忙之中閱讀文章，同時非常歡迎大家咨詢使用，SearchIndex的使用文檔，可參考
使用手冊，技術交流歡迎加入釘群：35977898
同時，也熱烈歡迎有興趣的同學加入我們，一起建設雲原生多模資料庫Lindorm，職位介紹請
參考連結