數據是今天的基礎! 它支持從你最喜歡的貓咪視頻到每天發生的數十億金融交易的一切。這一切的核心是分佈式數據存儲。
在這篇文章中，我們將學習什麼是分佈式數據存儲，為什麼我們需要它，以及如何有效地使用它。本文旨在幫助你開發應用程序，因此我們將只涉及應用程序開發人員需要知道的內容。這包括必要的基礎，開發人員遇到的常見陷阱，以及不同的分佈式數據存儲之間的區別。
這篇文章不需要任何分佈式系統知識! 編程和數據庫經驗會有幫助，但你也可以在我們遇到問題時直接查找主題。讓我們開始吧!
一、什麼是分佈式數據存儲？
分佈式數據存儲是一個在多台機器上存儲和處理數據的系統。
作為一個開發者，你可以把分佈式數據存儲看作是你存儲和檢索應用程序數據、指標、日誌等的方式。你可能熟悉的一些流行的分佈式數據存儲是MongoDB，亞馬遜網絡服務（AWS）的S3，以及谷歌云平台的Spanner。
在實踐中，有許多種分佈式數據存儲。它們通常是由雲提供商管理的服務或你自己部署的產品。你也可以從頭開始或在其他數據存儲的基礎上建立你自己的數據存儲。
二、我們為什麼需要它？
為什麼不直接使用單機數據存儲？為了真正理解，我們首先需要認識到今天數據的規模和普遍性。讓我們看看一些具體的數字。
– 2018年，Steam的最高並髮用戶數為1850萬，部署了擁有2.7PB固態硬盤的服務器，並向用戶提供了15艾字節的數據¹。
– 納斯達克在2020年單日攝取了1130億條記錄的峰值，比兩年前的平均300億條有所擴大²。
– 穀物公司凱洛格（Kellogg’s）在2014年每週僅模擬促銷活動就處理了16TB的數據³。
說實話，我們使用的數據之多令人難以置信。這些字節中的每一個都被仔細地儲存和處理在某個地方。這個地方就是我們的分佈式數據存儲。
單機數據存儲根本無法支持這些需求。因此，我們使用分佈式數據存儲，在性能、可擴展性和可靠性方面具有關鍵優勢。讓我們了解一下這些優勢在實踐中的真正含義。
性能、可擴展性和可靠性
性能是指一台機器能多好地完成工作。
性能是至關重要的。有無數的研究量化並顯示了短至100毫秒的延遲對業務的影響。緩慢的響應時間不僅使人們感到沮喪–它們使流量、銷售和最終收入下降。
幸運的是，我們確實可以控制我們應用程序的性能。在單機數據存儲的情況下，簡單地升級到一個更快的機器往往就足夠了。如果這還不夠，或者你依賴於一個分佈式數據存儲，那麼其他形式的可擴展性就會發揮作用。
可擴展性是指增加或減少基礎設施資源的能力。
今天的應用程序經常經歷快速增長和周期性的使用模式。為了滿足這些負載要求，我們’擴展’我們的分佈式數據存儲。這意味著，我們根據需要提供更多或更少的資源。可擴展性有兩種形式。
– 橫向擴展意味著添加或刪除計算機（也稱為機器或節點）。
– 垂直擴展意味著改變機器的CPU、RAM、存儲容量或其他硬件。
橫向擴展是分佈式數據存儲能夠勝過單機數據存儲的原因。通過將工作分散到數百台計算機上，總體系統具有更高的性能和可靠性。雖然分佈式數據存儲主要依靠水平擴展，但垂直擴展也被結合使用，以優化整體性能和成本⁶。
縮放存在於從手動到完全管理的範圍內。有些產品具有手動擴展功能，您可以自行配置額外的容量。其他產品則根據剩餘存儲容量等指標進行自動縮放。最後，有些服務會處理所有的擴展，而開發者甚至不需要考慮這個問題，例如亞馬遜網絡服務（AWS）的S3。
不管是哪種方法，所有的服務都有一些不能增加的限制，比如最大對象的大小。你可以檢查文檔中的配額，看看這些硬性限制。你可以檢查網上的基準，看看在實踐中可以達到什麼性能。
可靠性是指無故障的概率⁷。
有些應用對我們的生活非常關鍵，甚至幾秒鐘的故障都是不可接受的。這些應用不能使用單機數據存儲，因為不可避免的硬件和網絡故障會影響整個服務。相反，我們使用分佈式數據存儲，因為它們可以適應單個計算機或網絡路徑的故障。
要做到高度可靠，一個系統必須同時具有可用性和容錯性。
– 可用性是指一個服務可以到達並正常響應請求的時間百分比。
– 容錯性是指容忍硬件和軟件故障的能力。完全容錯是不可能的¹⁰。
儘管可用性和容錯性一開始可能看起來很相似，但它們實際上是完全不同的。讓我們看看如果你有一個但沒有另一個會發生什麼。
– 可用但不容錯。考慮一個每分鐘都發生故障但在幾毫秒內恢復的系統。用戶可以訪問服務，但長期運行的工作卻沒有足夠的時間來完成。
– 容錯但不可用。考慮一個系統，其中一半的節點永遠在重新啟動，而其他的節點是穩定的。如果穩定節點的容量不足，那麼一些請求將不得不被拒絕。
經驗之談
對於應用程序開發人員來說，關鍵的一點是，分佈式數據存儲的性能和可靠性可以遠遠超過單機。問題是，它們在工作方式上有一些注意事項，會限制它們的潛力。
三、它是如何工作的？
讓我們來介紹一下應用程序開發人員需要知道的分佈式數據存儲的工作原理–分區、查詢路由和復制。這些基礎知識將使你深入了解分佈式數據存儲的行為和特點。它將幫助你了解注意事項，權衡利弊，以及為什麼我們沒有一個分佈式數據存儲在所有方面都很出色。
分區
我們的數據集往往太大，無法存儲在一台機器上。為了克服這個問題，我們將數據劃分為較小的子集，讓各個機器可以存儲和處理。有許多方法可以對數據進行分區，每一種方法都有其自身的優劣勢。兩個主要的方法是垂直和水平分區。
垂直分割是指按相關字段分割數據¹¹。字段可以因為許多原因而相關。它們可能是一些共同對象的屬性。它們可能是經常一起被查詢的字段。它們甚至可能是以類似的頻率或由具有類似權限的用戶訪問的字段。你在機器上垂直劃分數據的確切方式最終取決於你的數據存儲的屬性和你要優化的使用模式。
水平分區（也被稱為分片）是指我們將數據分割成具有相同模式的子集¹¹。例如，我們可以通過將行分組到分片中來對一個關係數據庫表進行水平分區，以便存儲在不同的機器上。當一台機器無法處理數據量或數據的查詢負載時，我們就會將數據分片。分片策略分為兩類：算法型和動態型，但也存在混合型¹⁰。
算法分片是根據數據的鍵值的函數來確定將數據分配到哪個分片。例如，在存儲將URL映射到HTML的鍵值數據時，我們可以通過根據URL的第一個字母分割鍵值來對數據進行範圍分割。例如，所有以’A ‘開頭的URL將被放在第一台機器上，’B ‘被放在第二台機器上，以此類推。有無數的策略，都有不同的權衡。
動態分片明確地選擇了數據的位置，並將該位置存儲在一個查詢表中。要訪問數據，我們要諮詢有查詢表的服務或檢查本地緩存。查詢表可能相當大，因此它們可能有指向子查詢表的查詢表，如B+樹¹²。動態分片比算法分片更靈活¹³。
分片，在實踐中是相當棘手的，會產生許多你需要注意的問題。幸運的是，一些分佈式數據存儲將為你處理所有這些複雜性。其他的則處理一些或不處理。
– 分片可能有不均勻的數據大小。這在算法分片中很常見，在這種情況下，功能很難正確。我們通過圍繞數據定制分片策略來緩解這種情況。
– 分片可能有熱點，某些數據的查詢頻率比其他數據高。例如，考慮在社交網絡中查詢名人比查詢普通人要頻繁得多。精細的模式設計、緩存和復制可以在這方面有所幫助。
– 在保持高可用性的情況下，重新分配數據以處理從系統中添加或刪除節點是很困難的。
– 索引可能也需要被分割開來。索引可以為它所存儲的碎片建立索引（本地索引），也可以為整個數據集建立索引並進行分區（全局索引）。每種方法都有其利弊。
– 跨分區的交易可能工作，也可能被禁用，因為它們速度慢，或以混亂的方式不一致。當你從單機數據存儲中建立自己的分佈式數據存儲時，這尤其困難。
查詢路由
劃分數據只是故事的一部分。我們仍然需要將查詢從客戶端路由到正確的後端機器。查詢路由可以發生在軟件棧的不同層次。讓我們看看這三種基本情況。
– 客戶端分區是指客戶持有要查詢哪個後端節點的決策邏輯。其優點是概念簡單，缺點是每個客戶端必須實現查詢路由邏輯。
– 基於代理的分區是指客戶端將所有的查詢發送給一個代理。然後這個代理決定查詢哪個後端節點。這可以幫助減少後端服務器上的並發連接數，並將應用邏輯與路由邏輯分開。
– 基於服務器的分區是指當客戶端連接到任何後端節點時，該節點將處理、重定向或轉發該請求。
在實踐中，查詢路由是由大多數分佈式數據存儲處理的。通常情況下，你配置一個客戶端，然後使用客戶端進行查詢。然而，如果你正在建立你自己的分佈式數據存儲，或使用像Redis這樣的產品不處理它，你將需要考慮到這一點¹⁴。
複製
我們要討論的最後一個概念是複制。複製意味著存儲同一數據的多個副本。這有很多好處。
– 數據冗餘。當硬件不可避免地發生故障時，數據不會丟失，因為有另一個副本。
– 數據可訪問性。客戶可以從任何副本訪問數據。這增加了對數據中心故障和網絡分區的恢復力。
– 增加閱讀量。有更多的機器可以為數據提供服務，因此整體容量更高。
– 減少了網絡延遲。客戶端可以訪問離他們最近的副本，減少了網絡延時。
實施複制需要令人費解的共識協議和對失敗情況的bug進行分析。幸運的是，應用程序開發人員通常只需要知道數據複製的地點和時間。
數據複製的地點從數據中心內到跨區、跨地區、甚至跨大陸不等。通過近距離複製數據，我們可以最大限度地減少機器之間更新數據時的網絡延遲。然而，通過進一步複製數據，我們可以防止數據中心故障、網絡分區，並有可能減少讀取的網絡延遲。當數據被複製時，可以是同步的或異步的。
– 同步複製是指在響應請求之前將數據複製到所有的副本。這樣做的好處是確保各複製體的數據相同，但代價是寫入延遲較高。
– 異步複製意味著在響應請求之前，數據只存儲在一個副本上。這樣做的好處是寫入速度快，缺點是數據一致性較差，可能會出現數據丟失。
經驗之談
分區、查詢路由和復制是分佈式數據存儲的構建模塊。不同的實現方式會出現不同的功能和屬性，你要在它們之間進行權衡。
四、這些差異是什麼？
分佈式數據存儲都是特殊的雪花，每一個都有其獨特的功能集。我們將通過把它們的差異歸為一類並涵蓋每一類的基礎知識來比較它們。這將有助於你知道要問什麼問題，以及在未來要進一步閱讀什麼。
數據模型
要考慮的第一個差異是數據模型。數據模型是數據的類型以及你如何查詢它。常見的類型包括：
– 文檔。 JSON文檔的嵌套集合。用鍵或過濾器進行查詢。
– 鍵-值。鍵值對。用一個鍵進行查詢。
– 關係型。具有明確模式的行的表。用SQL查詢。
– 二進制對象。任意二進制大型物件。用一個鍵進行查詢。
– 文件系統。文件的目錄。用文件路徑查詢。
– 圖形。帶有邊的節點。用圖查詢語言進行查詢。
– 信息。一組鍵值對，像JSON或Python的字典。從隊列、主題或發件人查詢。
– 時間序列（Time-series）。按時間戳排序的數據。用SQL或其他查詢語言進行查詢。
– 文本。自由格式的文本或日誌。用查詢語言進行查詢。
不同的數據模型是針對不同的情況。雖然你可以把所有東西都存儲為二進制對象，但在查詢數據和開發應用程序時，這將是不方便的。相反，使用最適合你的查詢類型的數據模型。例如，如果你需要快速、簡單地查詢小塊數據，就使用鍵值對。我們將在下方列舉更多關於預期用途的細節。
請注意，有些數據存儲是多模型的，這意味著它們可以有效地操作多種數據模型。
擔保
不同的數據存儲提供不同的行為’保證’。雖然從技術上講，你不需要保證來開發健壯的應用程序，但強大的保證可以極大地簡化設計和實施。你會遇到的常見保證有以下幾種。
– 一致性是指數據對所有讀者來說都是一樣的，並且是最新的。請注意，’一致性’這個詞具有諷刺意味，它嚴重超載–要確定所指的是哪種類型的一致性¹⁵。
– 可用性是指你是否可以訪問你的數據。
– 持久性是指存儲的數據是否保持安全和不被破壞。
一些服務供應商甚至會通過服務水平協議（SLA）以合同形式保證服務水平，如99.99%的可用性。在他們未能堅持協議的情況下，你通常會得到一些補償。
生態系統
生態系統（集成、工具、支持軟件等）對您在分佈式數據存儲方面的成功至關重要。需要檢查一些簡單的問題，比如有哪些SDK可用，支持哪些類型的測試。如果你需要像數據庫連接器、移動同步、ORM、協議緩衝區、地理空間庫等功能，你需要確認它們是否被支持。文檔和博客會有這些信息。
安全問題
安全責任是由你和你的產品/服務提供商共同承擔的。你的責任將與你管理的堆棧的程度相關。
如果你使用分佈式數據存儲作為一種服務，你可能只需要配置一些身份和訪問策略、審計和應用安全。然而，如果你建立和部署它，你將需要處理一切，包括基礎設施安全、網絡安全、休息/傳輸中的加密、密鑰管理、補丁等。檢查你的數據存儲的’共同責任模式’，以弄清這一點。
合規性
合規性可以是一個關鍵的差異化因素。許多應用程序需要遵守關於如何處理數據的法律和法規。如果你需要遵守安全政策，如FEDRAMP、PCI-DSS、HIPAA或任何其他政策，你的分佈式數據存儲也需要遵守。
此外，如果你已經向客戶做出了關於數據保留、數據駐留或數據隔離的承諾，你可能希望分佈式數據存儲具有這方面的內置功能。
價格
不同的數據存儲的價格是不同的。有些數據存儲只根據存儲量收費，而其他的則考慮到服務器和許可證費用。文檔中通常會有一個定價計算器，你可以用它來估算賬單。請注意，雖然有些數據存儲起初看起來成本較高，但它們很可能在工程和操作時間的節省上得到補償。
經驗之談
分佈式數據存儲都是獨一無二的。我們可以通過文檔、博客、基準、定價計算器，或者通過與專業支持人員交談和建立原型來了解和比較它們的不同特點。
五、有哪些選擇呢？
我們現在對抽象的分佈式數據存儲有了很大的了解。讓我們把它聯繫起來，看看真正的工具吧。
似乎有無限的選擇，不幸的是，沒有最好的選擇。每個分佈式數據存儲都是為了不同的目的，需要適合你的特定使用情況。為了了解不同的類型，請查看下表。花點時間，專注於一般的類型和用例。
最後，請注意，真實的應用程序和公司有各種各樣的工作要做，因此它們依賴於多個分佈式數據存儲。這些系統一起工作，為終端用戶以及開發人員和分析師服務。
六、結束
數據將繼續存在，而分佈式數據存儲正是實現這一目標的手段。
在這篇文章中，我們了解到，分佈式數據存儲的性能和可靠性可以遠遠超過單機數據存儲的規模。分佈式數據存儲依靠具有許多機器的架構來劃分和復制數據。應用程序開發人員不需要知道所有的具體細節–他們只需要知道足夠多的知識以了解實踐中出現的問題，如數據熱點、交易支持、數據複製的價格等等。
像其他東西一樣，分佈式數據存儲也有大量的功能。一開始，你可能很難將其概念化，但希望我們的分解能幫助你確定思考過程的方向，並指導你今後的學習。
文章來源：https://towardsdatascience.com
原文作者：Quentin Truong
原文鏈接：https://towardsdatascience.com/introduction-to-distributed-data-storage-2ee03e02a11d
