近年來(lái)，由于連接設(shè)備和物聯(lián)網(wǎng) (IoT) 不斷發(fā)展，數(shù)據(jù)量呈指數(shù)級(jí)增加。與此同時(shí)，用來(lái)描述和提供其他數(shù)據(jù)信息的元數(shù)據(jù)也增長(zhǎng)驚人。盡管元數(shù)據(jù)一直存在，但由于其規(guī)模只是如今的一小部分，因此曾一度被存儲(chǔ)于內(nèi)存及幕后。

編輯搜圖

十年前，數(shù)據(jù)和元數(shù)據(jù)之間的典型比率是1000:1。這意味著大小為32k的數(shù)據(jù)單元(文件、塊或?qū)ο?，其元數(shù)據(jù)大約為32字節(jié)。針對(duì)這種數(shù)量的數(shù)據(jù)，既有的數(shù)據(jù)引擎能夠非常高效地處理。然而，數(shù)據(jù)和元數(shù)據(jù)之間的比率已發(fā)生明顯變化，如今這個(gè)比率可以根據(jù)對(duì)象大小從1000:1到1:10之間浮動(dòng)。元數(shù)據(jù)的爆炸式增長(zhǎng)對(duì)我們的數(shù)據(jù)基礎(chǔ)設(shè)施產(chǎn)生了直接而顯著的影響。

隨著云應(yīng)用、云基礎(chǔ)設(shè)施服務(wù)、物聯(lián)網(wǎng)、大數(shù)據(jù)分析和其他數(shù)據(jù)密集型工作負(fù)載大規(guī)模采用，非結(jié)構(gòu)化數(shù)據(jù)量在未來(lái)幾年只會(huì)延續(xù)增長(zhǎng)趨勢(shì)，而當(dāng)前的數(shù)據(jù)架構(gòu)無(wú)法滿足現(xiàn)代企業(yè)的需求。為了應(yīng)對(duì)元數(shù)據(jù)不斷增長(zhǎng)的挑戰(zhàn)，我們需要新的架構(gòu)來(lái)支撐新一代的數(shù)據(jù)引擎，以有效地處理元數(shù)據(jù)的激增，同時(shí)讓?xiě)?yīng)用程序得以快速訪問(wèn)元數(shù)據(jù)。

理解元數(shù)據(jù)：無(wú)聲的數(shù)據(jù)引擎殺手

無(wú)論是 SQL 還是 NoSQL，每個(gè)數(shù)據(jù)庫(kù)系統(tǒng)都使用存儲(chǔ)引擎或稱數(shù)據(jù)引擎(無(wú)論嵌入與否)來(lái)管理數(shù)據(jù)的存儲(chǔ)方式。在日常生活中，我們不太關(guān)注這些讓世界運(yùn)轉(zhuǎn)的引擎，通常只在突然發(fā)生故障時(shí)才注意到它們。同樣，我們大多數(shù)人也是直到最近才聽(tīng)說(shuō)“數(shù)據(jù)引擎”這個(gè)術(shù)語(yǔ)。它們運(yùn)行我們的數(shù)據(jù)庫(kù)、存儲(chǔ)系統(tǒng)以及基本上任何處理大量數(shù)據(jù)的應(yīng)用程序。就像汽車引擎一樣，似乎只有當(dāng)它們發(fā)生故障時(shí)，我們才意識(shí)到它們的存在。畢竟，我們本來(lái)也不會(huì)期望轎車引擎能驅(qū)動(dòng)一輛大卡車，而它總有某個(gè)時(shí)刻會(huì)承受不住壓力而崩潰。

那是什么導(dǎo)致了數(shù)據(jù)引擎負(fù)擔(dān)加劇呢?主要原因是數(shù)據(jù)增長(zhǎng)速度過(guò)快。尤其是元數(shù)據(jù)，它簡(jiǎn)直是無(wú)聲的數(shù)據(jù)引擎殺手。元數(shù)據(jù)指有關(guān)數(shù)據(jù)的任何信息，例如讓查找和處理數(shù)據(jù)更容易的索引，這意味著元數(shù)據(jù)沒(méi)有預(yù)先固定的模式來(lái)適應(yīng)數(shù)據(jù)庫(kù)(通常是鍵值格式);相反，它是由各種系統(tǒng)和設(shè)備創(chuàng)建的一種一般性數(shù)據(jù)。這些需要存儲(chǔ)在某個(gè)地方并且通常隱藏放置在緩存 RAM 內(nèi)存中的數(shù)據(jù)，現(xiàn)在正變得越來(lái)越大。

除了像文檔和音/視頻文件等非結(jié)構(gòu)化數(shù)據(jù)量的不斷增加外，連接設(shè)備和物聯(lián)網(wǎng)傳感器的快速發(fā)展也造成了元數(shù)據(jù)數(shù)量的攀升，并且這一趨勢(shì)還將逐漸加快。數(shù)據(jù)通常本身很小(例如傳感器的字母數(shù)字讀取)，但卻伴隨著大量的元數(shù)據(jù)(位置、時(shí)間戳、描述)，而這些元數(shù)據(jù)甚至可能比數(shù)據(jù)本身還要大。

既有數(shù)據(jù)引擎所基于的架構(gòu)不能支持現(xiàn)代數(shù)據(jù)集的規(guī)模。為了跟上不斷增長(zhǎng)的數(shù)據(jù)量，它們已經(jīng)被逼到極限。這當(dāng)中包括基于 SQL的、鍵值存儲(chǔ)的、時(shí)間序列數(shù)據(jù)的，甚至是像MongoDB一樣非結(jié)構(gòu)化的數(shù)據(jù)引擎。它們都使用一個(gè)底層存儲(chǔ)引擎(無(wú)論嵌入與否)，而這個(gè)引擎構(gòu)建之初并非為了支持當(dāng)今的數(shù)據(jù)大小。由于元數(shù)據(jù)要大得多，并且暴露出內(nèi)存不足，那么訪問(wèn)底層介質(zhì)就會(huì)很慢并對(duì)性能造成沖擊。對(duì)應(yīng)用程序造成的性能影響直接取決于數(shù)據(jù)大小和對(duì)象數(shù)量。

隨著這一趨勢(shì)的持續(xù)發(fā)展，數(shù)據(jù)引擎必須進(jìn)行調(diào)整，以便能夠有效地支持現(xiàn)代企業(yè)的元數(shù)據(jù)處理和管理需求。

在數(shù)據(jù)引擎的蓋子之下

數(shù)據(jù)引擎作為軟件層安裝在應(yīng)用程序和存儲(chǔ)層之間，是一種嵌入式鍵值存儲(chǔ) (KVS)，以排序和索引數(shù)據(jù)。歷史上，數(shù)據(jù)引擎主要用于處理存儲(chǔ)管理的基本操作，尤其是創(chuàng)建、讀取、更新和刪除(CRUD)數(shù)據(jù)。

如今，KVS 越來(lái)越多地被實(shí)現(xiàn)為應(yīng)用程序內(nèi)的軟件層，以便在傳輸過(guò)程中對(duì)實(shí)時(shí)數(shù)據(jù)執(zhí)行各種即時(shí)活動(dòng)。雖然RocksDB等既有的數(shù)據(jù)引擎正被用于處理 CRUD 之外的應(yīng)用程序內(nèi)操作，但它們依然被設(shè)計(jì)所限。這種部署類型通常旨在管理元數(shù)據(jù)密集型工作負(fù)載，并防止可能導(dǎo)致性能問(wèn)題的元數(shù)據(jù)訪問(wèn)瓶頸。由于 KVS 正在超越其作為存儲(chǔ)引擎的傳統(tǒng)角色，因此術(shù)語(yǔ)“數(shù)據(jù)引擎”被用于描述更廣泛的用例。

傳統(tǒng)的 KVS 是基于針對(duì)快速寫(xiě)入速度或快速讀取速度而優(yōu)化的數(shù)據(jù)結(jié)構(gòu)。為了在內(nèi)存中存儲(chǔ)元數(shù)據(jù)，數(shù)據(jù)引擎通常采用基于日志結(jié)構(gòu)的合并樹(shù) (LSM樹(shù)) 的 KVS?；?LSM 樹(shù)的 KVS 比 B 樹(shù)(KVS 中的另一種流行的數(shù)據(jù)結(jié)構(gòu))具有優(yōu)勢(shì)，因?yàn)椴豢勺?SST 文件的使用，它能夠非常快速地存儲(chǔ)數(shù)據(jù)而無(wú)需改變數(shù)據(jù)結(jié)構(gòu)。盡管既有的 KVS 數(shù)據(jù)結(jié)構(gòu)可以調(diào)整以獲得足夠好的寫(xiě)入和讀取速度，但無(wú)法為這兩種操作一起提供高性能。

當(dāng)你的數(shù)據(jù)引擎過(guò)熱時(shí)

隨著數(shù)據(jù)引擎越來(lái)越多地被用于處理和映射數(shù)萬(wàn)億個(gè)對(duì)象，傳統(tǒng) KVS 的局限性變得顯而易見(jiàn)。盡管提供了比傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)更高的靈活性和速度，但由于高寫(xiě)入放大，基于 LSM 的 KVS 容量有限以及高CPU 利用率和內(nèi)存消耗，這會(huì)影響其固態(tài)存儲(chǔ)介質(zhì)的性能。開(kāi)發(fā)人員必須在寫(xiě)入性能和讀取性能之間進(jìn)行權(quán)衡。然而，配置 KVS 以滿足這些要求不僅是一項(xiàng)長(zhǎng)期任務(wù)，而且由于其復(fù)雜的內(nèi)部結(jié)構(gòu)，也將是一項(xiàng)具有挑戰(zhàn)性和勞動(dòng)密集型的任務(wù)。

為了維持運(yùn)行，應(yīng)用程序開(kāi)發(fā)人員將發(fā)現(xiàn)自己要花費(fèi)越來(lái)越多的時(shí)間處理分片、數(shù)據(jù)庫(kù)調(diào)優(yōu)和其他耗時(shí)的操作任務(wù)。這些局限將迫使許多缺乏開(kāi)發(fā)人員資源的組織使用無(wú)法滿足數(shù)據(jù)引擎需求的默認(rèn)設(shè)置。

顯然，這種方法不可能長(zhǎng)期持續(xù)。由于既有 KVS 產(chǎn)品的固有缺陷，當(dāng)前可用的數(shù)據(jù)引擎難以在保持足夠性能的同時(shí)進(jìn)行擴(kuò)展，更不用說(shuō)以具有成本效益的方式進(jìn)行擴(kuò)展了。

一種新的數(shù)據(jù)架構(gòu)

認(rèn)識(shí)到元數(shù)據(jù)產(chǎn)生的問(wèn)題以及當(dāng)前數(shù)據(jù)引擎的局限，促使我們創(chuàng)建了 Speedb，該數(shù)據(jù)引擎可在規(guī)模上提供更快性能。我和合伙人認(rèn)識(shí)到當(dāng)前數(shù)據(jù)架構(gòu)的局限性，并決定從頭開(kāi)始構(gòu)建一個(gè)新的數(shù)據(jù)引擎來(lái)應(yīng)對(duì)元數(shù)據(jù)激增，以避免在可擴(kuò)展性、性能和成本之間權(quán)衡，同時(shí)提供卓越的讀寫(xiě)速度。

為此，我們重新設(shè)計(jì)了KVS的基本組件。我們開(kāi)發(fā)了一種新的壓縮方法，可顯著減少大規(guī)模 LSM 的寫(xiě)入放大;一種新的流控制機(jī)制，以消除用戶延遲的峰值;以及一個(gè)概率索引，無(wú)論對(duì)象和密鑰大小如何，每個(gè)對(duì)象最多消耗3個(gè)字節(jié)，在規(guī)模上提供極高性能。

Speedb是一款與 RocksDB 存儲(chǔ)引擎兼容的嵌入式解決方案，可以滿足云規(guī)模下不斷增長(zhǎng)的高性能需求。元數(shù)據(jù)的增長(zhǎng)并沒(méi)有放緩，但有了這種新架構(gòu)，我們至少能夠跟上需求的腳步。

譯者介紹

楊曉娟，51CTO社區(qū)編輯，西安電子科技大學(xué)計(jì)算機(jī)專業(yè)碩士研究生，資深研發(fā)工程師，信息系統(tǒng)項(xiàng)目管理師，擁有近20年Java開(kāi)發(fā)經(jīng)驗(yàn)。分別在NEC、甲骨文、英方從事數(shù)據(jù)存儲(chǔ)、Oracle數(shù)據(jù)庫(kù)的數(shù)據(jù)遷移以及同構(gòu)/異構(gòu)數(shù)據(jù)庫(kù)復(fù)制等研發(fā)工作，尤其在數(shù)據(jù)庫(kù)、數(shù)據(jù)編碼等方面有深入鉆研和了解。