本文來自開源云中文社區(qū)。
元數(shù)據(jù)過去對(duì)數(shù)據(jù)中心架構(gòu)的影響很小。元數(shù)據(jù)是關(guān)于數(shù)據(jù)的數(shù)據(jù)，這些數(shù)據(jù)被隱藏在某個(gè)地方進(jìn)行檢索和分析，對(duì)操作幾乎沒有影響。隨著大數(shù)據(jù)、人工智能、物聯(lián)網(wǎng)和5G應(yīng)用程序的擴(kuò)展，積累了大量元數(shù)據(jù)，數(shù)據(jù)和元數(shù)據(jù)之間的傳統(tǒng)關(guān)系已經(jīng)被顛覆。
十年前，數(shù)據(jù)和元數(shù)據(jù)之間的典型比率是1000:1。例如，大小為32K的數(shù)據(jù)單元（文件、塊或?qū)ο螅┑脑獢?shù)據(jù)大約為32字節(jié)?，F(xiàn)有的數(shù)據(jù)引擎能夠非常有效地處理這些數(shù)據(jù)量。今天，當(dāng)對(duì)象很小時(shí)，比率通常更接近1:10。許多組織現(xiàn)在發(fā)現(xiàn)，他們的元數(shù)據(jù)超過了存儲(chǔ)的數(shù)據(jù)量，而且隨著非結(jié)構(gòu)化數(shù)據(jù)量的持續(xù)爆炸，情況只會(huì)變得更糟。
元數(shù)據(jù)的激增引發(fā)了以下問題：在何處存儲(chǔ)元數(shù)據(jù)，如何有效管理元數(shù)據(jù)，最重要的是，如何擴(kuò)展底層架構(gòu)以支持快速增長(zhǎng)的元數(shù)據(jù)量以及快速擴(kuò)展的系統(tǒng)。除非元數(shù)據(jù)擴(kuò)展問題得到充分解決，否則保存元數(shù)據(jù)的系統(tǒng)最終將遇到可能影響業(yè)務(wù)運(yùn)營(yíng)和性能的問題。
縮放元數(shù)據(jù)的四個(gè)答案
在處理元數(shù)據(jù)時(shí)，無(wú)法有效地應(yīng)用通過添加更多計(jì)算資源和/或?qū)嵤└鞣N解決方案來監(jiān)控和優(yōu)化IT堆棧不同層來解決可伸縮性和性能問題的傳統(tǒng)方法。
組織通常使用鍵值存儲(chǔ)（KVS）來管理元數(shù)據(jù)，如RocksDB，它依賴于存儲(chǔ)引擎（也稱為數(shù)據(jù)引擎），數(shù)據(jù)引擎是軟件堆棧中對(duì)數(shù)據(jù)進(jìn)行排序和索引的部分。
然而，現(xiàn)有的數(shù)據(jù)引擎存在著容量有限、CPU利用率高和內(nèi)存消耗大等固有的缺點(diǎn)，這無(wú)法通過簡(jiǎn)單地增加計(jì)算能力來解決。通常，一系列操作任務(wù)從這一點(diǎn)開始，其中很少有提出有效的長(zhǎng)期解決方案。
切分——此過程將數(shù)據(jù)集拆分為邏輯塊，并同時(shí)運(yùn)行多個(gè)數(shù)據(jù)集。這是處理高度可伸縮系統(tǒng)生成的元數(shù)據(jù)的一種方法（至少在短期內(nèi)是這樣）。然而，隨著流入系統(tǒng)的數(shù)據(jù)量的不斷增加，最初的分片計(jì)劃經(jīng)常會(huì)中斷，開發(fā)人員必須不斷地重新分片，從而成為自己的一項(xiàng)活動(dòng)。
數(shù)據(jù)庫(kù)優(yōu)化——即使使用靈活高效的NoSQL數(shù)據(jù)庫(kù)，開發(fā)人員也常常難以為遇到需要優(yōu)化的性能問題的應(yīng)用程序創(chuàng)建特殊的配置。然而，如果工作負(fù)載或底層系統(tǒng)發(fā)生變化，這些實(shí)例就會(huì)遇到更多更大的性能問題。隨著應(yīng)用程序的規(guī)模和復(fù)雜性的增長(zhǎng)，這可能會(huì)建立一個(gè)似乎無(wú)休止的進(jìn)一步重新調(diào)整循環(huán)，從而消耗開發(fā)人員的時(shí)間。
數(shù)據(jù)引擎優(yōu)化——存儲(chǔ)管理的基本操作通常由數(shù)據(jù)引擎（又名存儲(chǔ)引擎）執(zhí)行。數(shù)據(jù)引擎作為應(yīng)用程序?qū)雍痛鎯?chǔ)層之間的軟件層安裝，是一個(gè)嵌入式鍵值存儲(chǔ)（KVS），用于對(duì)數(shù)據(jù)進(jìn)行排序和索引。此外，KVS越來越多地被實(shí)現(xiàn)為應(yīng)用程序中的軟件層，以便在傳輸過程中對(duì)實(shí)時(shí)數(shù)據(jù)執(zhí)行不同的動(dòng)態(tài)活動(dòng)。這種類型的部署通常旨在管理元數(shù)據(jù)密集型工作負(fù)載，并防止可能導(dǎo)致性能問題的元數(shù)據(jù)訪問瓶頸。
數(shù)據(jù)引擎是一種復(fù)雜的結(jié)構(gòu)，組織通常會(huì)發(fā)現(xiàn)，在根據(jù)特定的性能和可伸縮性要求在應(yīng)用程序的引擎罩下調(diào)整和配置數(shù)據(jù)引擎時(shí)，存在技能差距。即使是熟練的開發(fā)人員也可能難以實(shí)現(xiàn)這一點(diǎn)。
添加資源——解決任何性能問題的由來已久的答案就是為問題投入額外的存儲(chǔ)資源。這通常被證明是一個(gè)暫時(shí)的解決方案，其成本無(wú)法長(zhǎng)期維持。
新選項(xiàng)
意識(shí)到當(dāng)前的數(shù)據(jù)架構(gòu)不再能夠支持現(xiàn)代企業(yè)的需求，這促使人們需要從頭開始設(shè)計(jì)新的數(shù)據(jù)引擎，以跟上元數(shù)據(jù)的增長(zhǎng)。但是，隨著開發(fā)人員開始深入研究數(shù)據(jù)引擎，他們面臨的挑戰(zhàn)是實(shí)現(xiàn)更大的規(guī)模，同時(shí)又不會(huì)影響存儲(chǔ)性能、靈活性和成本效益。這就需要一種新的架構(gòu)來支撐新一代的數(shù)據(jù)引擎，該引擎可以有效地處理元數(shù)據(jù)海嘯，同時(shí)確保應(yīng)用程序能夠快速訪問元數(shù)據(jù)。
新一代數(shù)據(jù)引擎可能是以數(shù)據(jù)密集型工作負(fù)載為特征的新興用例的關(guān)鍵推動(dòng)者，這些數(shù)據(jù)密集型工作負(fù)載需要前所未有的規(guī)模和性能。例如，實(shí)施適當(dāng)?shù)臄?shù)據(jù)基礎(chǔ)設(shè)施來存儲(chǔ)和管理物聯(lián)網(wǎng)數(shù)據(jù)對(duì)于智能城市計(jì)劃的成功至關(guān)重要。此基礎(chǔ)設(shè)施必須具有足夠的可擴(kuò)展性，以在不犧牲性能的情況下處理來自交通管理、安全、智能照明、廢物管理和許多其他系統(tǒng)的不斷增加的元數(shù)據(jù)。這對(duì)于對(duì)響應(yīng)時(shí)間和延遲高度敏感的應(yīng)用程序尤其重要，例如交通優(yōu)化和智能停車。
元數(shù)據(jù)增長(zhǎng)將繼續(xù)加速，成為數(shù)據(jù)中心關(guān)注的問題，它跨越了越來越多的數(shù)據(jù)密集型用例。最近開放數(shù)據(jù)引擎進(jìn)行創(chuàng)新的舉措為專注于使應(yīng)用程序能夠擴(kuò)展和增長(zhǎng)的團(tuán)隊(duì)提供了選擇。
原文鏈接：
https://thenewstack.io/how-to-manage-metadata-in-a-highly-scalable-system/
