UCloud對象存儲US3元數(shù)據(jù)改造（上）

一、前言

對象存儲是一種無層次結(jié)構(gòu)的數(shù)據(jù)存儲方法，通常在云中使用。與其他數(shù)據(jù)存儲方法不同，基于對象的存儲不使用目錄樹。離散的數(shù)據(jù)單元（對象）存在于存儲池中的同一級別。每個對象都有一個唯一的標(biāo)識名稱，客戶端使用其來檢索它。此外，每個對象都可能具有與其一起檢索的元數(shù)據(jù)。

2006年,美國Amazon公司發(fā)布AWS S3（Simple Storage Service）服務(wù),正式將對象存儲作為一項云存儲服務(wù),引入云計算領(lǐng)域。UCloud則在發(fā)展過程中,也自研了對象存儲服務(wù)US3,以滿足國內(nèi)外客戶的存儲需求。

二、US3元數(shù)據(jù)服務(wù)的挑戰(zhàn)

目前US3元數(shù)據(jù)服務(wù)支持了EB級存儲規(guī)模，存儲了超過千億級別的文件索引。需要面臨每日數(shù)十億次索引訪問,文件上傳請求,以及數(shù)億次文件刪除請求帶來的索引更新壓力,同時客戶大量的對象列表請求，也帶來了極大的索引范圍掃描挑戰(zhàn)。

在之前的元數(shù)據(jù)服務(wù)架構(gòu)中，UCloud采用了業(yè)內(nèi)流行的MongoDB作為底層數(shù)據(jù)存儲，同時輔以外部服務(wù)做數(shù)據(jù)路由、監(jiān)控統(tǒng)計，很好地滿足了客戶數(shù)據(jù)存儲需求。同時部署簡單，設(shè)計上也有一定的可擴展性。但隨著客戶數(shù)量以及存儲數(shù)據(jù)量的爆炸增長，此架構(gòu)也遇到了一定的問題。

三、此前的US3元數(shù)據(jù)服務(wù)架構(gòu)

US3元數(shù)據(jù)主要存儲在MongoDB集群內(nèi)，MongoDB集群則是鏈?zhǔn)浇Y(jié)構(gòu)，一個MongoDB集群由于寫入量太大扛不住了，就在后面增加一個MongoDB集群，查詢的時候接入集群將請求下發(fā)至DB-Gateway，DB-Gateway先將json數(shù)據(jù)轉(zhuǎn)譯成bson，然后根據(jù)Bucket對應(yīng)的DB（可能有多個），從新MongoDB至老MongoDB依次查詢數(shù)據(jù)。刪除的時候則需要將發(fā)送請求發(fā)送至所有bucket涉及的MongoDB集群。

一定會有小伙伴問為什么不直接擴mongo分片？

因為線上數(shù)據(jù)量大、服務(wù)壓力大、客戶需求高直接擴分片會有數(shù)據(jù)遷移，從而導(dǎo)致延遲，對線上服務(wù)的影響較大。

同時隨著MongoDB存儲的數(shù)據(jù)量越來越大，MongoDB的性能開始顯得不足。而原先直接在MongoDB進行列表掃描的方式會極大地影響其讀寫性能，為了緩解MongoDB的壓力，我們將列表服務(wù)分離出來，在外部同步MongoDB的數(shù)據(jù)，再對外提供服務(wù)。

列表服務(wù)對多個MongoDB進行同步，每加一個MongoDB集群就要加一個列表服務(wù)節(jié)點，查詢的時候也是根據(jù)bucket對應(yīng)的DB，同時發(fā)送至多個列表服務(wù)，然后再在接入層聚合。

由此我們總結(jié)了在元數(shù)據(jù)服務(wù)場景中，通常存在的一些痛點:

1、業(yè)務(wù)痛點：性能差

鏈?zhǔn)郊軜?gòu)，老MongoDB的寫能力用不上，讀會有放大。

刪除需要刪除多個MongoDB數(shù)據(jù)，可能存在數(shù)據(jù)不一致，孤兒文檔問題。

列表服務(wù)同步數(shù)據(jù)有延遲，客戶無法實時檢索上傳的文件。大量刪除導(dǎo)致列表服務(wù)同步延遲飆升。

2、運維痛點：可擴展性差

一個MongoDB頂不住就加一個MongoDB切，導(dǎo)致擴展同步繁瑣、手動切換出錯概率大。

3、運營痛點：成本高

由于性能不夠，需要更多的機器堆讀寫性能。列表服務(wù)由于分離出來，也需要額外的機器,導(dǎo)致元數(shù)據(jù)索引服務(wù)成本高昂。

四、新的US3元數(shù)據(jù)服務(wù)架構(gòu)

我們簡化了US3整個體系架構(gòu)，主要將其分為了高兼容性的DB-Gateway服務(wù)、高可用的計算存儲分離的分布式KV數(shù)據(jù)庫-UKV以及高度定制化的RocksDB-URocksDB三部分，將元數(shù)據(jù)存儲于UCloud自研的計算存儲分離的UKV中，因此獲得了更強大的容災(zāi)能力，更快的熱點節(jié)點分裂、性能拓展能力，還有底層存儲EC支持，異構(gòu)存儲等降低成本的潛力。

新架構(gòu)帶來了幾個方面的提升：

01 性能提升

元數(shù)據(jù)刪除延遲降低、讀放大降低。

02 列表服務(wù)無延遲

解決了客戶經(jīng)常因為列表服務(wù)延遲而不能實時看到上傳的數(shù)據(jù)的問題。（也不再有延遲告警問題）

03 成本降低

元數(shù)據(jù)服務(wù)成本降低80%。

04 運維更簡單

計算節(jié)點容災(zāi)無數(shù)據(jù)遷移，無需提心吊膽。熱點自動分裂，不再需要手動加節(jié)點擴容。

五、新架構(gòu)的幾個核心改變

有幾個關(guān)鍵產(chǎn)品（或環(huán)節(jié)）在這次優(yōu)化中起到重要作用：

1.DB-Gateway

DB-Gateway是一個無狀態(tài)進程,它兼容老的元數(shù)據(jù)服務(wù)，同時具有底層UKV協(xié)議轉(zhuǎn)換功能，Sharding路由功能，并且聚合了原先的列表服務(wù)功能，因此能夠移除列表服務(wù)需要的機器。

DB-Gateway通過ConfigServer集群更新UKV的Sharding路由表，來將不同的請求打到不同的UKV節(jié)點上去。

2.UKV

UKV是UCloud自研的計算存儲分離的分布式KV存儲系統(tǒng)。其存儲底座為分布式統(tǒng)一存儲Manul，Manul是具備自動數(shù)據(jù)平衡、異構(gòu)介質(zhì)存儲、EC存儲等功能的高性能、高可用、分布式存儲服務(wù)。

UKV提供了集群管理服務(wù)，快速備份等常規(guī)功能，還針對US3元數(shù)據(jù)服務(wù)設(shè)計了數(shù)據(jù)結(jié)構(gòu)，使其在UCloud日常的業(yè)務(wù)場景下提供更優(yōu)秀的性能。

UKV使用UCloud自研的、由開源RocksDB定制化的URocksDB作為計算節(jié)點，同時依托Manul，實現(xiàn)了主從熱備，熱點節(jié)點快速分裂等特色功能。