NoSQL 應用的現(xiàn)狀

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

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

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

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

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

NoSQL 產(chǎn)品矩陣

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

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

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

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

這三種數(shù)據(jù)關聯(lián)到一起就會形成圖狀結構。

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

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

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

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

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

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

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

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

圖計算系統(tǒng)

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

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

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

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

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

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

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

ABase

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

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

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

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

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

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

ABase 核心流程架構

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

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

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

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

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

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

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

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

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

現(xiàn)在我們從數(shù)據(jù) Schema 維度審視，NoSQL 代表了半結構化和非結構化的數(shù)據(jù)處理?！疤幚怼奔劝ㄓ嬎悖舶鎯?。從 CAP 理論維度來看，NoSQL 強調(diào)的是“最大化” P，也就是彈性規(guī)?；芰?，在 C 和 A 上不同的場景各有不同權衡。

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

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

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

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

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