PostgreSQL Replication之第一章 理解複製概念（3）

標籤：

1.3 使用分區和資料分配

本節您將瞭解基本可擴充性技術，例如資料庫分區。分區被廣泛應用於高端系統並提供一個簡單而且可靠的擴充設定方式來向外擴充。近年來，分區已經成為一種擴大專業系統規模的標準方式。

1.3.1 理解分區的目的

如果您的資料量增長超過一台機器的處理能力將會發生什麼事情？如果您要運行這麼多的事務，一台伺服器根本跟不上怎麼辦？我們假設您有百萬級的使用者，上萬使用者想在同一時間執行特定的任務。

顯然，某些時候，您再也不能通過購買能夠處理無限大的負載的足夠大的伺服器來解決問題。顯然在單個伺服器上運行一個類似Facebook或類似Google的應用是不可能的。有些時候，您必須拿出一個可伸縮策略來服務於您的需求。這就是分區應用的情境。

分區的想法很簡單：要是您能在某種程度上分裂的資料可以駐留在不同的節點上會怎樣？

設計一個分區系統的例子

為了表明分區的基本概念，我們假設一下情形：

我們要儲存數百萬使用者的資訊。每個使用者都有一個唯一的使用者ID。我們進一步假設，我們只有兩台伺服器。在這種情況下，我們可以儲存偶數使用者的ID到伺服器1上，奇數使用者的ID儲存到伺服器2上。

表明這是怎麼實現的：

正如您所看到的，在我們的圖中，我們已經很好地分發資料。一旦資料分發完成，我們就可以如下向系統發送一個查詢：

SELECT * FROM t_user WHERE id = 4;

用戶端可以很容易地計算出在哪裡可以通過我們的查詢檢查過濾器找到資料。在我們的例子中，該查詢將被發送到第一個節點，因為我們正在處理一個偶數。

正如我們已經基於一個鍵(key)(這裡使用的是使用者ID)所分布的資料，如果我們知道鍵(key)的話，我們可以很容易地搜尋到任何人。在大型系統中，通過一個一個鍵(key)參考使用者是常見的做法，因此這種方法是合適的。通過這種簡單的方法，我們也可以容易地在我們的系統中使機器數量翻倍。

在設計系統時，我們可以容易地拿出任意數量的伺服器；所有我們要做的就是創造一個漂亮的和聰明的資料分割函數來在我們的伺服器叢集內部分發資料。如果我們想要在十台伺服器(不是問題)以內拆分資料，使用ID%10作為一個資料分割函數怎麼樣？

但您試圖分布資料到不同的主機上時，必須確保您使用的是一個健壯的資料分割函數，在某種程度上，它可以非常出色地分布資料，每台主機都或多或少的有同樣數量的資料。

使用者按照字母順序來分配資料可能不是一個好主意。其原因在於並不是所有的字母都有同樣的可能。我們不能簡單地假設從字母A到M發生的情況和字母從N到Z發生的情況一樣。如果您想分發一個資料集到一千台伺服器而且不僅僅是少數機器，這是一個大問題。如前所述，它必須是一個健壯的資料分割函數，其產生的分布均勻的效果。

[在大多情況下，雜湊函數(散列函數)將為您提供很好且分布均勻的資料。處理字元欄位時(例如名字，郵件地址等)特別有用。]

查詢不同欄位的例子

在上一節中，您已經看到我們如何容易地使用鍵(key)查詢一個人。我們深入探究一下，看看下面的查詢會發生什麼：

SELECT * FROM t_test WHERE name = ‘Max‘;

請記住，我們使用ID分發資料，在查詢中，我們搜尋名字。該應用程式將不知要使用哪個分區，因為沒有規則告訴我們什麼在哪裡。

作為一個合乎邏輯的結果，應用程式必須要求每個分區的名字。如果要找的名字是一個真實的情況，這是可以接受的；然而，我們不能依賴這個事實。不得不詢問多台伺服器而不是一台伺服器顯然是一個嚴重的解最佳化(未最佳化)而且是不能接受的。

我們有兩個選擇來處理這個問題：

•提出一個比較智能的資料分割函數

•冗餘儲存資料

提出一個比較聰明的資料分割函數必定是最好的選擇，但如果您想查詢不同的欄位，這幾乎是不可能的。

這給我們留下了第二個選項，就是冗餘地儲存資料。對一個資料集儲存兩份，或甚至更多份是不太常見的，實際上確實是一個好的方法來解決這個問題。下面的圖片顯示了這是如何?的：

正如您可以看到的，在這個情境我們有兩個叢集。當一個查詢到來，系統必須決定哪些資料可以在哪個節點上找到。萬一查詢名字，我們(為簡單起見)簡單地按半字母順序分割資料。在第一個叢集，我們的資料仍然按使用者ID分割。

1.3.2 分區的優點和缺點

分區不是一個簡單的單行道是需要理解的重要的事情。如果有人決定使用分區，必須要認識到技術的優點和缺點。與往常一樣，不去思考，沒有什麼神能奇蹟般地解決人類所有的問題。

每個實際使用方式都是不同的，沒有替代的常識和深入思考。

首先，我們看一下下面列出來的拆分的優勢：

• 它有擴充系統超過一台伺服器的能力

• 它是一個簡單的方法

• 它被許多架構支援

• 它可以與多種其它複製方法組合

• 它可以很好地支援PostgreSQL(例如使用PL/Proxy)

光與影子傾向於走在一起，因此分區也有其不足之處，如下：

•在啟動並執行叢集中添加伺服器是非常麻煩的(取決於分區函數的類型)

•可能會嚴重降低您的靈活性。

•並非所有類型的查詢將和在單台伺服器上有相同的效果。

•增加了整體安裝設定的複雜性(如容錯移轉等等)。

•備份需要更多的規劃。

•您可能面臨冗餘和額外的儲存需求。

•應用程式開發人員應該知道分區，以確保高效的查詢被寫入。

在第十三章，使用PL/Proxy擴充，我們將討論如何和PostgreSQL一起能夠高效地利用分區，如何最大效能和擴充性地設定PL/Proxy。

1.3.3 切分和冗餘之間的選擇

學習如何切分一個表只是設計一個可擴充系統架構的第一步。我們在前面章節已經展示的例子中，我們僅僅只有一張表，可以很容易地使用鍵(key)來拆分。但是，要是我們有不只一張表又會怎麼樣呢？假設我們有兩張表：

•一張表名為t_user的表在我們的系統中儲存使用者

•一張表名為t_language儲存我們的系統支援的語言

我們也許可以很好地通過某種拆分方式來拆分表t_user，這個表也可以分配到一個合理數目的伺服器上。但是表t_language怎麼辦？我們的系統可能支援多達十種語言。

可以很好地分區和分發數以億計的使用者，但是拆分十種語言怎麼樣？這顯然是無用的。除此之外，我們可能需要我們的語言表在所有的節點上以便我們可以進行串連。

解決這個問題的方法很簡單：您需要語言表在所有節點上的一個完全的複製。這將不會引起儲存浪費的相關問題，因為表是如此的小。

[確保只有大表被分區。對於小表的情況，表的完全複製可能更有效]

同樣，每一種情況都必須深思熟慮。      

1.3.4 增大和減小叢集的大小

到目前為止，我們一直認為分區大小的設定是恒定不變的。我們已經設定了使我們能夠利用一個在我們叢集內部固定數目分區的分區方式。這種限制可能無法反應日常的需求。您怎麼能夠真正地說出在設計的時候某個特定時刻需要的節點的數目？人們可能對硬體需求有一個粗略的想法，但是實際上知道負荷的期望值是一門藝術而不是科學。

[為了反映這一點，您必須設計一個系統，他可以很容易地調整大小。]

一個常見的錯誤是人們往往會在不必要的小步中增加他們設定的的大小。有人可能會從五台機器增加到六台或七台機器。這可能非常棘手。我們假設在某一時刻我們拆分資料使用使用者ID%5來作為分區函數。要是我們想使用使用者ID%6又怎樣？這不太容易，問題是我們必須在我們的叢集內重新平衡資料來反映我們的新規則。

請記住，我們已經介紹了分區(即，分區)因為我們有這麼大量的資料和這麼多的負載，一台伺服器無法處理這麼多的請求了。如果我們想出來一個策略，現在需要重新平衡資料。我們已經在錯誤的軌道上了。您肯定不希望為了添加兩台或三台伺服器到您現有的伺服器而重新平衡20TB的資料。

實際上，簡單地加倍分區數目是比較容易的。加倍您的分區不需要重新平衡資料，因為您可以簡單地按照後面的策略來做：

•建立每個分區的副本

•刪除每個分區上一半的資料

如果之前您的分區函數是使用者ID%5，而現在應該是使用者ID%10。倍增的優點在於資料不能在兩個分區之間移動。但談到加倍，使用者可能會認為您的叢集大大小會增長的太快。這是事實，但是如果系統的運行能力達到了極限，增加系統資源的10%並不能解決可擴充性的問題。

不僅僅增加一倍的叢集(這是用於大多數情況)，您也可以把更多的心思投入到編寫一個更複雜的資料分割函數保留舊的資料，但更智能地處理最新的資料。有時間依賴的分區函數可能導致它自身的問題，但它可能是值得研究的方法。

[一些NoSQL系統採用定界分割傳播資料。定界分割意味著一個給定的時間幀每個伺服器有固定的資料切片。如果您想要做時間序列分析或相似的工作可能有益。但是，如果您要確保資料被均勻分割可能會適得其反。]

如果您期望您的叢集規模擴大，我們建議從開始就設定比最初需要較多的分區，在一台伺服器上打包不只一個分區。稍後，移動單個分區到添加到叢集的硬體就會很容易。有些雲端服務能夠做到這一點，但是本書不包含這些內容。

要縮小叢集是您可以簡單地套用反向策略和移動多於一個分區到單個伺服器。為將來伺服器的增加留下並敞開大門很容易做到。

1.3.5 結合分區和複製

一旦資料被拆散成有用的組塊，可以被一個伺服器或分區處理，我們必須考慮如何使整個設定更可靠和故障安全。

在您的設定中伺服器越多，這些伺服器中的一台伺服器越容易由於別的原因宕機或不可用。

[這是設計一個高可擴充的系統時總是要避免單點故障。]

為了確保最大的輸送量和最大可用性，我們可以再次轉向冗餘。該設計方法可以歸納為一個簡單的公式，這應該永遠印在一個系統架構師的腦海裡：

 “One is none and two is one”

一台伺服器遠遠不夠為我們提供高可用性。每個系統需要一個備份系統，它可以在非常緊急的情況下接管過來。僅通過拆分一組資料，我們絕對沒有改善可用性，因為我們有較多的伺服器可能也在這個時間點出故障。為瞭解決這個問題，我們可以為我們每個分區(片段)增加副本，正如所示：

每個分區是一個獨立的PostgreSQL資料庫執行個體，每個執行個體有它自己的副本(或多個副本)。

請記住，您可以從全部武器特性和本書中所討論的特性(例如，同步和非同步複製)選擇。本書中所介紹的所有策略可以靈活地組合；單一的技術通常是不夠的，因此要以不同的方式自由組合各種技術來實現您目標。

1.3.6 各種分區解決方案

近幾年，分區已經作為一種工業標準融入到許多可擴充性相關的問題。因此，許多程式設計語言，架構和產品已經提供了隨插即用來支援拆分。

實現分區時，您基本上可以在兩種策略之間進行選擇：

•依靠一些架構/中介軟體

•依靠PostgreSQL方法解決問題

在接下來的兩節中，我們將簡要討論這兩個選擇。這個小概述並不意味著一個全面的指南，而是一個讓您開始分區的概括。

基於PostgreSQL的分區

PostgreSQL本身不能對資料進行分區，但是它有通過附加組件來實現分區所有的介面和方法。其中的一個被廣泛使用的附加組件是PL/Proxy。它已經存在好多年了，並提供卓越透明度以及良好的擴充性。

PL/Proxy背後的思想基本上是使用一個本地虛擬表隱藏一個伺服器組組成的表。

PL/Proxy將在第十三章進行深入地討論，使用PL/Proxy擴充。

外部架構/中介軟體

您也可以使用外部工具來替代依靠PostgreSQL。一些使用的最廣泛和知名的工具是：

• Hibernate shards (Java)

• Rails (Ruby)

• SQLAlchemy (Python)

1.4 總結

本章，您已經瞭解了基本的複製相關的概念，以及有關物理限制。我們已經處理了理論概念，這是基礎的東西，在本書的後面仍然會出現。

下一章，您將通過PostgreSQL交易記錄的指導，我們將概述這一重要組成部分的所有重要方面。您將學會事物日誌對什麼是有益的，它是如何被應用的。

PostgreSQL Replication之第一章 理解複製概念（3）