譯者 | 楊曉娟

審校 | 梁策 孫淑娟

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

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

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

理解元數據：無聲的數據引擎殺手

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

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

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

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

隨著這一趨勢的持續發展，數據引擎必須進行調整，以便能夠有效地支持現代企業的元數據處理和管理需求。

在數據引擎的蓋子之下

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

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

傳統的 KVS 是基于針對快速寫入速度或快速讀取速度而優化的數據結構。為了在內存中存儲元數據，數據引擎通常采用基于日志結構的合并樹 (LSM樹) 的 KVS?；?LSM 樹的 KVS 比 B 樹(KVS 中的另一種流行的數據結構)具有優勢，因為不可變 SST 文件的使用，它能夠非常快速地存儲數據而無需改變數據結構。盡管既有的 KVS 數據結構可以調整以獲得足夠好的寫入和讀取速度，但無法為這兩種操作一起提供高性能。

當你的數據引擎過熱時

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

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

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

一種新的數據架構

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

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

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

譯者介紹

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

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