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

一、需求分析

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

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

（1）Value 大

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

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

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

（3）讀寫性能要求高，延時低

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

（4）不需要范圍查詢

大部分場景都是單點隨機讀寫。

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

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

（6）易用

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

2. 潛在需求

擴展為通用磁盤 KV，支撐各個場景的大容量存儲需求

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

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

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

可維護性強

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

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

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

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

二、方案選型

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

源自開源，按需定制。

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

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

可靠至上，高可維護。

先簡單介紹一下我們早期方案調(diào)研的一些優(yōu)缺點分析：

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

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

三、Nebula 簡介

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

1. 存儲計算分離

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

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

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

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

3. 可伸縮

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

4.易維護

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

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

四、Nebula Raft 簡介

上文提到 Nebula 是依賴 Raft 保證強一致的，這里簡單介紹一下 Nebula Raft 的特點：

1. 選主 與 任期

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

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

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

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

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

3. 成員變更

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

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

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

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

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

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

五、特征存儲平臺介紹

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

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

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

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

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

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

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

2. 性能優(yōu)化

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

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

（2）WiscKey

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

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

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

3. TTL 機制

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

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

4. 易用

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

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

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

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

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

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

（3）平臺化運維

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

5. 災(zāi)備

（1）定期冷備

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

（2）實時熱備

熱備落地一共分兩期：

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

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

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

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

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

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

6. 跨機房雙活

雙活也是分兩期落地：

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

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

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

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

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

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

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

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

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

六、未來展望

1. 擴展成通用 KV 存儲

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

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

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

3. 持續(xù)完善正確性校驗機制

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

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

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

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

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

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

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

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

6. 支持更多類型的存儲引擎

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

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

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

8. SPDK 磁盤讀寫

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

9. KV SSD

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

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

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

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

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

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

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

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

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

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

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