什么是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）也不一樣，這樣相當于每個圖片都有多個標簽，每個標簽有一個名字和一個權重分。這種數據其實就是一個兩層的數據結構：

{"image_url": "http://img.com/20180901/cn/zj/hz/yq1002.jpg","image_size": 10240,"created_timestamp": 1537261379"tags": [{"name" : "house","socre": 0.47},{"name" : "car","score": 0.24}] }

如果要根據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查詢功能時的學習成本和復雜度。

TableStore已經于09月20日開始多元索引邀測，有興趣的用戶可以登陸TableStore控制臺，根據指引申請邀測。邀測階段的多元索引費用免收。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的TableStore发布多元索引功能，打造统一的在线数据平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。