如何在千億行規模的表中快速檢索數據

簡介：背景自從五十年前關係型數據模型被髮明出來後，憑藉優秀的表達能力和清晰易懂的特性讓其很快在數據庫市場中嶄露頭角，迅速佔領市場，成爲各行各業的主流數據存儲系統。在這五十年內，數據庫架構、表達方式、存儲結構、優化器等方面都有了長足的發展，可是索引結構的發展相對緩慢了一些，更多的發展是基於現有的索引基礎去優化查詢優化器。發展了三十年後進入互聯網和移動互聯網時代，數據規模呈爆發式增加，隨即產生了非關係型數據

背景

自從五十年前關係型數據模型被髮明出來後，憑藉優秀的表達能力和清晰易懂的特性讓其很快在數據庫市場中嶄露頭角，迅速佔領市場，成爲各行各業的主流數據存儲系統。在這五十年內，數據庫架構、表達方式、存儲結構、優化器等方面都有了長足的發展，可是索引結構的發展相對緩慢了一些，更多的發展是基於現有的索引基礎去優化查詢優化器。html

發展了三十年後進入互聯網和移動互聯網時代，數據規模呈爆發式增加，隨即產生了非關係型數據庫（NoSQL），NoSQL 的出現補充了原有數據庫在規模上的不足，可是這些 NoSQL 的索引結構原理仍然同傳統關係數據庫相似，都是基於原有表結構構建二級索引。算法

不管是關係型數據庫的二級索引仍是 NoSQL 數據庫的二級索引基本都是基於原有表結構的主鍵列重排，這樣都會在索引能力上存在短板：一是最左匹配原則的限制了索引功能，二是須要提早肯定好查詢列，而且將要查詢列組合後構建多個二級索引，若是在查詢時出現了沒法匹配索引的狀況則性能會大幅降低，因而就出現了深惡痛絕的慢查詢，慢查詢會嚴重影響用戶體驗和數據庫自己的穩定性。數據庫

爲了解決上述問題，有一種架構是引入搜索引擎，好比 Elasticsearch 、Solr（衰退期） 或其餘雲搜索系統等，使用搜索引擎的倒排索引來支持讀時索引：任意列的自由組合查詢，還能支持地理位置查詢、全文檢索。因爲搜索引擎是專門爲查詢優化的系統，查詢性能會更加穩定一些。可是這種作法也存在一些問題，甚至有些問題不少人都沒有意識到：數組

• 數據的可靠性：對於數據庫而言，保證數據不丟是最核心的要求，可是對於搜索引擎則不是，大部分搜索引擎都存在丟數據的問題。
• 查詢結果的完整度：搜索引擎的核心目標是查詢性能，因此會優先保證查詢性能，而非數據完整度，因此部分搜索引擎存在爲了保證延時而提早停止查詢請求的狀況。
• 功能的穩定性隱患：大部分開源產品或者商業產品，爲了吸引客戶因此最熱衷的是不停出新功能，部分功能在小數據量級上沒問題，可是數據量增多後，可能會有很嚴重的穩定性隱患，好比打爆內存，打爆CPU或者讓整個集羣卡死等等問題，最關鍵的是若是不是很是專業的專家，很難提早預估到這些隱患，最終都是在一次次的故障中慢慢摸索瞭解，更棘手的是永遠都不知道還有多少坑未踩過。
• 運維的複雜度：搜索領域是一個專業性很強的領域，雖然部分產品的易用性很好，可是對於運維人員的專業性要求很高，不少人摸索了幾年還僅僅是入門，當遇到問題時仍然沒法快速定位而且解決，甚至都不知道哪一個環節出了問題（根本看不到更細粒度的監控指標也就沒法知道到底哪一個環節出了問題），並且也很難在業務上線前提早發現風險，最終的結果多是兩敗俱傷：運維人員很累，業務的問題仍然不少。
• 架構的複雜度：爲了讓數據從數據庫同步到搜索引擎，須要引入一個同步系統，這樣至少須要管理三個系統，並且須要管理同步的狀態和時效性，這個複雜度和費用都會增長很多。另外一種方案是雙寫數據庫和搜索引擎，可是這個裏面要處理比較複雜的一致性問題。同時，研發須要讀寫兩個不一樣的系統。

上面這種架構已經意識到了傳統數據庫的不足，而且找到了一種解決辦法，只是解決辦法仍然有很大不足。架構

這裏爲何不更進一步，將搜索引擎的能力引入數據庫系統中？若是這個能夠，那麼上述的問題就會迎刃而解，煙消雲散。併發

基於上述的思路，阿里雲歷經十年自研的非關係型（NoSQL）結構化數據表存儲服務 Tablestore 在三年前成功引入了搜索引擎的核心能力：倒排索引、BKD 索引 等，將搜索引擎的能力徹底植入了 NoSQL 數據庫中。less

這個能力在表格存儲（Tablestore）中稱爲：多元索引（SearchIndex）。運維

至此，表格存儲具有了兩大能力：寬表和多元索引，其中寬表引擎相似於 Bigtable，主要面向的是數據的高可靠存儲，解決的是數據規模和擴展問題，而多元索引解決的是數據的查詢檢索的效率和靈活問題。分佈式

當前表格存儲的完整架構和能力大圖以下：高併發

價值

Tablestore 的多元索引相對於傳統方案，除了彌補了上述說的數據庫加搜索引擎方案中的全部缺點外，還在其餘一些方面存在巨大的優點：

• 一個系統，多種能力支持：既能提供數據庫級別的數據可靠性，又能提供搜索引擎具有的豐富查詢能力。
• 應用層架構更簡單：數據存儲和查詢只須要一個系統便可，運維、研發甚至是財務的工做都會更加簡單。
• 查詢能力豐富：支持很是豐富的查詢功能、排序和統計聚合等。能夠知足絕大部分的在線查詢和輕量級分析場景的需求。
• 性能更好：無論是存儲仍是查詢性能，都要比業界開源產品更優，好比 Count 性能比業界最好的 Elasticsearch 還要快 10 倍以上。
• 和 DLA 結合提供複雜分析能力：阿里雲數據湖分析產品 DLA 目前能夠將大部分 SQL 的算子下推到多元索引中，能夠大幅提高 DLA 中分析 SQL 的性能，當前 Tablestore 是 DLA 惟一能夠下推 limit、agg、sort 等算子的數據系統，結合 DLA 就能夠提供更加複雜的分析能力。
• ALL IN ONE 的價值：一份數據同時支持了在線寫入查詢、離線導入導出、輕量級分析和基於 DLA 的完整 SQL 分析能力。這些能力在 Tablestore 中會作多重相應隔離，避免相互影響。因爲是一個系統，客戶研發、運維和財務管理上都會更加簡單。
• 研發效率提高：除了上面這些比較明顯的優點外，還有一個很大的優點是能夠大幅提升研發效率：再也不須要額外部署系統，再也不須要學習多種不一樣系統的接口和行爲，不在須要關注同步鏈路的延遲，不在須要考慮運維等等。從客戶的反饋來看，使用多元索引後，一個基礎功能的研發週期能夠從一個月減小到一週時間，大幅提升產品上線的速度。

功能和能力

表格存儲是阿里雲重金打造的分佈式 NoSQL 產品，核心目標是打造一款海量數據平臺，能夠支持在線、離線和輕量級分析。但願能基於 ALL IN ONE 的設計理念實現客戶在大規模結構化數據存儲和查詢方面的一站式需求。

多元索引在表格存儲產品中的核心定位是數據價值發現，提供了查詢和分析的能力：

查詢能力

當前多元索引在查詢方面的能力比較豐富，沒有傳統數據庫和各類其餘 NoSQL 的最左匹配原則限制，只要建了索引的列就能任意列組合查詢，使用體驗上大幅提高。

同時也支持了數組類型（Array）和相似 Json 的嵌套類型，能夠更容易適配各類應用層的模型，研發效率會更高一些。

除此以外，還有一個傳統數據庫不具有的能力，那就是豐富的分詞能力和全文檢索功能，全文檢索功能支持按照相關性分數排序，或者按照任意列排序結果，其中相關性算法使用了 BM25 算法。

在當前移動互聯網、物聯網和車聯網快速發展的時期，很多應用或者業務中都須要地理位置查詢，好比查詢周圍的人或者電子圍欄的需求，這個時候就須要使用地理位置查詢的功能，這個功能在多元索引中也有提供，在寫入時指定列爲 GeoPoint類型，而後查詢的時候就可使用豐富的地理位置查詢，並且地理位置查詢能夠和其餘索引列一塊兒查詢或過濾，好比和時間結合。

多元索引的查詢能力基本具有了目前現存的最完整的查詢功能，因爲是自研系統，若是有新的業務場景或者新的查詢需求，咱們的快速研發能力也能夠儘快讓新功能推出。

實時分析能力

多元索引也爲在線場景提供了輕量級的實時分析的能力，主要適用在查詢延遲要求毫秒到秒級別的場景中。

• 支持基礎統計聚合：Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等。
• 支持高級統計聚合：直方圖統計、百分位統計等。

咱們的部分輕量級分析功能性能相對於開源系統有 10 倍以上的性能提高。

更重要的是這些輕量級分析相關的請求在內部執行的時候會和其餘在線請求隔離開，不會影響在線請求的可用性。

若是某些場景須要查詢總數或者分組等等，則能夠直接使用多元索引，不用再引入其餘系統。

SQL 分析能力

有些場景中須要 SQL 分析能力，可是不太在乎時間，分鐘級別返回也能夠接受，這個時候可使用多元索引 + 阿里雲數據湖分析 DLA 實現完整分析能力。DLA 是一個 Severless 的分析系統，支持標準的 SQL 能力，能夠將算子下推到底層的存儲系統或者數據庫的。當前表格存儲的多元索引實現了 DLA SQL 中大部分算子，也是 Limit 、Sort、Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等算子惟一能夠下推到存儲層的數據存儲系統。

多元索引和 DLA 結合的分析功能適用於秒級到分組級延遲的複雜分析請求。而多元索引自身的輕量級分析能力適用於毫秒到秒級延遲的簡答分析場景。

更詳細的 DLA 和多元索引的使用能夠參考這篇文章《Tablestore計算下推》。

高併發導出能力

在一些場景中，客戶須要將知足條件的數據快速的導出到外部系統，作一些其餘操做，好比設備數據導出後可能須要爲這些設備發送通知，待分析數據導出到外部的計算系統後作更負責的分析處理和報表生成等。若是在導出前，在存儲系統中就能過濾掉無用數據，快速篩選出最終的數據集合，那麼性能和成本都會更加有優點。

爲了知足這類場景的需求，咱們研發了併發導出功能：ParallelScan。該接口具有下列三個基礎能力：

• 支持完整的查詢功能：包括 Search 接口支持的全部 Query 功能。能夠將無用的數據提早在存儲層過濾掉，減小要傳輸的數據量和成本，提供性能。
• 高吞吐：線上最高能夠支持 1000萬行/秒的篩選導出。
• 斷點續傳：若是在讀取過程當中出現錯誤，此時能夠支持從出錯的位置從新讀取，具有斷點續傳能力。

上述特徵也讓 ParallelScan 在下列場景中能夠發揮出最大的優點：

• 設備中心： 有時候應用須要挑選出知足某些條件的設備或者App，爲他們推送一些通知或者升級信息，這個時候系統須要支持任意條件的自由組合，也要支持快速的從數據庫中拉取出大量設備。
• 計算系統：好比 Spark、Presto、DLA 等計算系統若是出現複雜的 SQL 查詢，可使用 ParallelScan 下推部分算子，將算子過濾後的剩餘結果快速的拉取到計算系統內存中作二次計算，大幅下降成本和提高性能。

動態修改 Schema 和 A/B Test

除了功能外，咱們在易用性方面也在不斷投入，但願能夠大幅簡化客戶的使用體驗和提高研發、運維效率等。客戶使用了多元索引後，因爲多元索引是強 Schema 的產品，若是後續業務須要變動字段，好比新增、刪除、修改類型、修改列名等場景時，須要先新建一個索引，等索引數據都追上後，驗證沒問題，而後再線上作變動，將線上使用的索引換到新索引上，這個過程雖然能夠解決問題，可是存在兩個致命的問題：

• 容易引起故障：可能切換的時候切換錯了索引，也有可能新索引有問題，這些均可以致使線上服務出現問題，引起故障，產生損失。
• 效率極低：這個過程所有要靠人力去作，持續時間長，並且由於是線上變動，每一步都要認認真真，稍一不注意可能會搞錯，須要重來。

基本上每個強 Schema 的系統都會面臨這樣的問題，這個問題雖然看起來是一個小問題，可是對於用戶而言則是一個很痛很痛的點，每一個用戶每月痛一次，若是有幾千個客戶，那麼每月花費在這件事情上的時間和精力就會很是恐怖。爲了真正的讓客戶用起來舒服，簡化使用，解客戶之痛，提高使用者的幸福度，咱們推出了動態修改 Schema功能。

當前咱們的動態修改 Schema 功能具有下列三大功能：

• 支持新增列、刪除列、修改列類型、修改類名字、修改路由鍵等功能。
• 支持新舊索引的 A/B Test。能夠將原索引的流量切部分到新索引上，用於驗證新索引的可用性和延遲狀況。
• 新索引切換時智能提醒能力，避免客戶提早切換致使的數據回退問題。

上述功能目前已經上線，開始邀測中，短短一個月時間內，已經有幾十個客戶在使用，大幅簡化了客戶的使用和下降了風險，好評不斷。預計六月份會徹底對外開放。接下來咱們會有一篇專門文章介紹動態修改 schema 的能力和使用。

場景

增長了多元索引後，表格存儲在一些場景中的適配度變得很是高。

訂單

對於小數據量的訂單，好比小於 2000 萬行的能夠直接用 MySQL，若是更大量的數據量，甚至幾十億、幾百億行的訂單數據使用表格存儲的多元索引會更好。

某互聯網公司當前擁有上百億條歷史訂單數據，將來隨着業務增加訂單量預計每一年會翻倍，當前架構是基於 MySQL 的分庫分表來實現的，可是存在一些痛點：1）分庫分表愈來愈複雜，帶來的運維壓力也愈來愈大；2）慢請求愈來愈多，用戶的投訴不間斷。3）大客戶的查詢常常超時。爲了解決這些痛點，客戶將最新一天的訂單存儲在 MySQL，將全量訂單數據經過 DTS 實時同步到表格存儲，查詢使用多元索引功能，帶來了超出預期的好處：一是再也不須要考慮將來的擴容問題；二是再也不須要運維，主須要關注業務研發便可，效率大幅提高；三是查詢性能最大提高了55倍；四是完全消除了慢請求，用戶的投訴也再也不有了；五是能夠直接結合 DLA 或者 MaxCompute 作更復雜的分析。

更詳細的訂單場景介紹：《大規模訂單系統解讀-架構篇》。

設備元數據

表格存儲的多元索引在去年新推出了併發導出功能，結合以前的特性，使表格存儲在設備元數據管理方面具有了很大的競爭力。

某公司擁有幾百億設備 APP 信息，這些設備信息會實時更新，每秒更新最大會達到 50萬行/s，當有活動或者突發事件時，須要快速圈選出目標APP進行消息推送，圈選的時候須要 具有 1 分鐘內從幾百億設備中圈選出 2 億臺設備的能力。當前架構中多套系統組合使用，存在一些痛點：1）系統衆多，包括了多套存儲和查詢系統、大數據計算系統等，管理複雜，成本高昂。2）時效性查，大規模圈選都是小時級別，知足不了日益增加的運營需求。3）隨着業務增加更新量愈來愈大，原有系統瓶頸愈來愈大。客戶通過半年調研後，將整個系統搬遷到了表格存儲，利用多元索引的查詢和導出能力作實時查詢和在線圈選，帶來了超出預期的效果：1）系統數量減小到一個系統，研發和運維複雜度大幅下降，穩定性更高；2）圈選時效性從小時級別下降到分鐘級別。3）更新速率能夠線性擴展，不在成爲瓶頸。

消息

消息類型存儲（IM、Feed流、通知等）是表格存儲上客戶量最多的的場景之一，表格存儲的高可靠存儲、實時擴展能力、自增列功能能夠大幅簡化存儲庫、同步庫架構以及多元索引提供全方位查詢能力讓消息數據能夠一站式解決存儲、同步和搜索的全部需求。

基於上述優點，阿里巴巴集團內部的大部分 IM 系統的存儲、同步和搜索系統都基於表格存儲，好比內部的釘釘，外部的衆多互聯網和物聯網客戶等。

下圖是一個經典的消息架構圖：

最後

多元索引當前支持阿里雲官網控制檯或者SDK建立，若是是首次使用，能夠參考多元索引快手入門文章，即將發佈。

咱們有一個釘釘公開交流羣，你們能夠加入保持一個更好的溝通交流，釘釘羣號：23307953。

對於重要客戶咱們會免費提供專家服務羣，在羣裏面會有表格存儲各個模塊的核心研發專家，會第一時間解決技術或者穩定性上的問題，爲客戶提供一個絕佳的使用體驗。

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。