譯者 | 楊曉娟

審校 | 梁策 孫淑娟

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

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

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

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

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

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

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

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

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

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

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

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

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

當你的數(shù)據(jù)引擎過熱時

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

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

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

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

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

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

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

譯者介紹

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

原文標題：??Metadata, not data, is what drags your database down??，作者：Adi Gelvan