TableStore釋出多元索引功能，打造統一的線上資料平臺
摘要： TableStore釋出多元索引功能，提供多欄位ad-hoc查詢、模糊查詢、全文檢索、排序、範圍查詢、巢狀查詢、空間查詢等功能，打造統一的線上資料平臺
什麼是NoSQL
“NoSQL”一詞最早出現在1998年，距今剛好二十年。站在今天回頭看的話，很少有人能想到在關係型資料庫成熟發展了三十年，已經在資料儲存領域佔據了不可動搖的的地位後，NoSQL資料庫盡然還可以快速地異軍突起，並且以多點開花、多路並進的方式高速發展。“NoSQL”最早的意思是“non-relational”，後來又升級為了“Not Only SQL”，不管如何定義，“NoSQL”都代表了一種不同於關係型資料庫的全新的思維方式。雖然在最近幾年也出現了一些新穎的單機資料儲存系統，也被劃歸為NoSQL，但在本文中，“NoSQL”僅指傳統的分散式NoSQL資料庫。
NoSQL最近二十年，尤其是最近十年可以說異軍突起，主要得益於網際網路的高速發展，對資料庫有了更多更高的要求：
• 高達TB，PB級的海量資料儲存需求：不管是二十年前起步的搜尋，十年前起步的社交，還是今天開始發展的物聯網，都需要儲存、處理海量的資料，而且場景越來越多，規模越來越大、
• 低延遲的讀寫速度：無論是隨著網際網路的發展，還是移動時代的到來，越來越多的應用需要直接面對使用者的訪問，延遲直接影響了使用者的體驗感受，同時隨著網民數量的激增和技術的深入，需要處理的資料極速增大，儲存系統的延遲直接影響了整個資料處理的耗時，低延遲會使資料處理更快，使用者更早看到結果，體驗更好，在同產品競爭中優勢會更大，這些都要求儲存系統能有更低的讀寫延遲。
• 低成本的需求：資料量增大了，速度也提高了，成本應該會更高，但是高昂的技術成本支出如果沒法在產品營收中同比例的賺回，那麼這項技術是沒價值的。基於此，更低的成本成了技術發展、普及的核心要求。
上述三個需求，在傳統資料庫中很難實現，就算是優化改進，只要不改變思維方式，不改變系統架構，很難徹底的滿足上述的需求，只是繼續一個個的打補丁。基於此現狀，“NoSQL”依賴分散式系統架構，在功能上做出一定取捨後，帶著網際網路時代的使命誕生。
從最早的“Bigtable”，到後來的Dynamodb、HBase、Cassandra、Redis、MongoDB、Janus Graph等，發展出了不同型別，適用於不同場景的多種NoSQL資料庫，每一種NoSQL資料庫都有各自適合的場景，不管是適應於何種場景，這批相繼前後誕生的“NoSQL 兄妹”都在快速成長。從下面最新的DBEngine的趨勢圖上也能看出一些端倪：
從圖中可以明顯看到，各種NoSQL系統的影響力基本都是在大幅增長。
在這場“NoSQL”的革命中，阿里雲也是放眼未來，在成立之初就投入資源研發，歷經9年的打磨和多輪迭代演變成了今天的TableStore，在2014年正式商業化面向公有云提供服務。目前已在阿里巴巴集團、阿里雲公有云以及專有云內得到廣泛應用，涵蓋電商、金融風控、物聯網、人工智慧、大資料、社交媒體等不同業務領域，不間斷的為成千上萬的訂單、日誌、風控、IM、Feeds、無限Topic佇列、時序、氣象、軌跡溯源等產品儲存著海量的資料。為網際網路，為國計民生默默的貢獻著自己的力量。
“NoSQL”等大資料的軟體出來沒多久後，很快就到了雲端計算時代，2012年Aliyun開始在國內售賣雲端計算產品，經過多年的市場培育，大眾也開始逐漸接受和信賴雲端計算，越來越多的使用者把整個系統架構在阿里雲產品之上。隨著使用者越來越多，場景也越來越複雜，使用者感受到雲端計算的價值後，對雲端計算的要求也變得越來越高，使用者日益增長的功能、易用性需求在當前地雲產品上不一定能得到滿足。
NoSQL的未來
我們回到“NoSQL”領域，在海量儲存領域，使用者真正希望的產品其實是可以儲存海量資料、資料可靠、效能穩定、成本低、資料可見，目前能較好滿足這五個條件的NoSQL產品是沒有的。在小資料量級上用關係型資料庫就能滿足需求了，但是在大資料集上是空缺的。比如TableStore，滿足前4項：儲存海量資料，單表可到10PB級；資料可靠，提供11個9的可靠性保障；效能穩定，不管是1GB還是1PB的儲存都不影響讀寫效能，目前有線上業務單表寫入速度達到3500萬行每秒，效能仍然很穩定；成本低，才適合儲存海量資料；資料可見，只能通過單Key或者Key字首範圍掃描兩種方式，其他的非主鍵查詢、模糊、排序、統計都不支援，使用者的資料儲存後，很難高效的被使用，資料可見能力比較弱，其他類似分散式NoSQL資料庫有同樣的問題。
那麼問題來了，作為一個分散式NoSQL雲產品為什麼必須要有很強大的查詢能力呢？這個要從兩方面來看：
• 首先，從分散式NoSQL軟體來看，目前這類軟體大多數基於“LSM”架構，寫入效能極好，但是查詢能力弱，結果就是使用者只願意儲存價值較低的海量資料，因為資料價值低也只願意付最低的價格，而對於使用者願意支付更高價格的價值較高的資料沒法儲存，就算儲存進來後，也很難比較容易的被查詢到資料，資料價值就不容易發揮出來。使用者最終只能權衡後，通過降低要求將頭部的少量高價值資料儲存在關係型資料庫中，其他資料放棄掉，結果是使用者想花錢還花不出去。但是如果哪一天，分散式NoSQL資料庫支援豐富的查詢能力後，這部分使用者就可以有地方儲存更高價值的資料，且可以儲存更多資料，也就能對使用者業務產生更大的價值。
• 其次，雲端計算時代的雲產品和開源軟體不一樣。當某個開源軟體比較成熟和穩定，或者功能不能滿足新需求時，更多的思路是熱衷於新開啟一個開源專案，在新專案中將新需求更好的實現，這樣新專案也更容易積累影響力，但是原有的開源產品就會發展緩慢甚至停滯。簡單說就是單功能系統的迭代速度快，生命週期短，帶來的後果是使用者需要每隔幾年更新換代一次系統。而云產品不一樣，雲產品釋出後就會有使用者使用，使用者使用了，那麼就不能輕易的下線，必須不停的基於當前雲產品去迭代，將雲產品做的更好。雲產品的生命週期一般都要比開源軟體的生命週期更長。所以，作為一個雲產品，我們考慮的是如何滿足使用者儲存海量線上資料時的需求，為了滿足這些基本業務需求，查詢能力是最基本的要求，否則很難說是一個完整的雲產品。
為了解決上述的矛盾或者預期差距，需要提供更高效、易用的資料可見途徑，將使用者的資料價值發揮出來，實現客戶和雲產品的雙贏。為了實現上述目標，為了滿足使用者期望，甚至是希望能給使用者驚喜感，我們一直以來的思路是提供“一個線上資料平臺”：一份可靠高效的資料儲存，多種模型的高效訪問。我們正在打造的“線上資料平臺”具有以下特點：
• 超大規模資料的高可靠儲存：單表10PB級以上的儲存能力；11個9的資料可靠性保障能力。
• 低成本：在保證效能的前提下，平衡成本，將成本做到最低。產品的目標是海量資料，只有低成本，才能發揮出海量資料的價值，低成本是最核心的訴求。
• 高寫入效能：基於LSM架構和使用者態的協議棧，寫入效能極佳；架構的優化可以使不管是高效能的SSD，還是SATA儲存，都能保證一樣的寫入效能。
• 多種模型的高效訪問：通過多種模型的高效訪問，可以將海量資料的黑盒狀態變成白盒狀態，將資料的真面目展現出來，資料的價值才能被使用者利用起來，為使用者產生價值。
如果將雲端計算的發展和社會的發展做一個類比的話，那麼：
• 原始時代：單產品單功能時代，每個產品提供一個最主要功能，比如儲存A提供一個功能，儲存B提供一個功能，計算A提供一個功能，計算B提供一功能，使用者用的時候就是在上層寫應用層，通過雙寫或多寫將多種產品組合起來。
• 工業時代：開始出現管道和輔助產品，開始基於多個單功能產品和一些管道提供完整解決方案，使用者只需要一步一步按照步驟就能搭建起來一個系統。
• 智慧時代：使用者想儲存海量資料，需要線上實時訪問，那麼只用一款產品就夠了；如果想計算，那麼同樣一款產品就夠了。使用者通過這些“線上大資料儲存平臺”和“線上計算平臺”的統一介面可以實現絕大部分的需求。
我們做的“線上資料平臺”就是一個為“智慧時代”產品而做的探索，希望對外只展現一套讀寫API介面，通過這套統一的介面，使用者可以實時高效地儲存、訪問海量資料。
如何實現
線上資料平臺”是一個比較龐大的工程，為了完成我們“線上資料平臺”的目標，我們從頂往下一層一層分解開來看。
頂層：需求層
需求是實現一站式的易用的、低成本線上海量資料的儲存和訪問。歸納後的特點就是：低成本、易用性、海量資料、高效寫、高效豐富的訪問能力。目前在TableStore中已經實現的有：低成本，海量資料、高效寫和部分易用性，缺乏的是高效豐富的訪問能力和更佳的易用性。
第二層：模型層
為了實現豐富的訪問能力和易用性這兩個特點，我們將不同場景、訪問方式抽象成一個個的“模型”，使用者只要將需求匹配到模型上，那麼後續的開發複雜度會大幅降低，經過半年多的實踐，也證實了我們去年的猜想，效果非常好。這樣我們就會有一個模型層，目前已經提供了下列模型：
• Wide Column Model：寬表模型，支援任意多的列，且每一行的列名可以不一樣，為儲存半結構化和結構化資料提供極大的方便。同時在資料操作層面，提供兩類資料訪問API：Data API和Stream API，通過Stream API可以將增量資料的能力發揮出來。在寬表模型上，我們提供了兩套訪問介面，一套是HBase Client，如果使用者之前使用HBase Client，想要切換到TableStore，不需要修改程式碼，只需要增加對TableStore Hbase Client的依賴，以及增加阿里雲AccessKey的配置項後即可一鍵切換。另一套是原有的OTS介面，易用性和效能更佳。不同於現有的其他的寬表系統，我們的寬表系統裡面會提供非主鍵列查詢、模糊查詢和多欄位查詢等更豐富的查詢能力支援。
• Timeline Model：這是我們年初推出的一個新模型，抽象了無限Topic佇列的場景，基於表格儲存獨有的主鍵列自增功能可以保證訊息不亂序、不丟失。適用於IM、Feed流和其他訊息下推等場景。零基礎的使用者基於此模型，可以在1到2周時間內快速上線自己的IM或Feed流系統。在阿里巴巴集團內部以及阿里雲公有云使用者中已經被廣泛使用和好評，不僅將IM，Feed流和物聯網的控制命令下發等系統的開發週期大大的縮短，更關鍵的是將該類系統的可靠性、穩定性，效能、準確性（訊息的可達性）大幅的提高。該模型的架構在業界處於領先地位，業界同類型的著名IM們還在使用我們已經淘汰的落後技術架構。同時Timeline模型中也提供元資料和訊息內容的檢索能力。
除了上述兩個已經發布，並且被廣泛使用的模型外，今年我們會繼續擴充套件多模型的邊界：
• Graph Model：提供圖資料庫的讀寫模式，圖資料是一種比較經典的資料模型，在很多場景中都有廣泛使用。圖的查詢也是一種更加自然、友好的方式。
• Time Series Model：時序模型，我們會提供一種不同於現有產品的新時序模型，在功能和擴充套件性上會有很大的提高。
第三層：引擎層
在上面的模型中，目前已經支援了Wide Column和Timeline模型，但是這兩種模型都只是部分支援，比如Wide Column模型中目前還不支援非主鍵列查詢、多列組合查詢、模糊查詢、排序、時空、統計聚合等功能。Timeline模型中目前還不支援元資訊查詢和訊息內容查詢。Graph模型和TimeSeries模型中也都需要多欄位的檢索能力，否則效能和功能上都會有重大缺陷。為了彌補這個缺陷，我們還需要一個查詢引擎，有了這個查詢引擎後上述的非主鍵列查詢、多列組合查詢、模糊查詢、排序、時空、統計聚合等功能就能比較容易的實現了，這樣才能實現一個個完整的模型，才能打造出一個滿意的“線上資料平臺”。
為什麼做多元索引（SearchIndex）
在上一節的“引擎層”部分，我們得出結論，除了儲存引擎外，我們還需要一個查詢引擎，這個查詢引擎需要提供下列功能：
• 極強的索引能力：需要支援多欄位組合查詢，模糊查詢，時空等多維查詢等，這些需求只能通過倒排索引和其他類似索引解決。
• 輕量級分析能力：需要支援排序、統計、聚合等輕量級分析能力，這些能力在眾多場景下都有大量的需求，目前很多產品的這部分能力訴求都沒能得到很好地滿足。
上述說的查詢引擎，就是我們的多元索引（SearchIndex）。
儲存引擎和查詢引擎的側重點不同，架構方式也是有多種方式，一種是將儲存和查詢引擎揉捏在一起，在功能和效能上做一些取捨，往往會有致命性的問題無法解決。另一種是獨立引擎，中間通過非同步同步的方式傳輸資料，寫請求資料先進入儲存引擎，成功後直接返回，然後非同步通過佇列的方式將資料傳輸給查詢引擎後建立索引。
上述兩種架構方式，在目前業界是怎麼處理的？業界的發展現狀是怎麼樣的？下一章節，我們一起看一下目前業界的比較領先的解決方案。
業界領先方案
Cloudera Search
Cloudera是一家位於美國的軟體公司，向企業客戶提供改造後的商業版本的Apache Hadoop體系的軟體和服務，該公司為了讓分散式NoSQL資料庫HBase支援多列組合查詢、模糊查詢和輕量級分析能力，將開源搜尋引擎Solr引入HBase中。最終通過Lily HBase Indexer Service將寫入HBase的資料非同步同步給Solr，架構如下圖：
• 資料同步路徑依賴HBase Replication。
• Lily Indexer通過監聽HBase Replication的日誌非同步推送實時獲取增量資料，然後寫入Solr。
• Lily Indexer的全量rebuild通過HbaseMapReduceIndexerTool進行全量拉取。
• HBase提供持久化和Replication能力。
• 查詢直接使用Solr進行查詢，Solr提供了更豐富的查詢能力。
• 儲存引擎是HBase，查詢引擎是Solr，中間是使用Replication同步，查詢介面獨立。
基於HBase和Solr的Lily Indexer開源框架，可以使使用者實現資料持久化和豐富查詢能力，架構上覆用HBase的Replication的監聽推送資料能力，相對來說架構對HBase的改動侵入較少。但是有一些方面存在問題，甚至很嚴重的資料丟失問題：
• 需要依賴HBase開啟Replication功能，不能靈活的主動拉取增量，或者區域性補資料。
• Lily Indexer開源專案2016年以後活躍度降低，逐漸沉寂，如果沒有商業支援，運維成本非常高。
• HBase的日誌順序通過資料上的時間戳決定，在寫入Solr前需要重新排序，這種方式在時間回退或者寫solr超時時很容易出現新資料被老資料覆蓋的情況，很難保證做到資料一致性的，會導致索引資料丟失，結果就是資料存在，但是查詢不到。
• 查詢直接使用Solr Client，雖然有豐富的查詢語義，這意味著如果Solr中沒有的欄位還需要使用者自己反查HBase，易用性大幅降低。同時solr的活躍度、影響力和生命力都在下跌，未來存在專案死亡的潛在風險。
多元索引功能
TableStore作為阿里雲首款多模型資料庫，基於強大的分散式能力，目標是打造一個__線上資料平臺__。在此之前，TableStore已經可以提供大規模資料儲存、高效的讀寫訪問和較低的成本，不足的地方是查詢能力。現在我們新推出的多元索引能力就是專門解決查詢能力不足的問題。接下來，我們看一下多元索引能為大資料平臺提供哪些功能。
索引能力
不管是關係型資料庫，還是NoSQL資料庫，最基礎的查詢方式都是基於主鍵去查詢，如果需要通過其他屬性列去查詢，就需要建立二級索引，如果需要多欄位自由組合的ad-hoc查詢，那麼二級索引就會很吃力，另一種支援屬性列查詢的索引是檢索引擎系統使用的倒排索引。為了使阿里雲線上資料平臺的功能更豐富，我們直接支援了倒排索引以及其他一些索引：
- 倒排索引：是搜尋系統中多種查詢能力的基礎結構，可以極大優化查詢功能。基於此，TableStore提供了倒排索引能力，使用者為某些屬性列建立了倒排索引後，可以基於這些倒排索引實現多欄位自由組合的ad-hoc查詢，同時也不用擔心性別，年齡，列舉等選擇性較差的欄位的問題了。
- 多維空間索引：是一種用於地理位置等多維空間查詢的資料結構，一般都用於時空資料場景，可以極大提高空間查詢的效能。TableStore也提供了多維空間索引，目前基於多維空間索引提供了地理位置的查詢能力，包括“附近的人”、“矩形、多邊形等範圍內的點”等常見的地理查詢，為大資料篩選、車聯網和移動應用提供更豐富的一站式資料查詢能力。
排序
排序也是線上資料的一個很常見的強需求，比如選擇最多、最大、最小和最新等條件的資料。TableStore同樣提供了強大的排序能力，包括正序、逆序；單條件、多條件等排序功能。使用者儲存在TableStore中的資料就可以擁有全域性的多種排序能力。
全文檢索
有了倒排索引後，TableStore也提供了分詞能力，基於這些，使用者就可以實現全文檢索能力，目前只有資料召回能力，不提供相關效能力。
模糊查詢
模糊查詢時關係型資料庫的一個強大功能，基於like語法可以實現很多易用性極高的功能，但是在分散式資料庫中的時候，比如HBase，這個能力沒法提供。現在TableStore提供了模糊查詢能力，只要為該屬性列建立倒排索引，該欄位就可以被模糊查詢。
字首查詢
有了模糊查詢能力後，TableStore也提供了字首查詢功能。
巢狀查詢
線上資料中，除了扁平化的一層結構外，還存在一些更復雜的多層結構場景，比如圖片標籤：某個系統中儲存了大量圖片，每個圖片都有多個實體，比如有房子，有轎車，有人。在每個圖片中，這些實體佔的位置，空間大小都不同，所以每個實體的價值（score）也不一樣，這樣相當於每個圖片都有多個標籤，每個標籤有一個名字和一個權重分。這種資料其實就是一個兩層的資料結構：
如果要根據Tags中的條件查詢，這時候就需要使用到巢狀查詢，巢狀查詢功能為複雜資料的建模提供了極大的便利性。
去重能力
基於以上的查詢功能查詢到結構後，有可能某個屬性的資料非常多，結果多樣性比較差，有了去重能力後，可以限制某個屬性在一次結果中的最多個數，這樣就能提供更好的結果多樣效能力。
資料總行數
SearchIndex每次查詢時都會返回這次請求命中的資料行數，如果指定一個空查詢條件，這個時候所有建立了索引的資料都符合條件，這個時候返回的資料總行數就是表中已建立了索引的資料總行數。如果使用者停止寫入，且資料都已經建立了索引，則此時返回的資料總行數就是資料表中的總行數。這個功能可以用於資料校驗，運營等場景。
說完功能點後，我們再來看一下有了SearchIndex後，現有的場景會發生哪些變化，場景如何變得更豐富。
目標場景
當NoSQL資料庫TableStore有了多元索引能力後，原有的一些場景會變得更加豐富，比如在元資料、訊息資料、時序和時空資料等，接下來我們詳細看一下多元索引能力在這些場景中發揮價值。
1. 元資料
傳統的解決方案中，通常使用MySQL來儲存元資料，優點是利用MySQL提供的強大的事務能力來處理元資料的強一致寫。但當元資料的規模到一定量級，受限於MySQL的規模上限，會採用MySQL + NoSQL分層的解決方案，將一些不會再更新的歷史資料寫入NoSQL做一個冷資料儲存，比較典型的是淘寶曆史交易訂單方案。而有些元資料場景，對資料寫入沒有複雜的事務需求，例如物聯網裝置狀態資料或者是圖片元資料等，這類場景會直接使用NoSQL資料庫儲存資料。
元資料儲存後，需要提供豐富的線上查詢功能，這點是NoSQL資料庫的軟肋，也是MySQL的軟肋。元資料通常來說以個體為單位，包含多維屬性。查詢通常是多維屬性的一個條件組合查詢。MySQL的二級索引很難滿足這類查詢需求，需要定製大量索引。業界有采用了MySQL+Elasticsearch的方案，通過MySQL的binlog將資料實時增量同步至Elasticsearch，通過Elasticsearch內部的倒排索引實現高效的多維屬性檢索。
TableStore在推出多元索引之後，同時提供海量資料儲存以及高效資料檢索，很好的滿足元資料場景的需求。
2. 訊息資料
Timeline是TableStore今年年初推出的一個新的資料模型，適用於訊息資料場景，例如IM/Feeds流的訊息系統，或者是物聯網的裝置下推訊息系統。原理是基於底層的分散式KV引擎，模擬了一個類似佇列但提供無限輕量級Topic的資料模型，能提供訊息資料的保序儲存及實時隨機定位和範圍查詢。更豐富的內容可以檢視下列文章：《現代IM系統中訊息推送和儲存架構的實現》，《TableStore Timeline：輕鬆構建千萬級IM和Feed流系統》。
自Timeline推出後，在阿里巴巴集團內部和公有云上都已經得到廣泛使用。
在我們的規劃中，Timeline基於多元索引會提供更強大的功能。首先是對Timeline元資料的檢索，在即時通訊系統中Timeline是一個會話，在物聯網訊息系統中Timeline是一個裝置，不管是會話還是裝置，都具備一些元資料且需要能夠通過元資料來對Timeline進行檢索。其次是對訊息資料的檢索，提供訊息的全文檢索或者是多維檢索。
3. 時序和時空資料
隨著近幾年物聯網的發展，時序資料迎來了一個不小的爆發。TableStore在儲存模型、資料規模以及寫入和查詢能力上，都能比較好的滿足時序資料場景的需求。在《TableStore時序資料儲存 - 架構篇》中，我們對時序資料做了一個比較詳細的模型定義，以及給了一個基於TableStore的時序資料儲存方案。也闡述了開源時序資料庫存在的一些問題，例如對時間線元資料的索引，而基於多元索引，我們能提供對於時間線元資料的倒排索引和時空索引。
未來規劃
目前TableStore在支援了多元索引後，在功能上補齊了NoSQL系統的部分短板，但是還有一些不足，我們將在接下來幾個月繼續演進，比如：
• 功能：目前只是提供了最基本的功能，接下來會繼續根據業務場景需求增加更豐富的功能，比如統計、聚合能力。
• 易用性：在語法上會繼續優化查詢部分的難度，進一步降低使用者在使用TableStore查詢功能時的學習成本和複雜度。.
本文作者：少強
閱讀原文