隨著網際網路發展的深入，網際網路開始下沉到各行各業進行網際網路改造，比如進入網約車、計程車行業的滴滴，將計程車行業網際網路化，改造之前，計程車的分佈、訂單軌跡、人流熱度等交通資料都是直接廢棄導致無法利用起來。改造之後，整個城市的計程車的實時分佈、訂單執行軌跡、人流熱度等等這些都能實時觀測到的，可以用於交警、行人、計程車提前規劃更合理的路線，加快了整個城市的執行效率。在這個網際網路改造過程中，最核心的就是計程車的執行和運營資料，比如實時軌跡、訂單資訊、地理熱力圖等，這些資料就是一些結構化或半結構化的資料，需要為這些資料尋找一種合適的儲存系統。考慮到這些資料的存量和增量非常大，都是以億為單位，如果要存這些海量的半結構化的資料，最合適的莫過於分散式的結構化或半結構化儲存系統。

這種網際網路改造的過程不僅僅發生在交通行業，也發生在很多其他傳統行業，其他傳統行業的這類資料儲存需求也是一樣的。

目前業界可用的分散式結構化、半結構化儲存系統，有開源的HBase，如果使用雲服務，那麼有Amazon的DynamoDB、阿里雲的TableStore和Google cloud的Bigtable，後三種都是Serverless服務化的，使用者只需要關注開發，不再需要關注運維等鬧心的事情了，更適合如今高效率的開發節奏。

現狀

上一節提到的幾種大資料儲存系統都是LSM架構的，這些系統雖然專門是為了儲存海量的半結構化資料儲存而生，但是優點也僅限於此。可以輕輕鬆儲存幾PB，甚至幾十PB資料，且資料的寫入、查詢能力不會隨著資料增長而下降，也就是說，當系統裡面儲存1GB或1PB資料的時候，寫入、查詢效能基本相同，非常適合於儲存大規模資料。

但是查詢能力就比較弱，只能提供兩種查詢，一種指定完整PK的單行完全命中查詢（GetRow），另一種是指定PK字首、部分命中的範圍查詢，歸根到底，其實也就只有一種查詢，那就是隻能按PK來查詢，無法根據非PK的屬性列查詢。如果有屬性列查詢的需求，就只能通過各種辦法縮小PK範圍，然後全部掃描出來，再過濾，這樣查詢效能就比較差了，很多場景下效能會差到根本就無法接受。

更嚴重的是還有大量的查詢場景無法支援，比如模糊查詢，多欄位自由組合的ad-hoc查詢、分詞查詢、地理位置查詢，排序和統計等，最後只能通過限制上層應用的功能解決，但是這部分功能很可能就是使用者迫切需要的，比如滴滴的歷史訂單功能頁面，只能通過時間從前往後看，沒法按照起點、終點、費用、時間段、乘車型別和評價星級等檢視歷史訂單。

總之，當前這些系統在查詢方面的不足，主要體現在下面幾點：

• 無法滿足任意條件組合查詢需求
• 無法支援地理位置查詢
• 無法支援模糊查詢
• 無法支援分詞查詢
• 無法支援多列的排序和翻頁
• 無法支援輕量級的分析，包括統計聚合等。

目前的現狀其實就是：解決了儲存的問題，但是沒解決查詢的需求，而資料的價值只能通過查詢體現，查詢的需求迫在眉睫。

多元索引

為了解決上述這些不足，也為了充分釋放產品的功能潛力，TableStore研發了多元索引功能集。在原有的主鍵查詢方式基礎之上，額外提供了下列能力：

• 多條件自由組合查詢
• 模糊、字首查詢
• 具備分詞能力的全文查詢
• 排序和多種翻頁功能
• 地理位置查詢
• 輕量級分析，比如統計、聚合等

具備上述功能後，TableStore在保證寫入效能不下降的前提下，查詢能力又有了非常大的提升，更加適合儲存海量結構化和半結構化資料，資料不僅可以快速儲存，還可以方便、快捷的查詢分析。

再回到文章開始時例子，如果將計程車的訂單儲存在TableStore，那麼就可以輕鬆實現按照起點、終點、費用、時間段、乘車型別和評價星級等檢視歷史訂單，也可以按照月份、車型、目的地等生成實時報表，有了這些功能後，使用者體驗就更好了，也會成為應用的核心競爭力，以前不能實現的功能，現在都可以輕鬆實現了。

 

使用

多元索引是一個強Schema的索引系統，在使用之前，需要先建立Schema，目前支援通過官網控制檯和SDK建立SearchIndex。已經在Java、Golang、C#、Node.js和Python等SDK中支援完整的SearchIndex功能。

如果當前Table中已經有資料，當建立好多元索引後，Table中資料會通過內部的系統自動開始建立索引（build index），建立索引過程中的狀態可以在官網控制檯或者通過SDK的DescribeSearchIndex介面查詢，結果會顯示當前階段（全量、增量）：

• 全量的含義是正在對Table中原有資料建立索引。
• 增量的含義是正在對建立Index之後新寫入的資料建立索引。

如果是增量階段，則會有一個最新建立index的時間，當前時間減去這個時間就是使用者將資料寫入Table成功，到可以在SearchIndex中查詢到的延遲，一般在秒級別（1~10秒），比如如下圖：​

在控制檯上，不僅可以建立多元索引，查詢多元索引Schema等外，還支援比較簡單的查詢功能，比如單欄位查詢、範圍查詢、分詞匹配查詢、字首查詢、多欄位組合查詢和排序等，其他的較複雜的巢狀查詢，地理範圍查詢等可以通過SDK實現。

TableStore是一個Serverless的服務化產品，使用者無需關心“運維”，只需要關注“開發”，提供類Restfull API和SDK，懷著“將複雜留給自己，將簡單留給客戶”的初心，讓使用者在使用上儘量簡單，同時也不用考慮儲存容量、機器水位等多種繁雜的問題。同樣的，多元索引也是基於這一目標，使用者只需要建立索引，就可以直接通過阿里雲官網控制檯體驗查詢，通過SDK的Search介面實現各種查詢需求。

如果想對多元索引有更深入的瞭解，可以閱讀下列文章：

1. 《如何用表格儲存翻頁》。
2. 《TableStore符合型別：Array和Nested介紹》。
3. 《TableStore多元索引路由介紹》。

場景

TableStore是一款阿里云為結構化、半結構化資料自研的大規模儲存系統，適用場景眾多，尤其是大規模資料的儲存和查詢，下面會簡單列舉幾種常見的場景或需求。

1. 訂單系統

訂單系統是各類應用或系統中最常見的一種系統，常見的有：

• 電商網站的歷史訂單
• 商場、零售店、超市和酒店等的歷史訂單
• 網約車、計程車的歷史訂單
• 財務系統中的歷史記錄

任何一家企業都會至少有一個類似訂單系統的系統存在，這一類系統的特點是，資料持續產出，每條資料的屬性很多，一般都在10個以上，甚至有些複雜系統可能有上百個，這種資料需要儲存時間長，因為有些時候需要通過這些資料調查歷史問題。

針對這類系統，最難得地方是查詢複雜，所有屬性列都需要支援查詢，且查詢條件不固定，同時資料量又大，一般的解決方法是以下兩種其一或者結合：

• 最近1個月的資料儲存在MySQL等單機關係型資料庫，如果用心觀察，很多產品的訂單隻能查詢最近1個月或3個月的，再長就不支援了，原因就是單機容量的限制。同時，由於MySQL只有二級索引，只能查詢固定列的組合，如果屬性多了後就會不太適合了。
• 儲存在HBase等系統，但是隻支援按順序查詢，比如滴滴的歷史訂單，不支援按任意屬性查詢。

不管採用哪種方案，都是犧牲產品的使用者體驗為代價的。

更詳細的場景文章介紹，可以參考下面兩篇：

1. 《基於TableStore的海量電商訂單後設資料管理》。
2. 《TableStore實戰：億量級訂單管理解決方案》。

2. IM/Feeds

常見的社交類應用都是這一類，比如QQ、微信、Line和釘釘屬於IM，朋友圈、微博屬於Feeds，這一類系統主要包括兩部分，一是訊息儲存和分發，一是訊息Meta儲存和查詢。

訊息儲存和分發可以採用TableStore專門為IM/Feeds系統量身打造的Timeline模型，不管是寫擴散（推模式）還是讀擴散（拉模式）都能輕鬆處理，尤其是TableStore擁有強悍的千萬行每秒的寫入能力，非常適合於寫擴散場景。訊息的儲存庫和同步庫都可以使用TableStore來儲存，同時還有TTL功能可以用來節省成本。

另一類的訊息Meta，包括關注列表、點贊、使用者資訊等，這些都是Meta類資料，對多種查詢需求，尤其多欄位組合，模糊查詢，統計等強需求，這一類就可以用TableStore的多元索引。一個雲產品就能滿足你在IM/Feeds系統中的所有資料儲存需求。

目前，行業內已經有不少大中小型公司在使用TableStore儲存IM/Feeds系統中的所有資料。

3. 爬蟲資料

隨著資料價值越來越被重視，網際網路上的大量垂直行業的資料價值也開始凸顯，這一類資料的特點是資料規模較大，資料成本敏感，清洗後的資料價值加到，部分欄位需要多欄位組合查詢，有些需要能支援分詞查詢。

上述的特點對應到儲存系統的要求就是：天然分散式、可靠性高、不能丟資料、成本低、支援多種查詢方式。適用於這些特點的儲存系統，目前也只有TableStore一款產品，其他系統都會有一些地方捉襟見肘或不合適。

更詳細的場景文章介紹，可以參考下面這篇：

1. 《TableStore：爬蟲資料儲存和查詢利器》。

4. 日誌

日誌資料類似於訂單資料，資料量大，查詢量較少，這一類資料也可以用TableStore儲存和查詢。

還有很多其他資料也非常適合用TableStore，由於篇幅有限，後面會專門寫一篇文章介紹TableStore的使用場景以及注意事項，全力賦能使用者使用TableStore。

展望

上面介紹了TableStore的多元索引，以及具備了多元索引能力的TableStore，非常適合儲存大規模的結構化、半結構化的資料，尤其是當單機MySQL等關係型系統在容量上容納不下的時候。

未來，我們會繼續優化TableStore的索引能力：

• 提供全域性二級索引，繼續加強少量固定列範圍查詢時的效能。
• 繼續優化多元索引的成本，未來有望將成本降低到當前一半，甚至更低，為大規模資料儲存提供一個理想的儲存平臺。
• 提供備份、容災等系統功能，再將系統的可靠性和可用性提高几個數量級。

我們的目標是：打造結構化、半結構化資料的線上資料平臺，未來會一直持續朝這個目標邁進，為阿里雲客戶提供理想的線上資料儲存系統。

產品頁面：https://www.aliyun.com/product/ots

產品文件：https://help.aliyun.com/document_detail/91974.html