譯者 | 布加迪

審校 | 孫淑娟

元數據過去對數據中心架構的影響很小。元數據是有關數據的數據，隱藏在某個地方以便檢索和分析，對業務運營幾乎沒什么影響。隨著大數據、人工智能、物聯網和5G等應用系統規模擴大，它們積累了眾多元數據，現在數據和元數據之間的傳統關系已被顛覆。

十年前，數據和元數據的典型比率是1000：1。比如說，大小為32K的數據單元（文件、塊或對象）將有大約32個字節的元數據。現有的數據引擎能夠非常有效地處理這些數量的數據。如今，對象很小時，這個比率通常更像是1：10。許多組織現在發現元數據超過了所存儲的數據量；隨著非結構化數據的數量持續猛增，情形只會變得更糟。

元數據激增的這種狀況引發了這些方面的問題：將元數據存儲在何處、如何有效管理，最重要的是如何擴展底層架構以支持快速增長的元數據量和快速擴展的系統。除非元數據擴展問題得到了充分解決，否則保存元數據的系統最終會遇到可能影響業務運營和性能的問題。

擴展元數據的四個解決之道

處理元數據時，無法有效地運用這種傳統做法：添加更多的計算資源及/或實施各種解決方案來監控和優化IT堆棧的不同層，從而解決可擴展性和性能問題。

組織通常使用RocksDB之類的鍵值存儲（KVS）系統來管理元數據，KVS系統依賴存儲引擎（又叫數據引擎），是對數據進行排序和索引的軟件堆棧的一部分。

然而現有的數據引擎存在容量有限、CPU利用率高和內存消耗大等先天不足，這些都是無法通過單單添加計算能力就能解決的。通常，一系列運營任務在此時開始，其中很少有有效的長期解決方案。

1. 分片——該過程將數據集拆分為邏輯片段，并同時運行多個數據集。這是處理高度可擴展系統生成的元數據的一種方法——至少在短期內如此。然而，隨著越來越多的數據流入系統，最初的分片方案常常出問題，在開發人員必須不斷重新分片的情況下開始暴露出來，本身成為一項活動。

2. 數據庫調優——即便使用靈活高效的NoSQL數據庫，開發人員也常常難以為遇到需要調優的性能問題的應用程序專門創建不尋常的配置。如果工作負載或底層系統發生變化，這些實例就會遇到額外的、更大的性能問題。隨著應用系統越來越龐大、越來越復雜，這可能會帶來看似無窮無盡的進一步重新調優的循環，結果耗費開發人員的時間。

3. 數據引擎調優——存儲管理的基本操作通常由數據引擎（即存儲引擎）執行。數據引擎作為應用程序和存儲層之間的軟件層加以安裝，這是一種嵌入式鍵值存儲（KVS），用于對數據進行排序和索引。此外，KVS日益作為應用程序內部的軟件層加以實施，以便在傳輸過程中對實時數據執行不同的動態活動。這種類型的部署常常旨在管理元數據密集型工作負載，并防止可能導致性能問題的元數據訪問瓶頸。

數據引擎是復雜的構件，組織常常發現在根據特定的性能和可擴展性要求，調整和配置應用程序底部的數據引擎方面存在技能方面的缺口。就連熟練的開發人員也難以克服這一點。

4. 添加資源——解決任何性能問題的傳統方法案都是添加額外的存儲資源以解決問題。這常常是一種權宜之計，成本無以為繼。

新的方法

當前的數據架構再也不能支持現代企業的需求，這促使企業需要從頭開始設計新數據引擎，以跟上元數據增長的步伐。但隨著開發人員開始深入數據引擎的底層，他們面臨這一挑戰：在不影響存儲性能、敏捷性和成本效益的情況下，實現更大的規模。這就需要一種新的架構來支持新一代數據引擎，該引擎可以有效地處理海量元數據，仍能確保應用程序可以快速訪問元數據。

下一代數據引擎可能是新興用例的關鍵賦能因素，這些用例的特點是數據密集型工作負載需要前所未有的規模和性能。比如說，實施適當的數據基礎設施來存儲和管理物聯網數據對于智慧城市項目的成功至關重要。該基礎設施必須有足夠的可擴展性，以便在不犧牲性能的情況下，處理來自交通管理、安全、智能照明、廢物管理及許多其他系統的不斷增多的元數據。這對響應時間和延遲高度敏感的應用程序而言尤為重要，比如交通優化和智能泊車。

元數據增長將繼續是數據中心面臨的問題，涉及越來越多的各種數據密集型用例。最近加大數據引擎創新力度的舉措為致力于使應用程序能夠擴展和增長的團隊提供了選擇。

原文標題：??How to Manage Metadata in a Highly Scalable System???，作者：Adi Gelvan