NoSQL 應(yīng)用的現(xiàn)狀

什么是 NoSQL？我們知道關(guān)系型數(shù)據(jù)庫強(qiáng)調(diào) CAP 理論：Consistency，Availability 和 Partition Tolerance，這三者不可兼得。談到 NoSQL，我們會引入 BASE 概念：

• Basically Available：分布式系統(tǒng)在出現(xiàn)故障時允許損失部分可用性，以保證核心功能可用。比如在電商場景中，有時交易付款出現(xiàn)了問題，但用戶仍可以正常瀏覽商品。
• Soft State：由于不要求強(qiáng)一致性，BASE 允許系統(tǒng)中存在一種不影響系統(tǒng)可用性的中間狀態(tài)，比如訂單支付中、數(shù)據(jù)同步中等，在數(shù)據(jù)達(dá)到最終一致的狀態(tài)后才改為成功。
• Eventually Consistent：指經(jīng)過一段時間后所有節(jié)點(diǎn)的數(shù)據(jù)將會達(dá)到一致。比如最終支付中的狀態(tài)會變成支付成功或者支付失敗；訂單的狀態(tài)和實(shí)際交易的過程達(dá)成一致；但這個過程有一定的時間延遲。

BASE 理論是對 CAP 中 AP 理論的擴(kuò)展，通過犧牲強(qiáng)一致性獲得可用性。當(dāng)出現(xiàn)故障時，允許部分不可用，但能保證核心功能可用；允許數(shù)據(jù)在一段時間內(nèi)不一致，但最終要達(dá)到一致。NoSQL 大致可以分為以下幾類：

• KV 類：以 Redis 為代表；
• 文檔型：以 MongoDB 為代表；
• 列存：以 HBase 為代表；
• 圖、時序等新興的數(shù)據(jù)庫也都屬于 NoSQL 范疇。

如今 NoSQL 在字節(jié)跳動有非常廣泛的應(yīng)用：數(shù)萬 NoSQL 應(yīng)用實(shí)例，10W+ 臺物理服務(wù)器資源，字節(jié)跳動超過 90% 的在線服務(wù)都是 NoSQL 系統(tǒng)提供的。

NoSQL 產(chǎn)品矩陣

上圖是字節(jié)跳動 NoSQL 的產(chǎn)品矩陣。我們對內(nèi)對外提供了生態(tài)類產(chǎn)品，包括 Redis、HBase、MongoDB 和 InfluxDB。此外自研的平臺上提供了 ByteGraph 和 ABase，這兩者和字節(jié)跳動的業(yè)務(wù)息息相關(guān)，也是內(nèi)部業(yè)務(wù)重度依賴的兩大產(chǎn)品。

字節(jié)跳動 NoSQL 的最新實(shí)踐

字節(jié)跳動的大部分業(yè)務(wù)數(shù)據(jù)可歸納為以下幾種類型：

• 用戶之間的關(guān)系：比如關(guān)注好友等；
• 內(nèi)容：視頻、文章、廣告等；
• 用戶和內(nèi)容的連接：用戶發(fā)布內(nèi)容之后的評論、點(diǎn)贊、轉(zhuǎn)發(fā)等，自媒體還會關(guān)注廣告點(diǎn)擊及分成收益等數(shù)據(jù)。

這三種數(shù)據(jù)關(guān)聯(lián)到一起就會形成圖狀結(jié)構(gòu)。

自研分布式圖數(shù)據(jù)庫

為了滿足內(nèi)部 social graph 在線增刪改查的場景，字節(jié)跳動自研了分布式圖存儲數(shù)據(jù)庫 ByteGraph。針對剛才提到的圖狀數(shù)據(jù)結(jié)構(gòu)，ByteGraph 支持有向?qū)傩缘膱D數(shù)據(jù)模型、Gremlin 查詢語言以及豐富的寫入和查詢接口，具有海量存儲和吞吐能力，單體集群可達(dá)萬億條邊，支持百萬 QPS 圖上多度讀寫。ByteGraph 也支持 Super Node 熱點(diǎn)訪問，單個過億出度節(jié)點(diǎn) 10K 量級 QPS 毫秒級讀寫。

?目前 ByteGraph 基本支持了字節(jié)跳動全系產(chǎn)品，除核心數(shù)據(jù)管理之外，BytrGraph 也支持以下典型場景：

• 風(fēng)控反作弊：在風(fēng)控場景，業(yè)界以前的常用做法是使用 HBase 加上一個計(jì)算引擎。實(shí)際上圖計(jì)算對于風(fēng)控反作弊的異常識別和風(fēng)險檢測更適合。
• 推薦模型：圖訓(xùn)練系統(tǒng)也支持推薦的核心模型，這也是字節(jié)跳動的的一個核心場景。

目前 ByteGraph 在字節(jié)跳動內(nèi)部的使用量有多大？這里列舉一組數(shù)據(jù)：

• 服務(wù) 2000+ 內(nèi)部用戶（這里的用戶指一個業(yè)務(wù)線或者一個小的 App）
• 1000+ 圖數(shù)據(jù)庫集群
• 日均運(yùn)行 1000+ 圖計(jì)算任務(wù)
• 服務(wù)器規(guī)模 1W+ 臺。

字節(jié)跳動為什么要自研這樣一個龐大的系統(tǒng)？作為業(yè)內(nèi)最大的圖生態(tài)之一，現(xiàn)有的一些開源解決方案還不能滿足字節(jié)跳動對圖場景的需求。所以在 2018-2019 年，字節(jié)跳動就嘗試自研分布式圖數(shù)據(jù)庫，最初是為了解決抖音關(guān)系的多度在線查詢（約百萬 QPS），當(dāng)時最主要的功能是支持定制點(diǎn)和邊的接口。在 2019 年-2021 年，ByteGraph 已經(jīng)支持了屬性圖模型和 Gremlin 語法，也在公司內(nèi)部廣泛落地，集群數(shù)量快速擴(kuò)張，并逐步標(biāo)準(zhǔn)化。

目前字節(jié)跳動在圖數(shù)據(jù)庫方面的多篇論文已被 VLDB 等數(shù)據(jù)庫頂會收錄，ByteGraph 預(yù)計(jì)在今年年底也將通過火山引擎提供給更多用戶。

圖計(jì)算系統(tǒng)

從圖數(shù)據(jù)庫又引申出來一個非常大的概念——圖計(jì)算。舉個例子，在 Google 上搜索時，需要基于網(wǎng)頁的鏈接關(guān)系計(jì)算每個頁面的 page rank，從而對頁面進(jìn)行排序。頁面的鏈接關(guān)系其實(shí)就是一張圖，基于網(wǎng)頁鏈接關(guān)系的 page rank 計(jì)算，就是在這張圖上運(yùn)行一個圖算法，即圖計(jì)算。

小規(guī)模的圖可以通過單機(jī)來進(jìn)行計(jì)算，但如今隨著業(yè)務(wù)數(shù)據(jù)量的增大，一般都需要引入分布式計(jì)算系統(tǒng)來解決問題，并且需要系統(tǒng)能高效運(yùn)行各類圖算法，做大規(guī)模的數(shù)據(jù)處理。

字節(jié)跳動早期時有不少業(yè)務(wù)使用 MapReduce 和 Spark 來實(shí)現(xiàn)圖算法。得益于批處理系統(tǒng)的廣泛使用，業(yè)務(wù)同學(xué)能夠快速上線算法邏輯。但批處理（batch processing）本身是為處理并行數(shù)據(jù)而設(shè)置的，能輕易將工作負(fù)載分散到不同機(jī)器上，并行處理大量的數(shù)據(jù)。

MapReduce 的過程是 Map 先切割，然后并行處理，再進(jìn)行 Reduce。但是圖數(shù)據(jù)比較特殊，天生就有關(guān)聯(lián)性，無法像以前常用的行式數(shù)據(jù)一樣直接切割。

如果用批處理系統(tǒng)來運(yùn)行圖的算法，就需要引入大量 shuffle 操作來實(shí)現(xiàn)關(guān)系的連接。但 shuffle 操作非常重，不僅會導(dǎo)致任務(wù)的運(yùn)行時間變長，還會浪費(fèi)非常多的計(jì)算資源。

為了解決這一系列的問題，字節(jié)跳動引入了圖計(jì)算系統(tǒng)。目前該系統(tǒng)支持超大規(guī)模圖萬億點(diǎn)邊規(guī)模上的計(jì)算訓(xùn)練，支持動態(tài)超高吞吐（百萬吞吐級別）的訓(xùn)練和推理，同時支持內(nèi)存/SSD 混合介質(zhì)的數(shù)據(jù)處理及 fault-tolerance，十億點(diǎn)邊超大圖的處理僅在分鐘級。

?為了讓用戶使用更方便，我們提供了一站式的圖數(shù)據(jù)分析與管理平臺，集成圖計(jì)算、圖訓(xùn)練的產(chǎn)品能力，廣泛對接公司內(nèi)核心業(yè)務(wù)場景。字節(jié)跳動在風(fēng)控、電商、搜索、推薦等領(lǐng)域的典型圖分析應(yīng)用方案都沉淀在該平臺，能做到開箱即用。

ABase

ABase 是字節(jié)跳動自研的 KV 存儲服務(wù)，具有大容量、高吞吐、高可用（容災(zāi))、多地域、低延時、易使用、低成本的特點(diǎn)。隨著字節(jié)跳動的業(yè)務(wù)規(guī)模不斷擴(kuò)張，急劇增長的數(shù)據(jù)量在可用性和性能、跨地域同步、同城容災(zāi)能力、資源和成本優(yōu)化等方面對 KV 存儲系統(tǒng)提出了更高的要求。我們希望 ABase 能支持的場景包括：

• 持久化 KV
• 兼容 Redis 協(xié)議，提供比 Redis 更大容量的緩存
• Redis 復(fù)雜命令
• 數(shù)據(jù)生態(tài)同步：支持?jǐn)?shù)據(jù)的備份/回滾，F(xiàn)aaS 數(shù)據(jù)訂閱，支持 ABase to Hive， Hive to ABase，方便用戶在線查詢和分析的轉(zhuǎn)換
• 跨地區(qū)同步：支持多活
• 邊緣存儲：給邊緣機(jī)房提供近地讀寫服務(wù)

對于上述這些要求，第一代的 ABase 無法完全滿足，所以我們引入了 ABase 第二代無主架構(gòu)，實(shí)現(xiàn)多點(diǎn)寫入，從高可用達(dá)到了極高可用。機(jī)器硬件或網(wǎng)絡(luò)都會有一定的故障率，常見的高可用方案是使用多副本、熱備的形式。常見的主從架構(gòu)有一個寫入點(diǎn)，主節(jié)點(diǎn)故障時，系統(tǒng)通過 HA 策略自動切換到熱備的從節(jié)點(diǎn)，這樣一般就成為高可用了。

?但在生產(chǎn)環(huán)節(jié)有兩個問題：

1. 主節(jié)點(diǎn)故障需要一系列的檢測機(jī)制，工業(yè)界的實(shí)現(xiàn)一般在 1s 以上， 而 ABase 的用戶最長只能接受毫秒級別的延時，秒級別的切主還是會造成整個過程的寫失敗。
2. 傳統(tǒng)的主故障探測對于慢節(jié)點(diǎn)的自動檢測和快速處理比較困難。

Abase 第二代采用無主架構(gòu)來解決這兩個問題，支持任意點(diǎn)寫入，沒有主節(jié)點(diǎn)故障后需要的切主時間，也不會受到單一慢節(jié)點(diǎn)影響，因此任何單一節(jié)點(diǎn)故障對可用性零影響，同時可規(guī)避慢節(jié)點(diǎn)，縮短 P99 延時。

ABase 核心流程架構(gòu)

傳統(tǒng)的 qourum 無主架構(gòu)修復(fù)數(shù)據(jù)一般需要構(gòu)建 Merkle tree，會造成海量 KV 場景數(shù)據(jù)達(dá)成一致的時間非常長，理論上有時可能是周級別。數(shù)據(jù)一致性依賴讀 qourum，讀吞吐的能力又非常浪費(fèi)。

ABase 自研的無主快速一致算法借鑒了有主架構(gòu)的同步方式，限制了寫入流的數(shù)，只在必要情況下亂序同步，這樣大幅度提高了數(shù)據(jù)達(dá)到一致的速度，數(shù)據(jù)修復(fù)不必再依賴讀取，也可充分發(fā)揮整個系統(tǒng)的讀性能。

?另一方面，為了解決沖突，ABase 將數(shù)據(jù)的 HLC 時間戳編碼在 key 結(jié)構(gòu)上，這樣用戶沖突就可以自然解決了。然而引入這種機(jī)制之后，要找同一個 Key 的所有版本中時間戳最大的一個，這樣點(diǎn)查詢的性能會惡化。

為了解決這個問題，我們引入了雙引擎結(jié)構(gòu)：多版本只存在 log engine 中。當(dāng)完成沖突處理之后，單版本寫入 KV engine，這樣絕大部分的查詢都是點(diǎn)查詢，不再需要查看所有版本。log engine 中的索引是全內(nèi)存的，這樣多版本查詢就不會影響性能。

?以上就是 ABase 第二代引入無主架構(gòu)所做的 trade-off。ABase 現(xiàn)狀?經(jīng)過優(yōu)化后，ABase 目前可用性和性能上都大大提升。

• 極高可用：直接屏蔽慢節(jié)點(diǎn)，無主從切換不可用時間，可一直寫入。
• 全球化部署：快速的一致性算法；支持 Zset，List 等復(fù)雜數(shù)據(jù)結(jié)構(gòu)的 CRDT 方案。
• 支持高性能架構(gòu)：包括 RunToComplete 架構(gòu)、KV 分離/全內(nèi)存索引、FIFO log 優(yōu)化。
• 支持 Serverless 存儲：多租戶 QoS 保證、多維度的負(fù)載均衡調(diào)度、極致的資源利用率。

字節(jié)跳動目前已有 5000+ 業(yè)務(wù)在使用 ABase，服務(wù)器超過 5W 臺，請求量達(dá)到百億級，數(shù)據(jù)規(guī)模百 PB 級，在 30+ 地域多地部署。

NoSQL 技術(shù)未來發(fā)展趨勢

最后我們對 NoSQL 技術(shù)的未來發(fā)展趨勢做一個簡單的預(yù)判。我們重新再來回答一下什么是 NoSQL。我認(rèn)為 NoSQL 不僅是 not only SQL 也不僅是沒有 SQL 語言，我對 NoSQL 的定義是高性能彈性存儲+可擴(kuò)展性動態(tài)計(jì)算的數(shù)據(jù)庫。

現(xiàn)在我們從數(shù)據(jù) Schema 維度審視，NoSQL 代表了半結(jié)構(gòu)化和非結(jié)構(gòu)化的數(shù)據(jù)處理。“處理”既包括計(jì)算，也包含存儲。從 CAP 理論維度來看，NoSQL 強(qiáng)調(diào)的是“最大化” P，也就是彈性規(guī)?；芰?，在 C 和 A 上不同的場景各有不同權(quán)衡。

最后再看看未來的機(jī)遇。根據(jù) Gartner 的統(tǒng)計(jì)，2025 年全球會有 175ZB 的數(shù)據(jù)需求，其中大部分是非結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)，并且會大量沉淀在 TOS/S3 等存儲產(chǎn)品中，這些數(shù)據(jù)的存儲和計(jì)算都蘊(yùn)含大量的機(jī)遇。當(dāng)然機(jī)遇與挑戰(zhàn)并存，誰能解決數(shù)據(jù)的處理（存儲+計(jì)算）問題，誰就能立于不敗之地。

我認(rèn)為 NoSQL 未來會有兩個極致的方向：一個是極致的高性能 KV 系統(tǒng)，以 Redis 為代表；另一個就是海量大規(guī)模的 KV 系統(tǒng)，以前文介紹的 ByteGraph 和 ABase 為代表。對于字節(jié)跳動的 NoSQL 來說，我們在朝著以下方向努力：

• 利用 Cloud Native、Serverless 能力，實(shí)現(xiàn)極致彈性和性價比、精細(xì)化的資源調(diào)度；
• 強(qiáng)調(diào)數(shù)據(jù)增值能力和數(shù)據(jù)共享，對計(jì)算（包括分析和 AI）的需求越來越重；
• 融合多樣化的非結(jié)構(gòu)/半結(jié)構(gòu)數(shù)據(jù) Schema，統(tǒng)一存儲，統(tǒng)一計(jì)算；
• 軟硬件結(jié)合，帶來數(shù)量級革命的技術(shù)升級；
• 產(chǎn)品界面標(biāo)準(zhǔn)化，增強(qiáng) Redis 生態(tài)能力建設(shè)與 SQL 生態(tài)能力建設(shè)。

我認(rèn)為 NoSQL 在接下來幾年里最大的發(fā)展趨勢是能存下所有數(shù)據(jù)，并且能夠又快又好地計(jì)算出來，讓用戶看到數(shù)據(jù)存儲的價值。

現(xiàn)在 NoSQL 和關(guān)系型數(shù)據(jù)庫的界限變得越來越模糊了，所以數(shù)據(jù)庫在不斷形成各種分支的同時，也在不停地融合，這就是今天技術(shù)發(fā)展的趨勢和方向。