本文旨在介紹 vivo 內(nèi)部的特征存儲(chǔ)實(shí)踐、演進(jìn)以及未來展望，拋磚引玉，吸引更多優(yōu)秀的想法。

一、需求分析

AI 技術(shù)在 vivo 內(nèi)部應(yīng)用越來越廣泛，其中特征數(shù)據(jù)扮演著至關(guān)重要的角色，用于離線訓(xùn)練、在線預(yù)估等場景，我們需要設(shè)計(jì)一個(gè)系統(tǒng)解決各種特征數(shù)據(jù)可靠高效存儲(chǔ)的問題。

1. 特征數(shù)據(jù)特點(diǎn)

（1）Value 大

特征數(shù)據(jù)一般包含非常多的字段，導(dǎo)致最終存到 KV 上的 Value 特別大，哪怕是壓縮過的。

（2）存儲(chǔ)數(shù)據(jù)量大、并發(fā)高、吞吐大

特征場景要存的數(shù)據(jù)量很大，內(nèi)存型的 KV（比如 Redis Cluster）是很難滿足需求的，而且非常昂貴。不管離線場景還是在線場景，并發(fā)請(qǐng)求量大，Value 又不小，吞吐自然就大了。

（3）讀寫性能要求高，延時(shí)低

大部分特征場景要求讀寫延時(shí)非常低，而且持續(xù)平穩(wěn)，少抖動(dòng)。

（4）不需要范圍查詢

大部分場景都是單點(diǎn)隨機(jī)讀寫。

（5）定時(shí)灌海量數(shù)據(jù)

很多特征數(shù)據(jù)剛被算出來的時(shí)候，是存在一些面向 OLAP 的存儲(chǔ)產(chǎn)品上，而且定期算一次，希望有一個(gè)工具能把這些特征數(shù)據(jù)及時(shí)同步到在線 KV 上。

（6）易用

業(yè)務(wù)在接入這個(gè)存儲(chǔ)系統(tǒng)時(shí)，最好沒有太大的理解成本。

2. 潛在需求

擴(kuò)展為通用磁盤 KV，支撐各個(gè)場景的大容量存儲(chǔ)需求

我們的目標(biāo)是星辰大海，絕不僅限于滿足特征場景。

支撐其他 Nosql/Newsql 數(shù)據(jù)庫，資源復(fù)用

從業(yè)務(wù)需求出發(fā)，后續(xù)我們會(huì)有各種各樣 Nosql 數(shù)據(jù)庫的需求，如圖數(shù)據(jù)庫、時(shí)序數(shù)據(jù)庫、對(duì)象存儲(chǔ)等等，如果每個(gè)產(chǎn)品之間都是完全隔離，沒有任何資源（代碼、平臺(tái)能力等等）復(fù)用，維護(hù)成本是巨大的。

可維護(hù)性強(qiáng)

首先實(shí)現(xiàn)語言不能太小眾，否則人才招聘上會(huì)比較困難，而且最好能跟我們的技術(shù)棧發(fā)展方向匹配。

架構(gòu)設(shè)計(jì)上不能依賴太多第三方服務(wù)組件，降低運(yùn)維的復(fù)雜性。

3. 存儲(chǔ)系統(tǒng)的冰山

綜合以上需求，最終我們決定兼容 Redis 協(xié)議，用戶看到的只是一個(gè)類似單機(jī)版的 Redis 服務(wù)，但背后我們做了大量的可靠性保障工作。

二、方案選型

在方案選型上，我們遵循一些基本原則：

源自開源，按需定制。

內(nèi)部開源，集思廣益。

語言主流，架構(gòu)主流。

可靠至上，高可維護(hù)。

先簡單介紹一下我們?cè)缙诜桨刚{(diào)研的一些優(yōu)缺點(diǎn)分析：

說實(shí)話，調(diào)研的都是優(yōu)秀的開源項(xiàng)目，但光靠官方代碼和設(shè)計(jì)文檔，沒有深入的實(shí)踐經(jīng)驗(yàn)，我們是很難斷定一個(gè)開源產(chǎn)品是真正適合我們的，適當(dāng)?shù)馁愸R可以更好校準(zhǔn)方案選型，同時(shí)也一定程度反映出我們較強(qiáng)的執(zhí)行力。

總的來說我們是要在現(xiàn)有需求、潛在需求、易用性、架構(gòu)先進(jìn)性、性能、可維護(hù)性等各個(gè)方面中找到一個(gè)最優(yōu)平衡，經(jīng)過一段時(shí)間的理論調(diào)研和實(shí)踐以后，最終我們選擇了 Nebula。

三、Nebula 簡介

Nebula Graph 是一個(gè)高性能、高可用、高可靠、數(shù)據(jù)強(qiáng)一致的、開源的分布式圖數(shù)據(jù)庫。

1. 存儲(chǔ)計(jì)算分離

Nebula 采用存儲(chǔ)計(jì)算分離的設(shè)計(jì)，有狀態(tài)的存儲(chǔ)服務(wù) 和 無狀態(tài)的計(jì)算服務(wù) 是分層的，使得存儲(chǔ)層可以集中精力提升數(shù)據(jù)可靠性，只暴露簡單的 KV 接口，計(jì)算層可以聚焦在用戶直接需要的計(jì)算邏輯上，而且大大提升運(yùn)維部署的靈活性。

不過作為圖數(shù)據(jù)庫，為了提升性能，Nebula 把一部分圖計(jì)算邏輯下沉到存儲(chǔ)層，這也是靈活性與性能之間的一個(gè)比較現(xiàn)實(shí)的權(quán)衡。

2. 強(qiáng)一致，架構(gòu)主流

Nebula 的強(qiáng)一致使用 Raft，是目前實(shí)現(xiàn)多副本一致性的主流方法，而且這個(gè) Raft 實(shí)現(xiàn)已經(jīng)初步通過了 Jepsen 線性一致性測試，作為一個(gè)剛起步不久的開源項(xiàng)目，對(duì)增加用戶的信心很有幫助。

3. 可伸縮

Nebula 的橫向擴(kuò)展能力得益于其 Hash-based 的 Multi-raft 實(shí)現(xiàn)，同時(shí)自帶一個(gè)用于負(fù)載均衡的調(diào)度器（Balancer），架構(gòu)和實(shí)現(xiàn)都比較簡潔（至少目前還是），上手成本低。

4.易維護(hù)

Nebula 內(nèi)核使用 C++ 實(shí)現(xiàn)，跟我們基礎(chǔ)架構(gòu)的技術(shù)棧發(fā)展方向比較匹配。經(jīng)過評(píng)估，Nebula 一些基本的平臺(tái)能力（如監(jiān)控接口、部署模式）比較簡單易用，跟我們自身平臺(tái)能很好對(duì)接。

代碼實(shí)現(xiàn)做了較好抽象，可以靈活支持多種存儲(chǔ)引擎，為我們后來針對(duì)特征場景的性能優(yōu)化奠定了很好的基礎(chǔ)。

四、Nebula Raft 簡介

上文提到 Nebula 是依賴 Raft 保證強(qiáng)一致的，這里簡單介紹一下 Nebula Raft 的特點(diǎn)：

1. 選主 與 任期

一個(gè) Raft Group 的生命周期是由一個(gè)又一個(gè)連續(xù)的任期組成的，每個(gè)任期開始會(huì)選出一個(gè) Leader，其他成員為 Follower，一個(gè)任期內(nèi)只有一個(gè) Leader，如果任期內(nèi) Leader 不可用，會(huì)馬上進(jìn)入下一個(gè)任期，選新的 Leader。這種 Strong Leader 機(jī)制使得 Raft 的工程實(shí)現(xiàn)難度遠(yuǎn)低于它的祖師爺 - Paxos。

2. 日志復(fù)制、壓縮

標(biāo)準(zhǔn)的 Raft 實(shí)現(xiàn)中，每個(gè)從客戶端來的寫請(qǐng)求都會(huì)轉(zhuǎn)換成 “操作日志” 寫到 wal 文件中，Leader 在把操作日式更新到自己狀態(tài)機(jī)后，會(huì)主動(dòng)向所有 Follower 異步復(fù)制日志，直到超過半數(shù)的 Follower 應(yīng)答后，才返回客戶端寫入成功。

實(shí)際運(yùn)行中，wal 的文件會(huì)越來越大，如果沒有一個(gè)合理的 wal 日志回收機(jī)制，wal 文件將很快占滿整個(gè)磁盤，這個(gè)回收機(jī)制就是日志壓縮（Log Compaction）。Nebula 的 Log Compaction 實(shí)現(xiàn)比較簡潔，用戶只需要配置一個(gè) wal_ttl 參數(shù)，即可在不破壞集群正確性的前提下，把 wal 文件的空間占用控制在一個(gè)穩(wěn)定的范圍。

Nebula 實(shí)現(xiàn)了 Raft batch 和 pipeline 機(jī)制，支持 Leader 到 Follower 的批量和亂序日志提交，在高并發(fā)場景下，能有效提升集群整體吞吐能力。

3. 成員變更

跟典型的 Raft 實(shí)現(xiàn)類似，這里著重提一下 Nebula Raft 的 Snapshot 機(jī)制。

當(dāng)一個(gè) Raft Group 增加成員時(shí)，新成員節(jié)點(diǎn)需要從當(dāng)前的 Leader 中獲取所有的日志并重放到自身的狀態(tài)機(jī)中，這是一個(gè)不容小覷的資源開銷，對(duì) Leader 造成較大的壓力。為此一般的 Raft 會(huì)提供一個(gè) Snapshot 機(jī)制，以此解決節(jié)點(diǎn)擴(kuò)容的性能問題，以及節(jié)點(diǎn)故障恢復(fù)的時(shí)效問題。

Snapshot，即 Leader 把自身狀態(tài)機(jī)打成一個(gè)“鏡像”單獨(dú)保存，在 Nebula Raft 實(shí)現(xiàn)中，“鏡像”就是 Rocksdb 實(shí)例（即狀態(tài)機(jī)本身），新成員加入時(shí)，Leader 會(huì)調(diào)用 Rocksdb 的 Iterator 掃描整個(gè)實(shí)例，過程中把讀到的值分批發(fā)送給新成員，最終完成整個(gè) Snapshot 的拷貝過程。

4. Multi-raft 實(shí)現(xiàn)

如果一個(gè)集群只有一個(gè) Raft Group，很難通過加機(jī)器實(shí)現(xiàn)橫向擴(kuò)展，適用場景非常有限，自然想到的方法就是把集群的數(shù)據(jù)拆分出多個(gè)不同的 Raft Group，這里就引入了 2 個(gè)新問題：（1）數(shù)據(jù)如何分片（2）分片如何均勻分布到集群中。

實(shí)現(xiàn) Multi-raft 是一個(gè)有挑戰(zhàn)且很有意思的事情，業(yè)界有 2 種主流的實(shí)現(xiàn)方式，一種是 Hash-based 的，一種是 Region-based，各有利弊，大部分情況下，前者比較簡單有效，Nebula 目前采用 Hash-based 的方式，也是我們需要的，但面向圖場景，后續(xù)有沒有進(jìn)一步的規(guī)劃，需要持續(xù)關(guān)注社區(qū)動(dòng)態(tài)。

五、特征存儲(chǔ)平臺(tái)介紹

1. 系統(tǒng)架構(gòu)

在 Nebula 原有架構(gòu)基礎(chǔ)上，增加了一些組件，包括 Redis Proxy、Rediscluster Proxy 以及平臺(tái)化相關(guān)的組件。

Meta 實(shí)例是存整個(gè)集群的元信息，包括數(shù)據(jù)分片路由規(guī)則，space 信息等等，其本身也是一個(gè) Raft Group。

Storage 實(shí)例是實(shí)際存數(shù)據(jù)的節(jié)點(diǎn)，假設(shè)一個(gè)集群多個(gè)分片對(duì)應(yīng) m 個(gè) Raft Group，每個(gè) Raft Group 對(duì)應(yīng) n 個(gè)副本，Nebula 就是把 m * n 個(gè)副本均勻分布到這多個(gè) Storage 實(shí)例中，并力求每個(gè)實(shí)例中的 Leader 數(shù)也相近。

Graph 實(shí)例是圖 API 的服務(wù)提供者以及整個(gè)集群的 Console，無狀態(tài)。

Redis 實(shí)例兼容了 Redis 協(xié)議，實(shí)現(xiàn)了部分 Redis 原生的數(shù)據(jù)結(jié)構(gòu)，無狀態(tài)。

Rediscluster 實(shí)例兼容了 Redis Cluster 協(xié)議，無狀態(tài)。

2. 性能優(yōu)化

（1）集群調(diào)優(yōu)

實(shí)際接入生產(chǎn)業(yè)務(wù)時(shí)，往往需要針對(duì)不同場景調(diào)整參數(shù)，這個(gè)工作在在早期占用了大量的時(shí)間，但確實(shí)也為我們積累寶貴的經(jīng)驗(yàn)。

（2）WiscKey

前文提到的大部分特征場景的 Value 都比較大，單純依賴 Rocksdb 會(huì)導(dǎo)致嚴(yán)重的寫放大，原因在于頻繁觸發(fā) Compaction 邏輯，而且每次 Compaction 的時(shí)候都會(huì)把 Key 和 Value 從磁盤掃出來，在 Value 大的場景下，這個(gè)開銷非常可怕。為此學(xué)術(shù)界提出過一些解決方案，其中 WiscKey 以實(shí)用性而廣受認(rèn)可，工業(yè)界也落地了其開源實(shí)現(xiàn)（Titandb）。

Titandb 詳細(xì)原理可參考其 官方文檔，簡單來說，就是改造 Rocksdb，兼容對(duì)外接口，保留 LSM-tree，新增 BlobFile 存儲(chǔ)，Key Value 分離存儲(chǔ)，Key 存 LSM-tree，Value 存 BlobFile，依賴 SSD 磁盤隨機(jī)讀寫性能，犧牲范圍查詢性能，減少大 Value 場景下的寫放大。

得益于 Nebula 支持多存儲(chǔ)引擎的設(shè)計(jì)，Titandb 很輕松就集成到 Nebula Storage，在實(shí)際生產(chǎn)中，的確在性能上給我們帶來不錯(cuò)的收益。

3. TTL 機(jī)制

不管是 Rocksdb， 還是 Titandb，都兼容了 Compaction Filter 接口，即在 Compaction 的時(shí)候會(huì)調(diào)用這個(gè) Filter 來判斷是否需要過濾掉具體的數(shù)據(jù)。我們?cè)趯?shí)際寫入 Storage 的 Value 中種入了 TTL，在 Compaction Filter 的時(shí)候，掃描每個(gè) Value，提取出 TTL 判斷 Value 是否過期了，如果是，則刪除掉對(duì)應(yīng) Key-Value 對(duì)。

然而，實(shí)踐中我們發(fā)現(xiàn)，Titandb 在 Compaction 的時(shí)候，如果 Value 很大被分離到 BlobFile 后，F(xiàn)ilter 是讀不到具體 Value 的（只有留在 LSM-tree 里的小 Value 才能被讀到）。這就對(duì)我們 TTL 機(jī)制造成很大的不利，導(dǎo)致過期的數(shù)據(jù)沒有辦法回收。為此，我們做了一點(diǎn)特殊處理，當(dāng)大 Value 被分離到 BlobFile 后，LSM-tree 里會(huì)存 Key-Index 對(duì)，Index 就是 Value 在 BlobFile 中的位置，我們嘗試把 TTL 種到 Index 中，使得 Filter 時(shí)能解析出 TTL，從而實(shí)現(xiàn)所有過期數(shù)據(jù)的物理刪除。

4. 易用

易用性是一個(gè)數(shù)據(jù)庫走向成熟的標(biāo)志，是一個(gè)很大的課題。

從不同用戶的視角出發(fā)，會(huì)引申出不同的需求集合，用戶角色可以包括 運(yùn)維 dba、業(yè)務(wù)研發(fā)工程師、運(yùn)維工程師等等，最終我們希望在各個(gè)視角都能超出預(yù)期，實(shí)現(xiàn)真正高易用的存儲(chǔ)產(chǎn)品。這里簡單介紹我們?cè)谝子眯陨系囊恍?shí)踐：

（1）兼容 redis 協(xié)議

我們改造了美圖開源的 KVrocks（一個(gè)基于 Rocksdb 的兼容 redis 協(xié)議的單機(jī)磁盤 KV 產(chǎn)品），依賴 Nebula C++ 版本的 Storage Client，把底層依賴 Rocksdb 的邏輯替換成 Nebula Storage KV 接口的讀寫邏輯，從而實(shí)現(xiàn)一個(gè)無狀態(tài)的 redis 協(xié)議兼容層（Proxy），同時(shí)我們根據(jù)實(shí)際需要額外實(shí)現(xiàn)了一些命令。當(dāng)然，我們只是針對(duì)特征場景實(shí)現(xiàn)了一些 redis 命令，要在分布式 KV 基礎(chǔ)上兼容所有 redis 的指令，需要考慮分布式事務(wù)，這里我先賣個(gè)關(guān)子，敬請(qǐng)期待。

（2）支持從 Hive 批量導(dǎo)入數(shù)據(jù)到 KV

對(duì)特征場景來說，這個(gè)功能也是易用性的一種體現(xiàn)，Nebula 目前針對(duì)圖結(jié)構(gòu)的數(shù)據(jù)已經(jīng)實(shí)現(xiàn)了從 Hive 導(dǎo)數(shù)據(jù)，稍加改造就能兼容 KV 格式。

（3）平臺(tái)化運(yùn)維

前期我們?cè)诠才渲?a target="_blank">中心上維護(hù)了所有線上集群的元信息，并落地了一些簡單的作業(yè)，如一鍵部署集群、一鍵卸載集群、定時(shí)監(jiān)控上報(bào)、定時(shí)命令正確性檢查、定時(shí)實(shí)例健康檢測、定時(shí)集群負(fù)載監(jiān)控等等，能滿足日常運(yùn)維的基本需求。同時(shí)，vivo 內(nèi)部在建設(shè)一個(gè)功能完善的 DBaaS 平臺(tái)，已經(jīng)實(shí)際支撐了不少 DB 產(chǎn)品的平臺(tái)化運(yùn)維，包括 redis、mysql、elasticsearch、mongodb 等等，大大提升業(yè)務(wù)的數(shù)據(jù)管理效率，所以，最終特征存儲(chǔ)是要跟平臺(tái)全面結(jié)合、共同演進(jìn)，不斷實(shí)現(xiàn)產(chǎn)品易用性和健壯性的突破。

5. 災(zāi)備

（1）定期冷備

Nebula 本身提供了冷備機(jī)制，我們只需要設(shè)計(jì)好個(gè)性化的定時(shí)備份策略，即可較好滿足業(yè)務(wù)需求，這里不詳細(xì)描述，感興趣可以看看 Nebula 的 集群快照機(jī)制。

（2）實(shí)時(shí)熱備

熱備落地一共分兩期：

第一期：比較簡單，只考慮增量備份，且容忍有損。

目前 KV 主要服務(wù)特征場景（或緩存場景），對(duì)數(shù)據(jù)可靠性要求不是特別高，而且數(shù)據(jù)在存儲(chǔ)中駐留的時(shí)間不會(huì)很長，很快就會(huì)被 TTL 清理掉。為此熱備方案中暫不支持存量數(shù)據(jù)的備份。

至于增量備份，就是在 Proxy 層把 “寫請(qǐng)求” 再異步寫一次到備集群，主集群還是繼續(xù)執(zhí)行同步寫，只要 Proxy cpu 資源足夠，不會(huì)影響主集群本身的讀寫性能。這里會(huì)存在數(shù)據(jù)丟失的風(fēng)險(xiǎn)，比如 Proxy 異步?jīng)]寫完，進(jìn)程突然掛了，這時(shí)備集群是會(huì)丟一點(diǎn)數(shù)據(jù)的，但正如之前提到，大部分特征場景（或緩存場景）對(duì)這種程度的數(shù)據(jù)丟失是可容忍。

第二期： 既保證增量備份，也要保證存量備份。

Nebula Raft 引入了 Learner，它也是 Raft Group 中的一個(gè)副本，但既不參與選主，也不影響多數(shù)派提交，它只是默默的接收來自 Leader 的日志復(fù)制請(qǐng)求。跟其他 Follower 一樣，Learner 一旦掛了，Leader 會(huì)不斷重試復(fù)制日志給 Learner，直到 Learner 重啟恢復(fù)。

有了這個(gè)機(jī)制，要實(shí)現(xiàn)存量備份就變的簡單了，我們可以實(shí)現(xiàn)一個(gè)災(zāi)備組件，偽裝成 Learner，掛到 Raft Group 中，這時(shí) Raft 的成員變更機(jī)制會(huì)保證 Leader 中的存量數(shù)據(jù)和增量數(shù)據(jù)都能以日志的形式同步給災(zāi)備組件，同時(shí)組件另一側(cè)依賴 Nebula Storage Client 把源日志數(shù)據(jù)轉(zhuǎn)換成寫請(qǐng)求應(yīng)用到災(zāi)備集群。

6. 跨機(jī)房雙活

雙活也是分兩期落地：

第一期：不考慮沖突處理，不保證集群間的最終一致。

這個(gè)版本的實(shí)現(xiàn)同樣簡單，可以理解是 2 個(gè)集群互為災(zāi)備，對(duì)有同城雙活、故障轉(zhuǎn)移需求，對(duì)最終一致性要求不高的業(yè)務(wù)還是很有幫助的。

第二期：引入 CRDT 處理沖突，實(shí)現(xiàn)最終一致。

這個(gè)版本對(duì)可靠性的要求比較高，復(fù)用災(zāi)備二期的能力，在 Learner 中獲取集群的寫請(qǐng)求日志。

一般雙活情況下，兩個(gè) KV 集群會(huì)分布在不同機(jī)房，單元化的業(yè)務(wù)服務(wù)會(huì)各自讀寫本機(jī)房 KV 的數(shù)據(jù)，兩個(gè)不同機(jī)房的 KV 相互同步變更。假如兩個(gè) KV 更新了同一個(gè) Key，并同步給對(duì)方，這時(shí)應(yīng)該怎么處理沖突呢？

最簡單直接的方案就是最 “晚” 寫的數(shù)據(jù)更新到兩個(gè) KV，保證最終一致，這里的 “晚” 不是指絕對(duì)意義上的先來后到，而是根據(jù)寫操作發(fā)生的時(shí)間戳，同一個(gè) Key 兩個(gè)機(jī)房的寫操作都能取到各自的時(shí)間戳，但機(jī)房之間時(shí)鐘不一定同步，這就可能導(dǎo)致實(shí)際先發(fā)生的操作 時(shí)間戳可能更大，但我們的目標(biāo)是實(shí)現(xiàn)最終一致，不是跟時(shí)鐘同步機(jī)制較勁，所以問題不大。針對(duì)這個(gè)思路，知名最終一致性方案 CRDT 已經(jīng)給出了相應(yīng)的標(biāo)準(zhǔn)實(shí)現(xiàn)。

KV 實(shí)際存的數(shù)據(jù)只有 String 類型，對(duì)應(yīng)于 CRDT 里的 Register 數(shù)據(jù)結(jié)構(gòu)，其中一種實(shí)現(xiàn)就是 Op-based LWW（Last-Write-Wins） Register，顧名思義，就是最 “晚” 寫的 Value 成為最終一致的狀態(tài)，算法原型如下：

對(duì) CRDT 感興趣的可以看看網(wǎng)上的其他資料，這里不詳細(xì)描述。

慶幸的是，vivo 內(nèi)部已經(jīng)在 Redis Cluster 上實(shí)現(xiàn)了 CRDT Register ，并提供了保障數(shù)據(jù)跨機(jī)房可靠傳輸?shù)慕M件，使得新 KV 存儲(chǔ)可以站在巨人的肩膀上。需要注意的是，KV 線上大量 mset 的寫請(qǐng)求，而 CRDT Register 只支持單個(gè) Set 的請(qǐng)求沖突處理，所以在雙活組件 Learner 中，從 Leader 收到的 Batch Write 請(qǐng)求需要拆解成一個(gè)一個(gè)的 Set 命令，然后再同步給 Peer 集群。

六、未來展望

1. 擴(kuò)展成通用 KV 存儲(chǔ)

我們立項(xiàng)特征存儲(chǔ)的時(shí)候，就目標(biāo)要做成通用 KV 存儲(chǔ)，成為更多數(shù)據(jù)庫的強(qiáng)力底座。但要做成一個(gè)通用 KV 存儲(chǔ)，還需要很多工作要落實(shí)，包括可靠性、平臺(tái)能力、低成本方面的提升。慶幸業(yè)界已經(jīng)有很多優(yōu)秀的實(shí)踐，給我們提供很大的參考價(jià)值。

2. 持續(xù)完善平臺(tái)能力

最簡單的，參考 vivo 內(nèi)部以及各大互聯(lián)網(wǎng)公司 redis 平臺(tái)化管理實(shí)踐，新 KV 的平臺(tái)能力建設(shè)還有非常多的事情要做，而且后續(xù)還會(huì)跟智能化 DB 運(yùn)維結(jié)合在一起，想象空間更大。

3. 持續(xù)完善正確性校驗(yàn)機(jī)制

數(shù)據(jù)可靠性和正確性是一個(gè)數(shù)據(jù)庫產(chǎn)品的安身立命之本，需要持續(xù)完善相應(yīng)的校驗(yàn)機(jī)制。

現(xiàn)階段我們還沒法承諾金融級(jí)的數(shù)據(jù)可靠性，我們會(huì)持續(xù)往這個(gè)方向努力，目前滿足一些特征場景和緩存場景還是可行的。

我們已經(jīng)在逐漸引入一些開源的 chaos 工具，希望能持續(xù)深入挖掘出系統(tǒng)的潛在問題，為用戶提供更可靠的數(shù)據(jù)存儲(chǔ)服務(wù)。

4. 強(qiáng)化調(diào)度能力

分布式數(shù)據(jù)庫核心是圍繞存儲(chǔ)、計(jì)算、調(diào)度 3 個(gè)話題展開的，可見調(diào)度的重要性，負(fù)載均衡就是其中一個(gè)環(huán)節(jié)，目前 Hash-based 的分片規(guī)則，后續(xù)能否改成 Region-based 的分片規(guī)則？能否跟 k8s 結(jié)合構(gòu)建云原生的 KV 存儲(chǔ)產(chǎn)品？能否讓數(shù)據(jù)分布調(diào)整變得更智能、更自動(dòng)化 …… 我們拭目以待。

5. 冷熱數(shù)據(jù)分離

本質(zhì)還是成本和性能的權(quán)衡，對(duì)一些規(guī)模特別大的集群，可能 90% 的數(shù)據(jù)是很少被訪問的，這些數(shù)據(jù)哪怕存到閃存，也是一種資源的浪費(fèi)。一方面我們希望被頻繁訪問的數(shù)據(jù)能得到更好的讀寫性能，另一方面我們希望能最大限度的節(jié)省成本。

一個(gè)比較直接的方法，就是把熱數(shù)據(jù)存到內(nèi)存和閃存上，一些冰封的冷數(shù)據(jù)則存到一些更便宜的介質(zhì)（比如機(jī)械磁盤），這就需要系統(tǒng)自身具備判斷能力，能持續(xù)動(dòng)態(tài)區(qū)分出哪些屬于熱數(shù)據(jù)，哪些屬于冷數(shù)據(jù)。

6. 支持更多類型的存儲(chǔ)引擎

目前已經(jīng)支持了 Rocksdb 和 Titandb，后續(xù)會(huì)考慮引入更多類型的存儲(chǔ)引擎，比如純內(nèi)存的，或者基于 AEP 等新閃存硬件產(chǎn)品的存儲(chǔ)引擎。

7.支持遠(yuǎn)端 HDFS 冷備

對(duì)于在線場景，數(shù)據(jù)備份還是很重要的，當(dāng)前 Nebula 已經(jīng)支持本地集群級(jí)的快照備份，但機(jī)器掛了，還是會(huì)存在大量數(shù)據(jù)丟失的風(fēng)險(xiǎn)，我們會(huì)考慮把數(shù)據(jù)冷備到遠(yuǎn)端，比如 HDFS。是不是只要把 HDFS 掛載成本地目錄，集群把快照 dump 到指定目錄就可以了呢？我們會(huì)做進(jìn)一步的思考和設(shè)計(jì)。

8. SPDK 磁盤讀寫

實(shí)際測試告訴我們，同樣是依賴 nvme 磁盤，單機(jī)上使用 SPDK 比不使用 SPDK 吞吐提升接近 1 倍。SPDK 這種 Bypass Kernel 的方案已經(jīng)是大勢(shì)所趨，對(duì)磁盤 io 容易成為瓶頸的場景，使用 SPDK 能有效提升資源利用率。

9. KV SSD

鑒于 SPDK Bypass Kernel 的優(yōu)勢(shì)，業(yè)界提出了一種新的解決方案（KV SSD）。

Rocksdb 基于 LSM-tree 實(shí)現(xiàn)，Compaction 機(jī)制會(huì)帶來嚴(yán)重的寫放大，而 KV SSD 提供了原生的 KV接口，兼容 Rocksdb API，可以將新的數(shù)據(jù)記錄直接寫入到 SSD 中，不需要再進(jìn)行反復(fù)的 Compaction 操作，從而將 Rocksdb 的寫放大減小到 1，是一個(gè)非常值得嘗試的新技術(shù)。

10. 支撐圖數(shù)據(jù)庫

我們的 KV 產(chǎn)品之所以訂制 Nebula，其中一個(gè)重要原因是為圖數(shù)據(jù)庫做準(zhǔn)備的，目前已經(jīng)在嘗試接入一些有圖需求的業(yè)務(wù)，以后希望能跟開源社區(qū)合作，共建領(lǐng)先的圖數(shù)據(jù)庫能力。

11. 支撐時(shí)序數(shù)據(jù)庫

在 5G 和 物聯(lián)網(wǎng)時(shí)代，時(shí)序數(shù)據(jù)庫起著非常重要的作用。

這個(gè)領(lǐng)域 Influxdb 目前比較領(lǐng)先，但開源版本不支持分布式，只依賴一種為時(shí)序數(shù)據(jù)設(shè)計(jì)的單機(jī)存儲(chǔ)引擎（TSM），實(shí)用價(jià)值非常有限。

我們的 KV 產(chǎn)品提供了現(xiàn)成的分布式復(fù)制能力、標(biāo)準(zhǔn)化的平臺(tái)能力、高可用保障措施，我們希望能盡可能復(fù)用起來。

結(jié)合起來，是不是可以考慮把 TSM 跟分布式復(fù)制能力做一個(gè)整合，外加對(duì)時(shí)序場景友好的 Sharding 策略，構(gòu)建一個(gè)高可用的分布式時(shí)序存儲(chǔ)引擎，替換掉開源 InfluxDB 的單機(jī)存儲(chǔ)層。

12. 支撐對(duì)象存儲(chǔ)的元數(shù)據(jù)存儲(chǔ)

元數(shù)據(jù)存儲(chǔ)對(duì)“對(duì)象存儲(chǔ)”來說至關(guān)重要，既然我們已經(jīng)提供了一個(gè)強(qiáng)大的 KV 存儲(chǔ)產(chǎn)品，是不是可以復(fù)用起來，減輕運(yùn)維和研發(fā)維護(hù)的負(fù)擔(dān)呢？
編輯：hfy