日韩熟女视频,亚洲AV无码无线在线观看护士,天堂男人在线视频,精品人妻一区二区三区阅读全文,亚洲天堂一区二区三区,成人久久影院,天堂一区二区三区18在线观看 ,91成人电影在线

一.引言

Lindorm提供海量數(shù)據(jù)下的高性能、低成本、彈性的存儲(chǔ)能力，被廣泛應(yīng)用在風(fēng)控、推薦、歷史訂單等場(chǎng)景中，成為阿里經(jīng)濟(jì)體的核心數(shù)據(jù)庫(kù)產(chǎn)品之一。隨著集團(tuán)云化的戰(zhàn)略推進(jìn)和云原生時(shí)代的到來(lái)，為了更好的服務(wù)內(nèi)外客戶，Lindorm品牌全新升級(jí)，融合寬表、時(shí)序、搜索、文件四種模型，演變?yōu)橐豢钤圃嗄?shù)據(jù)庫(kù)，關(guān)于Lindorm的產(chǎn)品介紹，可參考存的起，看得見—云原生多模數(shù)據(jù)庫(kù)Lindorm技術(shù)解析。

寬表模型兼容開源HBase接口，適合存儲(chǔ)海量數(shù)據(jù)，并提供極高吞吐的鍵值查詢。本篇文章介紹的全文索引SearchIndex是依托搜索引擎為寬表模型提供更高級(jí)的查詢能力，是Lindorm寬表引擎和搜索引擎的深度融合特性。本文主要介紹SearchIndex的技術(shù)原理和核心能力，分享過去我們遇到的關(guān)鍵問題以及解決思路。

什么是SearchIndex？
1）Lindorm寬表的一種新型索引，用來(lái)加速多條件查詢，是Lindorm在數(shù)據(jù)可見性上的全新探索。
2）索引引擎基于Lucene，可同時(shí)提供倒排和正排索引，具備多維查詢、文本檢索等基礎(chǔ)功能。

二.現(xiàn)狀與挑戰(zhàn)

2.1 多樣化的數(shù)據(jù)查詢需求

Lindorm依托其彈性的擴(kuò)展能力和低成本，成為海量數(shù)據(jù)存儲(chǔ)的首選，在過去的2020年，Lindorm數(shù)據(jù)存儲(chǔ)規(guī)模接近400PB，平均壓縮率在5:1。在海量數(shù)據(jù)存儲(chǔ)的背景下，伴隨著云原生、5G/IOT時(shí)代的到來(lái)，新的業(yè)務(wù)模型在不斷涌現(xiàn)，除了簡(jiǎn)單的主鍵查詢和范圍查詢外，簡(jiǎn)單分析、多維檢索成為業(yè)務(wù)的基本需求。

以Lindorm客戶收錢吧的線上訂單場(chǎng)景為例，每天接近5千萬(wàn)筆訂單數(shù)據(jù)，需要保存3年之久，通過Lindorm的冷熱分離、生命周期自動(dòng)管理以及高效壓縮顯著的降低了業(yè)務(wù)的存儲(chǔ)成本，良好的擴(kuò)展性可以隨時(shí)應(yīng)對(duì)業(yè)務(wù)峰值，毫秒級(jí)獲取訂單詳情。隨著業(yè)務(wù)的發(fā)展，訂單系統(tǒng)需要提供更豐富的查詢?nèi)肟?，幫助商家從多個(gè)維度檢索出訂單列表，并進(jìn)行基礎(chǔ)的統(tǒng)計(jì)分析，可以結(jié)算每天的營(yíng)業(yè)總額、總的訂單數(shù)，以及歷史的曲線變化。如何高效的支持這些多樣化的查詢是Lindorm在服務(wù)眾多客戶過程中需要重點(diǎn)解決的，常見的一些查詢需求如下：

1）多維查詢。即席查詢(adhoc)，一般是不固定的列隨機(jī)組合。
2）count計(jì)數(shù)。獲取數(shù)據(jù)表的總行數(shù)，或者返回一次查詢命中的數(shù)據(jù)條數(shù)。
3）指定列排序。按照指定列降序或升序，比方說(shuō)按照訂單時(shí)間降序輸出結(jié)果。
4）分詞檢索。支持文本字段的分詞檢索，返回相關(guān)性較高的結(jié)果數(shù)據(jù)。
5）統(tǒng)計(jì)聚合。按照某個(gè)字段進(jìn)行聚類統(tǒng)計(jì)，求取sum/max/min/avg等，或者返回去重后的結(jié)果集。
6）模糊查詢。查詢以'阿里'開頭的數(shù)據(jù)，可以匹配出'阿里巴巴'的結(jié)果集，類似MySQL的like語(yǔ)法。

諸如此類的海量數(shù)據(jù)低成本存儲(chǔ)+檢索多樣化的需求成為越來(lái)越多業(yè)務(wù)的基本訴求，如何在Lindorm系統(tǒng)本身的高擴(kuò)展、低成本的優(yōu)勢(shì)之上，同時(shí)去支撐業(yè)務(wù)的多樣化查詢場(chǎng)景，成為客戶和我們一直思考去解決的問題。

2.2 Lindorm現(xiàn)有方案

面對(duì)復(fù)雜的查詢需求，在Lindorm上的用戶通常會(huì)選擇如下幾個(gè)解決方案：

1）主鍵索引。Lindorm天然具備主鍵索引，可以很好的滿足業(yè)務(wù)基于主鍵的整行匹配、前綴匹配、范圍查詢等場(chǎng)景。
2）原生二級(jí)索引。在多維查詢的場(chǎng)景中，通過創(chuàng)建多個(gè)二級(jí)索引來(lái)滿足。二級(jí)索引適用查詢模式較為固定的場(chǎng)景，一個(gè)主表建議控制在5個(gè)二級(jí)索引表以內(nèi)最佳。
3）聚合Aggregate。使用Lindorm Aggregate語(yǔ)法，支持count/sum/avg/min/max。
4）自然排序。當(dāng)前僅支持主鍵列或索引列排序，按照最左前綴匹配，只能排序等值查詢后的第一個(gè)主鍵列或索引列。例如：

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;  // 非法

主鍵和索引的設(shè)計(jì)遵循最左前綴匹配，關(guān)于二級(jí)索引可參考高性能原生二級(jí)索引。

5）Like查詢。對(duì)于字符串類型的數(shù)據(jù)，可以使用Lindorm Like語(yǔ)法實(shí)現(xiàn)模糊查詢，支持通配符%和_。

上述方案最大的優(yōu)點(diǎn)就是簡(jiǎn)單、開發(fā)便捷，但不可避免在規(guī)模和成本制約下，會(huì)存在瓶頸，例如全表的count需要消耗大量IO資源、過多的二級(jí)索引會(huì)導(dǎo)致寫入吞吐的下降。如何在有限的資源下盡可能高效的滿足業(yè)務(wù)復(fù)雜查詢的訴求成為我們下一步重點(diǎn)考慮的問題，業(yè)界同樣也面臨這樣的問題。

2.3 業(yè)界解決方案

搜索引擎是解決復(fù)雜查詢的最佳實(shí)踐之一，業(yè)界通常會(huì)選擇將數(shù)據(jù)轉(zhuǎn)儲(chǔ)到搜索引擎Elasticsearch/Solr中，或者內(nèi)置Lucene引擎來(lái)提供復(fù)雜查詢的支持。

1）數(shù)據(jù)轉(zhuǎn)儲(chǔ)到外部搜索引擎

1.1）應(yīng)用雙寫
數(shù)據(jù)雙寫是最為簡(jiǎn)單的實(shí)現(xiàn)方式，通過前端接入Kafka等消息系統(tǒng)，多個(gè)消費(fèi)者雙寫到不同的應(yīng)用系統(tǒng)中。在我們接觸的客戶中，有非常多的業(yè)務(wù)是雙寫HBase和Elasticsearch/Solr，查詢時(shí)，先從搜索引擎中查詢出主鍵，然后回查HBase獲取完整的結(jié)果數(shù)據(jù)。雖然簡(jiǎn)單快捷，但不可避免會(huì)面臨非常多的痛點(diǎn)。

開發(fā)成本高。需要學(xué)習(xí)理解兩套系統(tǒng)的API，多語(yǔ)言的支持也不盡相同。
資源消耗高。雙寫相當(dāng)于寫入雙份的數(shù)據(jù)，客戶端需要更多的資源才可以確保兩套系統(tǒng)的寫入均衡，防止出現(xiàn)木桶效應(yīng)影響全局的寫入穩(wěn)定。
缺少數(shù)據(jù)一致性保障。任何一個(gè)系統(tǒng)的數(shù)據(jù)寫入失敗需要自主處理重試，否則會(huì)導(dǎo)致數(shù)據(jù)丟失；HBase支持部分更新，而搜索引擎只能整行更新，因此更新場(chǎng)景必須讀取出原始數(shù)據(jù)才能組裝出索引數(shù)據(jù)，這在高并發(fā)的寫入場(chǎng)景下很容易出現(xiàn)數(shù)據(jù)不一致問題。

1.2）數(shù)據(jù)自動(dòng)同步（LilyIndexer+Apache Solr）
開源HBase可以借助LilyIndexer將數(shù)據(jù)同步到Solr中提供全文檢索的能力，它的基本架構(gòu)如下圖，整體的流程是：先通過HBase Replication（數(shù)據(jù)復(fù)制）將表的WAL日志數(shù)據(jù)推送到LilyIndexer，LilyIndexer按照事先配置好的映射Schema解析出數(shù)據(jù)，最后同步寫入到Solr中。

圖片1.jpg

通過自動(dòng)同步省去了業(yè)務(wù)客戶端的開發(fā)成本，但同時(shí)也會(huì)帶來(lái)維護(hù)的復(fù)雜。

運(yùn)維復(fù)雜，難以維護(hù)。LilyIndexer已經(jīng)多年無(wú)人維護(hù)，鏈路操作比較繁瑣，需要同時(shí)操作三個(gè)服務(wù)HBase/LilyIndexer/Solr。目前主要是大數(shù)據(jù)發(fā)布商Cloudera內(nèi)部維護(hù)，沒有形成應(yīng)用生態(tài)。
同步效率低，鏈路不可見。一行數(shù)據(jù)寫入到HBase后，需要經(jīng)過多次序列化/反序列化才能寫入Solr，整個(gè)過程高度依賴HBase的Replication能力，很容易達(dá)到瓶頸；同時(shí)，每個(gè)HBase表的Replication通道彼此隔離，如果有多張表需要同步，那么一個(gè)WAL將會(huì)被重復(fù)讀取多次，存在嚴(yán)重的木桶效應(yīng)，給HDFS帶來(lái)無(wú)效的IO壓力。并且同步鏈路是個(gè)黑盒，一旦出現(xiàn)同步阻塞，只能從后臺(tái)運(yùn)行日志中查看原由。
數(shù)據(jù)一致性難以保障。HBase支持多版本，每個(gè)KV都具有獨(dú)立的時(shí)間戳ts，可以確保時(shí)間戳ts大的優(yōu)先可見。但是在Solr中并沒有時(shí)間戳的概念，數(shù)據(jù)以后寫的為準(zhǔn)。加之HBase Replication消費(fèi)WAL存在亂序的問題，就會(huì)導(dǎo)致數(shù)據(jù)寫入Solr的順序錯(cuò)亂，引起HBase表的數(shù)據(jù)與Solr索引數(shù)據(jù)的不一致。

2）內(nèi)置搜索引擎
通過對(duì)架構(gòu)重新設(shè)計(jì)，內(nèi)嵌搜索引擎的支持，從而達(dá)到系統(tǒng)的整體統(tǒng)一，這樣既能繼承原始的查詢功能，又可以擴(kuò)展支持較為復(fù)雜的查詢。例如MongoDB，開源的版本不具備全文檢索的能力，只提供基礎(chǔ)的Text索引功能，而它背后的公司MongoDB Inc.推出的企業(yè)版Atlas新增一個(gè)Search的功能，依托Lucene實(shí)現(xiàn)了全文檢索的能力。最初由Facebook開源的分布式NoSQL數(shù)據(jù)庫(kù)Cassandra同樣是在架構(gòu)上進(jìn)行升級(jí)，開源的Solandra方案便是引入搜索引擎Solr解決復(fù)雜的查詢問題，其背后的公司Datastax也是在此基礎(chǔ)上推出商業(yè)化的DSE Search特性，它的基本架構(gòu)如下圖，通過深度修改Cassandra和Solr的源碼，將兩者融合在一個(gè)進(jìn)程中提供服務(wù)，對(duì)外提供統(tǒng)一的CQL查詢語(yǔ)法。

圖片2.png

將搜索引擎與原始架構(gòu)深度融合是一種非常好的方案，但也會(huì)面臨一系列的問題。

系統(tǒng)隔離性。運(yùn)行時(shí)的部署形態(tài)能否做到真正的隔離，搜索引擎的查詢對(duì)資源要求較高，如果缺少合理的資源配比，很容易出現(xiàn)資源的浪費(fèi)和運(yùn)行時(shí)的相互影響。
數(shù)據(jù)一致性。因?yàn)長(zhǎng)ucene天然的設(shè)計(jì)約束，數(shù)據(jù)寫入后無(wú)法立即可見，即使內(nèi)置搜索引擎沒有了數(shù)據(jù)同步的延遲，依然無(wú)法提供強(qiáng)一致的語(yǔ)義，業(yè)務(wù)必須忍受最終一致帶來(lái)的訪問延遲。

通過對(duì)業(yè)界方案的調(diào)研分析，我們看到了一些優(yōu)秀的實(shí)踐以及融合Lucene過程中會(huì)存在的一些問題，為了解決這些問題，我們期望在Lindorm上設(shè)計(jì)一種新的索引，以數(shù)據(jù)庫(kù)特性的方式即開即用，幫助業(yè)務(wù)解決海量數(shù)據(jù)下的復(fù)雜查詢問題。

三.Lindorm SearchIndex 設(shè)計(jì)思路

索引通常用來(lái)加速查詢，可以通過增加一種新的索引類型來(lái)解決海量數(shù)據(jù)的復(fù)雜查詢問題，Lindorm作為一個(gè)多模數(shù)據(jù)庫(kù)，原生支持搜索引擎，天然具備全文索引能力。因此，我們通過融合搜索引擎，為L(zhǎng)indorm寬表增加了一種新型索引：SearchIndex。使得業(yè)務(wù)不感知底層的多個(gè)引擎以及數(shù)據(jù)的流轉(zhuǎn)，只需要申請(qǐng)一個(gè)新的索引即可解決復(fù)雜的查詢問題，就像使用Lindorm二級(jí)索引一樣方便快捷。SearchIndex重點(diǎn)構(gòu)建以下能力：

1）統(tǒng)一元數(shù)據(jù)
多套系統(tǒng)運(yùn)維復(fù)雜的根因是各自的元數(shù)據(jù)不統(tǒng)一，需要使用各自專用的命令才可以操作，例如在一個(gè)系統(tǒng)中建完表，還需要在另外一個(gè)系統(tǒng)中建索引。通過維護(hù)統(tǒng)一的分布式元數(shù)據(jù)，我們可以屏蔽掉不同引擎間的Schema差異，提供統(tǒng)一的命令完成DDL類的操作。

2）統(tǒng)一接口
多個(gè)系統(tǒng)間的接口存在差異，通過實(shí)現(xiàn)一套專有的統(tǒng)一接口可以有效降低開發(fā)的復(fù)雜度，但這也需要業(yè)務(wù)學(xué)習(xí)和理解新的接口，應(yīng)用開發(fā)成本沒有明顯的降低。SQL作為眾多數(shù)據(jù)庫(kù)系統(tǒng)的開發(fā)語(yǔ)言，使用和學(xué)習(xí)成本都較低，Lindorm SearchIndex原生支持類SQL接口：CQL，業(yè)務(wù)開發(fā)過程中不感知索引的存在，在使用體驗(yàn)上與原始的寬表訪問保持一致。

3）強(qiáng)一致性
數(shù)據(jù)在多個(gè)引擎間流轉(zhuǎn)必然會(huì)涉及到一致性問題，通常只能提供最終一致性的語(yǔ)義，數(shù)據(jù)的正確性和訪問延遲無(wú)法有效保障。Lindorm SearchIndex提供了最終一致性和強(qiáng)一致性兩種語(yǔ)義，對(duì)于訪問量大、數(shù)據(jù)延遲性要求不高的場(chǎng)景采用最終一致性，可以提供非常高的吞吐和可用性，而業(yè)務(wù)訪問延遲敏感的業(yè)務(wù)可以選擇強(qiáng)一致性模型，數(shù)據(jù)寫入成功后，索引立即可查。

4）資源隔離
異構(gòu)系統(tǒng)對(duì)資源的使用各不相同，必須建立有效的隔離機(jī)制確保資源使用最大化，Lindorm通過存儲(chǔ)和索引分離的模式來(lái)保障系統(tǒng)的健壯和彈性。寬表引擎負(fù)責(zé)存儲(chǔ)原始數(shù)據(jù)，具備極低的存儲(chǔ)成本，搜索引擎負(fù)責(zé)索引和檢索，兩個(gè)引擎可以配置不同的CPU、內(nèi)存資源，并且可以獨(dú)立擴(kuò)縮容。

接下來(lái)，我們將重點(diǎn)介紹SearchIndex的架構(gòu)設(shè)計(jì)以及具體的功能實(shí)現(xiàn)。

四.Lindorm SearchIndex 功能解析

4.1 使用舉例

SearchIndex的使用非常簡(jiǎn)單，創(chuàng)建索引表時(shí)只需要枚舉出索引列名即可，查詢時(shí)不需要感知索引表的存在。下面先給出一個(gè)具體的例子，介紹如何使用Lindorm CQL(CQL是Cassandra的查詢語(yǔ)言，Lindorm無(wú)縫兼容Cassandra API)操作SearchIndex。

圖片3.jpeg

原始表

CREATE TABLE myTable (
    id bigint,
    name text,
    age int,
    sex text,
    city text，
    address text,
    PRIMARY KEY (id)
) WITH compression = {'class': 'ZstdCompressor'};

需求

對(duì) 姓名(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）標(biāo)準(zhǔn)查詢語(yǔ)句

模糊查詢：SELECT * FROM myTable WHERE name LIKE '小%'
多維查詢排序：SELECT * FROM myTable WHERE city='杭州' AND age>=18 ORDER BY age ASC
多維查詢翻頁(yè)：SELECT * FROM myTable WHERE name='小劉' AND sex=false OFFSET 100 LIMIT 10 ORDER BY age DESC

查詢編譯層會(huì)自動(dòng)將符合條件的查詢路由到索引節(jié)點(diǎn)，除了上述比較Native的查詢方式，我們同時(shí)提供更貼近搜索的查詢方式search_query，后續(xù)的章節(jié)我們也會(huì)介紹到。

2）高級(jí)查詢語(yǔ)句

多維查詢排序：SELECT * FROM myTable WHERE search_query='+city:杭州 +age:[18 TO *] ORDER BY age ASC'
文本檢索：SELECT * FROM myTable WHERE search_query='address:西湖區(qū)'

從上面的例子可以看到，SearchIndex的使用非常簡(jiǎn)單，基本可以做到拿來(lái)即用。

4.2 適用場(chǎng)景

SearchIndex在阿里內(nèi)部已經(jīng)成功應(yīng)用多個(gè)業(yè)務(wù)場(chǎng)景，當(dāng)前該特性在公有云上已經(jīng)發(fā)布，支持的重要功能列表如下：

1）多維查詢：多個(gè)條件任意組合的精確查詢、范圍查詢等。
2）通配符查詢：* 代表任意個(gè)字符；? 代表任意單個(gè)字符。
3）統(tǒng)計(jì)聚合：求最小值、求最大值、求和、求平均值、統(tǒng)計(jì)行數(shù)。
4）排序分頁(yè)：任意索引列的排序輸出。
5）文本分詞：支持中文/英文分詞，分隔符分詞，拼音分詞等。
6）地理位置：距離查詢、長(zhǎng)方形/多邊形范圍查詢。（即將到來(lái)）

有了這些功能，可以很容易的將Lindorm應(yīng)用到多樣化的業(yè)務(wù)場(chǎng)景中，當(dāng)前我們已經(jīng)在公有云上積累了大量的客戶案例，經(jīng)典的使用場(chǎng)景主要有以下幾個(gè)：

1）訂單詳情，例如物流訂單、交易賬單，支持訂單的多維查詢、排序等。
2）標(biāo)簽畫像，例如基于商家對(duì)買家進(jìn)行標(biāo)簽圈選，定向投遞信息。
3）文本搜索：例如日志分析，異常信息檢索等。

4.3 實(shí)現(xiàn)原理

Lindorm作為一款多模數(shù)據(jù)庫(kù)，同時(shí)支持多種模型，在總結(jié)過往的經(jīng)驗(yàn)和業(yè)界實(shí)踐后，我們將搜索引擎與寬表模型深度融合，對(duì)外提供簡(jiǎn)單易用的SearchIndex，整體的分層架構(gòu)如下：

圖片4.png

查詢接入：由多個(gè)QueryProcessor節(jié)點(diǎn)組成，主要負(fù)責(zé)查詢接入，進(jìn)行SQL解析，基于RBO自動(dòng)選擇合適的索引。
索引預(yù)處理：基于索引列的元信息將新插入或者更新的原始數(shù)據(jù)轉(zhuǎn)換為索引數(shù)據(jù)，并且針對(duì)不同的場(chǎng)景可以選擇與之匹配的Mutability屬性，比較典型的例如日常監(jiān)控，數(shù)據(jù)寫入后不更新，可以選擇Immutable模式，直接生成索引原始數(shù)據(jù)；而那些有狀態(tài)的數(shù)據(jù)，大多需要局部更新，此時(shí)通過回讀歷史數(shù)據(jù)組裝成索引原始數(shù)據(jù)，并且能夠支持業(yè)務(wù)自定義時(shí)間戳的寫入，確保數(shù)據(jù)不亂序。
索引同步：對(duì)于最終一致模式(默認(rèn))，LTS(Lindorm Tunnel Service)作為L(zhǎng)indorm生態(tài)的數(shù)據(jù)同步服務(wù)，具備高效的實(shí)時(shí)同步和全量遷移能力?？梢詫?shí)時(shí)監(jiān)聽WAL的變化，將索引原始數(shù)據(jù)轉(zhuǎn)換后寫入到搜索引擎，同時(shí)支持一讀多寫，即一份WAL可以同步到多個(gè)索引表中，極大提升同步效率；對(duì)于強(qiáng)一致模式，索引原始數(shù)據(jù)構(gòu)建完畢后同步寫入到搜索引擎，由搜索引擎實(shí)時(shí)生成全文索引，為業(yè)務(wù)提供寫入即可查的強(qiáng)一致體驗(yàn)。
索引引擎：由多個(gè)節(jié)點(diǎn)組成的分布式Lucene集群，數(shù)據(jù)按照Hash或者Range來(lái)劃分為多個(gè)Shard，對(duì)外提供全文檢索能力。
索引存儲(chǔ)：索引數(shù)據(jù)存儲(chǔ)在分布式文件系統(tǒng)Lindorm DFS上，存算分離的架構(gòu)具有極好的擴(kuò)展性，同時(shí)存儲(chǔ)層的透明壓縮和智能冷熱分離可以顯著降低索引的存儲(chǔ)成本。

4.4 核心特性

4.4.1 Online DDL Operations

作為一個(gè)分布式數(shù)據(jù)庫(kù)，Lindorm可以橫向擴(kuò)展支持高達(dá)億次每秒的處理能力，如果我們的索引DDL需要阻塞DML，對(duì)高并發(fā)的業(yè)務(wù)應(yīng)用影響將會(huì)被放大。借助Lindorm的分布式元數(shù)據(jù)管理，SearchIndex通過合理的擴(kuò)展，可以支持在線DDL操作，并且不會(huì)破壞數(shù)據(jù)的完整性。

1）動(dòng)態(tài)增加、刪除索引列
在寬表的應(yīng)用場(chǎng)景中，列可能不會(huì)固定，尤其是標(biāo)簽畫像場(chǎng)景，需要經(jīng)常性的增加或刪除索引列。SearchIndex提供Java API/CQL接口來(lái)動(dòng)態(tài)操作索引列。

2）在線變更索引列屬性
每個(gè)索引列支持多種屬性：indexed（是否索引，默認(rèn)true）、stored（是否存儲(chǔ)原始值，默認(rèn)false）、docvalues（是否維護(hù)正排索引，默認(rèn)true）、分詞類型等。例如某個(gè)索引列起初并未設(shè)置stored，那么在索引表中是不會(huì)存儲(chǔ)原始值的，服務(wù)端會(huì)自動(dòng)回查L(zhǎng)indorm寬表獲取原始數(shù)據(jù)。此時(shí)，可以通過接口變更索引列的stored為true。

3）動(dòng)態(tài)修改壓縮
Lindorm寬表在創(chuàng)建時(shí)可以設(shè)置壓縮算法（例如ZSTD、Snappy），也可以創(chuàng)建表后動(dòng)態(tài)修改。SearchIndex是一個(gè)獨(dú)立的索引表，底層依賴Lucene，僅支持LZ4和ZLIB兩種壓縮算法，為了保證原始主表與索引表的屬性統(tǒng)一，我們通過修改Lucene，讓其支持ZSTD、Snappy壓縮算法。因此，在修改原始主表壓縮算法時(shí)，也會(huì)聯(lián)動(dòng)修改SearchIndex，有效降低索引的存儲(chǔ)大小。

4）動(dòng)態(tài)修改TTL
為了自動(dòng)淘汰歷史數(shù)據(jù)，Lindorm支持動(dòng)態(tài)修改表的TTL，例如設(shè)置TTL=30days，代表從此刻起30天前的數(shù)據(jù)將會(huì)被淘汰，并且無(wú)法查詢。我們?cè)贚ucene的基礎(chǔ)上實(shí)現(xiàn)了行級(jí)TTL能力，可以與原始主表的TTL聯(lián)動(dòng)，自動(dòng)淘汰過期數(shù)據(jù)，確保主表和索引表的數(shù)據(jù)一致。

5）動(dòng)態(tài)修改索引表狀態(tài)
索引表的狀態(tài)主要有三種：DISABLED（不可寫，不可查）、BUILDING（可寫不可查）、ACTIVE（可寫可查）。在創(chuàng)建、刪除索引或者對(duì)歷史數(shù)據(jù)構(gòu)建索引時(shí)，我們經(jīng)常需要?jiǎng)討B(tài)變更索引的狀態(tài)，此時(shí)也不能夠影響到運(yùn)行中的DML請(qǐng)求。

4.4.2 多一致性

Lindorm寬表針對(duì)不同的業(yè)務(wù)場(chǎng)景，使用一套架構(gòu)提供了不同的數(shù)據(jù)一致性模型，常用的是EC和SC模式：

1）最終一致 Eventual Consistency
數(shù)據(jù)寫入后，可能需要等待一段時(shí)間后(ms，通常就近讀取最新數(shù)據(jù))才能被讀到，可以規(guī)避任何毛刺和抖動(dòng)。

2）強(qiáng)一致 Strong Consistency
數(shù)據(jù)寫入后，可以立即讀到。

在設(shè)計(jì)SearchIndex時(shí)，針對(duì)不同的業(yè)務(wù)場(chǎng)景，我們也提供了多一致性的支持。

1）最終一致性（默認(rèn)）
1.1）用戶寫入操作成功返回后，原表數(shù)據(jù)立即可見，索引表數(shù)據(jù)不保證立即可查，需要等待一定的時(shí)間（可調(diào)節(jié)的時(shí)間，最低可配置為1秒）。
1.2）可見時(shí)間=LTS同步時(shí)間(ms)+搜索引擎數(shù)據(jù)可見時(shí)間(最低1秒)。

2）強(qiáng)一致性
2.1）用戶寫入操作成功返回后，主表和索引表中的數(shù)據(jù)一定可見，依賴Lindorm Search的實(shí)時(shí)可查特性，可參考下面章節(jié)的介紹。
2.2）寫入過程中，或者寫入未成功（拋錯(cuò)或者超時(shí)）時(shí)：不保證主表和索引表數(shù)據(jù)同時(shí)可見，但可以保證最終一致性，主表和索引表數(shù)據(jù)要么全執(zhí)行成功，要么全不執(zhí)行。

圖片5.png

4.4.3 可選的索引構(gòu)建成本

索引可以加速查詢，助力業(yè)務(wù)進(jìn)一步挖掘數(shù)據(jù)的價(jià)值，但它不是銀彈，會(huì)帶來(lái)寫入成本和存儲(chǔ)成本的增加。我們可以通過多種高效的壓縮算法顯著降低索引的存儲(chǔ)體積，但如何降低索引構(gòu)建對(duì)寫入吞吐的影響呢？

圖片6.png

上面是數(shù)據(jù)寫入的主要流程，其中索引WAL的構(gòu)建快慢將直接影響到原始數(shù)據(jù)的寫入性能。Lindorm寬表是一個(gè)KV數(shù)據(jù)庫(kù)，天然支持更新部分列，但是搜索引擎Lucene只能整行更新，不能夠局部更新。因此，在構(gòu)建索引時(shí)需要回讀原表獲取歷史數(shù)據(jù)，才能夠拼接出完整的索引WAL。我們將這個(gè)回讀操作按照業(yè)務(wù)場(chǎng)景進(jìn)行分類，支持不同的選擇。

1）IMMUTABLE（成本最低）
1.1）適用場(chǎng)景：數(shù)據(jù)只增不刪的場(chǎng)景（可以TTL淘汰數(shù)據(jù)）。例如監(jiān)控?cái)?shù)據(jù)/日志數(shù)據(jù)，數(shù)據(jù)寫入后不會(huì)更新和刪除。
1.2）索引構(gòu)建非常高效，不需要回查舊數(shù)據(jù)，直接依據(jù)當(dāng)前的數(shù)據(jù)生成索引。

2）MUTABLE_LATEST（成本中等）
2.1）適用場(chǎng)景：普適的場(chǎng)景，大眾的選擇（除UDT）。
2.2）例如索引列為c1,c2，第一次寫入c1列，第二次寫入c2列。那么在第二次寫入c2的值時(shí)，需要讀出原始的c1值，才能夠拼接出完整的索引數(shù)據(jù)c1,c2。

3）MUTABLE_ALL（成本最高）
3.1）適用場(chǎng)景：寫入數(shù)據(jù)時(shí)，業(yè)務(wù)自定義時(shí)間戳（User-Defined Timestamp）。例如：全量任務(wù)和增量并存的場(chǎng)景，往往需要在全量任務(wù)時(shí)攜帶時(shí)間戳，這樣可以確保不會(huì)覆蓋增量寫入的數(shù)據(jù)
3.2）存儲(chǔ)引擎層每個(gè)KV都有時(shí)間戳，如果業(yè)務(wù)寫入時(shí)沒有顯示的設(shè)置，服務(wù)端會(huì)自動(dòng)設(shè)置為系統(tǒng)時(shí)間戳，遵循"時(shí)間戳大的優(yōu)先可見"的原則。
3.3）業(yè)務(wù)自定義時(shí)間戳的寫入，在構(gòu)建索引時(shí)需要獲取到所有的歷史數(shù)據(jù)（包括刪除的數(shù)據(jù)），才能準(zhǔn)確判斷當(dāng)前的寫入是否為有效數(shù)據(jù)。如果時(shí)間戳小，則直接丟棄掉，不構(gòu)建索引。

4.4.4 高效同步

在最終一致性的模型中，索引數(shù)據(jù)同步依賴LTS服務(wù)。LTS服務(wù)作為L(zhǎng)indorm生態(tài)的數(shù)據(jù)通道，具備高效的實(shí)時(shí)同步和全量遷移能力，寫入寬表的數(shù)據(jù)，可以在毫秒內(nèi)感知到，快速的同步到搜索引擎中。

1）同步可視化。LTS提供WEB訪問，可以查看到索引同步的詳細(xì)信息。例如同步的耗時(shí)、索引表信息、同步的數(shù)據(jù)量等。另外，LTS可以將這些信息對(duì)外吐出監(jiān)控指標(biāo)，對(duì)接告警體系，實(shí)時(shí)監(jiān)測(cè)同步鏈路的健康度。

2）同步高效率。LTS內(nèi)部通過高并發(fā)的生產(chǎn)者/消費(fèi)者模式，支持快速消化大量的數(shù)據(jù)，一份WAL只需要讀取一次。并且支持橫向擴(kuò)展，新加入的節(jié)點(diǎn)可以快速加入到同步鏈路中，加速索引數(shù)據(jù)的同步。

3）WAL保序。通過隱藏的時(shí)間戳屬性，保證在寬表中先寫入的數(shù)據(jù)先寫入搜索，后寫入的數(shù)據(jù)后寫入搜索，確保寬表和搜索的數(shù)據(jù)一致性，徹底解決LilyIndexer存在的數(shù)據(jù)錯(cuò)亂問題。

4）全量構(gòu)建快。對(duì)于已有的歷史數(shù)據(jù)，可以借助LTS的全量任務(wù)運(yùn)行機(jī)制，高效的從寬表中獲取原始數(shù)據(jù)生成索引，TB級(jí)別的數(shù)據(jù)量分鐘內(nèi)即可完成索引構(gòu)建。

5）數(shù)據(jù)快速校驗(yàn)。支持對(duì)已有數(shù)據(jù)的比對(duì)校驗(yàn)，可以快速篩選出不一致的索引數(shù)據(jù)，幫助業(yè)務(wù)及時(shí)發(fā)現(xiàn)問題。

4.4.5 索引實(shí)時(shí)可見（RealTime Search）

寫入成功后的索引數(shù)據(jù)可以立即可查，我們稱之為索引的實(shí)時(shí)可見，是一種強(qiáng)一致的模型。SearchIndex底層依賴Lucene，Lucene有一個(gè)明顯的"缺陷"：數(shù)據(jù)寫入后不能立即可查，必須要顯示的執(zhí)行Flush或者Commit操作才可以查詢到。這導(dǎo)致基于Lucene的服務(wù)無(wú)法應(yīng)用到實(shí)時(shí)業(yè)務(wù)場(chǎng)景，只能適用于監(jiān)控、日志等弱實(shí)時(shí)的場(chǎng)景。在業(yè)界，基于Lucene的分布式搜索引擎Elasticsearch/Solr為了緩解這個(gè)問題，提供近實(shí)時(shí)查詢（NRT）功能，可以確保索引數(shù)據(jù)在某個(gè)時(shí)間范圍內(nèi)（通常在秒級(jí)）一定可查，但還是達(dá)不到實(shí)時(shí)性的要求。

為了解決寫入的數(shù)據(jù)無(wú)法立即可查的問題，我們基于Lucene實(shí)現(xiàn)了一種索引實(shí)時(shí)可見的方案，通過精細(xì)化的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)和動(dòng)態(tài)的內(nèi)存管理機(jī)制，可以保證索引數(shù)據(jù)一旦寫入成功后可以立即查詢到，真正做到實(shí)時(shí)性。

4.4.6 CQL API

CQL是Cassandra的官方查詢語(yǔ)言，是一種適合NoSQL數(shù)據(jù)庫(kù)特點(diǎn)的SQL方言，由于Lindorm無(wú)縫兼容Cassandra，面向客戶我們默認(rèn)推薦使用CQL來(lái)訪問SearchIndex。當(dāng)然，集團(tuán)內(nèi)部用戶也可以繼續(xù)使用Lindorm的TableService API來(lái)訪問SearchIndex

1）DDL

1.1）創(chuàng)建索引

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）重構(gòu)索引

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）標(biāo)準(zhǔn)查詢，WHERE后面緊跟具體的條件。
2.2）search_query查詢，語(yǔ)法如下：

SELECT selectors
       FROM table
       WHERE (indexed_column_expression | search_query = 'search_expression') 
       [ LIMIT n ]
      [ ORDER BY column_name ]

當(dāng)標(biāo)準(zhǔn)的查詢語(yǔ)法無(wú)法滿足檢索需求時(shí)，可以考慮通過search_query來(lái)直接從搜索引擎中檢索數(shù)據(jù)，使用的語(yǔ)法也是Lucene的語(yǔ)法。例如，下面的用例中，相當(dāng)于檢索city為'hangzhou'，并且age在1到18（包含）的數(shù)據(jù)。

SELECT name,id FROM myTable  WHERE search_query = '+city:hangzhou +age:[1 TO 18]';

詳細(xì)的CQL語(yǔ)法，可參考語(yǔ)法介紹。

五.案例介紹

Lindorm經(jīng)過多年的發(fā)展和歷練，在集團(tuán)內(nèi)部和公有云形成了良好的口碑，通過不斷的夯實(shí)存儲(chǔ)引擎，讓業(yè)務(wù)數(shù)據(jù)真真正正的"存得起"，海量數(shù)據(jù)存儲(chǔ)找Lindorm已成為各個(gè)業(yè)務(wù)選型的重要參考，非常感謝各位業(yè)務(wù)方的信任與支持。除了支持淘寶、支付寶、菜鳥、優(yōu)酷、高德等業(yè)務(wù)中的核心應(yīng)用外，我們也在不斷探索新的業(yè)務(wù)場(chǎng)景，今天介紹的SearchIndex特性可以進(jìn)一步讓業(yè)務(wù)數(shù)據(jù)"看得見"，只有看得見才能挖掘數(shù)據(jù)的價(jià)值，形成數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)的良性循環(huán)。特性上線之后受到了很多用戶的喜愛，在此也列舉下當(dāng)前在線上跑的一些場(chǎng)景，幫助大家進(jìn)一步了解SearchIndex的使用場(chǎng)景。

5.1 訂單場(chǎng)景

不管是傳統(tǒng)行業(yè)，還是互聯(lián)網(wǎng)行業(yè)，訂單數(shù)據(jù)的存儲(chǔ)是核心需求。而且訂單數(shù)據(jù)往往有其特殊的天然屬性：

高增長(zhǎng)：數(shù)據(jù)可能隨時(shí)會(huì)爆發(fā)式的增長(zhǎng)，例如雙11或大促節(jié)日。
低成本：訂單數(shù)據(jù)一般不會(huì)直接產(chǎn)生經(jīng)濟(jì)效益，是業(yè)務(wù)對(duì)外呈現(xiàn)的附加價(jià)值，需要低成本存儲(chǔ)。
多維查詢：對(duì)于C端用戶而言，往往會(huì)從不同角度對(duì)訂單進(jìn)行分類、標(biāo)記以及查看和過濾自己的訂單。

在之前，面對(duì)上面的訴求，一般的解決方案就是MySQL+搜索引擎。業(yè)務(wù)雙寫到兩個(gè)系統(tǒng)中，或者借助binlog進(jìn)行實(shí)時(shí)同步，查詢時(shí)分別從不同的系統(tǒng)中獲取結(jié)果。隨著數(shù)據(jù)量的增長(zhǎng)，可能會(huì)演變?yōu)镸ySQL熱數(shù)據(jù)+Lindorm冷數(shù)據(jù)+搜索引擎的架構(gòu)，基于多套系統(tǒng)可以有效解決業(yè)務(wù)問題，但需要面臨多套系統(tǒng)維護(hù)的時(shí)間成本和人力成本。

現(xiàn)在，一套Lindorm即可解決問題，不用關(guān)心數(shù)據(jù)的流轉(zhuǎn)，統(tǒng)一的API訪問。
1）通過冷熱分離、壓縮優(yōu)化等手段顯著降低存儲(chǔ)成本。
2）橫向彈性擴(kuò)展適應(yīng)海量數(shù)據(jù)的寫入。
3）SearchIndex CQL提供豐富的查詢語(yǔ)法。

客戶群體：物流、第三方支付、移動(dòng)出行。

圖片7.png

某物流公司基于Lindorm實(shí)現(xiàn)的訂單查詢系統(tǒng)。

5.2 用戶畫像

用戶畫像的數(shù)據(jù)一般有兩種：一個(gè)是基礎(chǔ)數(shù)據(jù)，另一個(gè)是經(jīng)過分析得到的標(biāo)簽數(shù)據(jù)。這些數(shù)據(jù)可以被應(yīng)用到營(yíng)銷、推薦等場(chǎng)景中，可以助力企業(yè)營(yíng)收快速增長(zhǎng)。畫像數(shù)據(jù)的主要痛點(diǎn)如下：

數(shù)據(jù)量大：畫像數(shù)據(jù)與用戶基數(shù)強(qiáng)相關(guān)，往往在千萬(wàn)甚至億級(jí)別，而且數(shù)據(jù)維度非常高，在我們服務(wù)的客戶中，有的場(chǎng)景支持的標(biāo)簽數(shù)在5000個(gè)以上。
高并發(fā)。畫像數(shù)據(jù)通常需要全量刷新，需要在基線的時(shí)間內(nèi)完成才能有效輔助后續(xù)的推薦、廣告投放等。
動(dòng)態(tài)列。數(shù)據(jù)維度在不斷的變化中，因此需要支持動(dòng)態(tài)增/刪列。
多維查詢。面向不同的業(yè)務(wù)需求，畫像數(shù)據(jù)查詢需求也會(huì)有差異，運(yùn)營(yíng)人員通常會(huì)統(tǒng)計(jì)任意一個(gè)維度的數(shù)據(jù)。

畫像場(chǎng)景一般沒有強(qiáng)事務(wù)需求，而是大數(shù)據(jù)量、高并發(fā)讀寫的場(chǎng)景，關(guān)系數(shù)據(jù)庫(kù)不太適合。Lindorm作為一款NoSQL數(shù)據(jù)庫(kù)，非常適合這樣的場(chǎng)景。
1）多列族、動(dòng)態(tài)列、TTL等特性，適合表結(jié)構(gòu)不固定，經(jīng)常需要進(jìn)行變更的業(yè)務(wù)場(chǎng)景。
2）高性能吞吐。
3）SearchIndex CQL支持任意維度的查詢和統(tǒng)計(jì)。

客戶群體：在線教育、互聯(lián)網(wǎng)車險(xiǎn)。

圖片8.png

某在線教育公司基于Lindorm實(shí)現(xiàn)的學(xué)生畫像系統(tǒng)。

5.3 日志檢索

日志的來(lái)源非常廣泛，例如系統(tǒng)日志、數(shù)據(jù)庫(kù)審計(jì)日志、用戶行為日志等，這些數(shù)據(jù)在互聯(lián)網(wǎng)公司中通常存儲(chǔ)于開源Elasticsearch（ES）中，借助ELK體系構(gòu)建一站式的日志平臺(tái)。但ES的存儲(chǔ)成本是非常高的，而且存儲(chǔ)和計(jì)算往往需要同機(jī)部署，在海量數(shù)據(jù)下系統(tǒng)運(yùn)維面臨非常多的挑戰(zhàn)，數(shù)據(jù)遷移、節(jié)點(diǎn)擴(kuò)縮容等都需要人工介入。多模數(shù)據(jù)庫(kù)Lindorm的SearchIndex是日志檢索場(chǎng)景的更優(yōu)選擇，通過寬表引擎存儲(chǔ)海量數(shù)據(jù)降低成本，搜索引擎構(gòu)建合適的索引加速查詢，統(tǒng)一的API操作進(jìn)一步降低業(yè)務(wù)開發(fā)成本。

圖片9.png

客戶群體：日志數(shù)據(jù)量大、成本敏感的客戶。

六.總結(jié)與展望

SearchIndex作為L(zhǎng)indorm寬表的一種新型索引，進(jìn)一步增強(qiáng)了寬表的查詢能力，業(yè)務(wù)使用統(tǒng)一的CQL API即可享受SearchIndex帶來(lái)的查詢便利，無(wú)需感知底層的多模引擎以及數(shù)據(jù)同步問題。未來(lái)，我們將在以下方面繼續(xù)發(fā)力：
1）持續(xù)豐富SearchIndex的查詢能力，例如：支持地理位置查詢等。
2）SearchIndex Serverless隔離調(diào)度，持續(xù)降低業(yè)務(wù)接入成本。
3）融合時(shí)序引擎，加速時(shí)序引擎的tag檢索等。

七.結(jié)語(yǔ)

感謝大家百忙之中閱讀文章，同時(shí)非常歡迎大家咨詢使用，SearchIndex的使用文檔，可參考使用手冊(cè)，技術(shù)交流歡迎加入釘群：35977898

同時(shí)，也熱烈歡迎有興趣的同學(xué)加入我們，一起建設(shè)云原生多模數(shù)據(jù)庫(kù)Lindorm，職位介紹請(qǐng)參考鏈接。

Lindorm 原理 | 深度解析 Lindorm 全文索引 SearchIndex 特性