前言

任何應用程序或網站，如果經歷了顯著增長，最終都需要進行擴展以適應流量的增加。對于數據驅動的應用程序和網站來說，擴展的方式必須確保數據的安全性和完整性。很難預測一個網站或應用程序會變得多受歡迎，或者這種受歡迎程度能維持多久，這就是為什么一些組織選擇能夠動態擴展數據庫的數據庫架構。在這篇概念性文章中，我們將討論這樣一種數據庫架構：分片數據庫。分片在近年來受到了大量關注，但許多人對它是什么或者在什么情況下對數據庫進行分片是有意義的并沒有清晰的理解。我們將討論分片是什么，它的一些主要優點和缺點，以及一些常見的分片方法。

什么是分片

分片是一種數據庫架構模式，與水平分區有關——即將一個表的行分離到多個不同的表中，這些表被稱為分區。每個分區都有相同的模式和列，但行完全不同。同樣，每個分區中保存的數據是獨特的，并且與其它分區中保存的數據互不影響。

我們可以從水平分區與垂直分區的關系來幫助理解水平分區。在垂直分區的表中，整個列被分離出來并放入新的、不同的表中。一個垂直分區中保存的數據與所有其他分區中的數據是獨立的，并且每個分區都保存著不同的行和列。下面的圖示展示了一個表如何同時進行水平和垂直分區：

圖片

分片涉及將數據分成兩個或更多的小塊，稱為邏輯分片。這些邏輯分片隨后被分布到不同的數據庫節點上，這些節點被稱為物理分片，可以保存多個邏輯分片。盡管如此，所有分片中保存的數據集體代表了整個邏輯數據集。

數據庫分片體現了一種無共享架構。這意味著分片是自治的；它們不共享任何相同的數據或計算資源。然而，在某些情況下，將某些表復制到每個分片中作為引用表可能是有意義的。例如，假設有一個應用程序的數據庫依賴于固定的重量測量轉換率。通過將包含必要轉換率數據的表復制到每個分片中，它將有助于確保所有分片都保存了查詢所需的所有數據。

通常，分片是在應用程序級別實現的，這意味著應用程序包含定義傳輸讀取和寫入到哪個分片的代碼。然而，一些數據庫管理系統內置了分片功能，允許你直接在數據庫級別實現分片。

鑒于我們對分片的一般概述，讓我們來看看與這種數據庫架構相關的一些優點和缺點。

分片的優點

分片數據庫的主要吸引力在于它可以幫助實現水平擴展，也稱為擴展外部。水平擴展是在現有堆棧中添加更多機器以分散負載并允許更多流量和更快處理的做法。這通常與垂直擴展相對比，后者稱為擴展上行，涉及升級現有服務器的硬件，通常是通過增加更多RAM或CPU。

在單臺機器上運行關系數據庫并根據需要通過升級其計算資源來擴展它是相對簡單的。然而，任何非分布式數據庫在存儲和計算能力方面都將受到限制，因此具有水平擴展的自由使你的設置更加靈活。

選擇分片數據庫架構的另一個原因是加快查詢響應時間。當你在未分片的數據庫上提交查詢時，它可能必須搜索你查詢的表中的所有行，才能找到你正在尋找的結果集。對于具有大型、單一數據庫的應用程序，查詢可能會變得非常慢。通過將一個表分片成多個，查詢必須覆蓋的行數減少，結果集返回得更快。

分片還可以通過減輕停機的影響來使應用程序更可靠。如果你的應用程序或網站依賴于未分片的數據庫，停機可能會使整個應用程序不可用。通過分片數據庫，停機可能只會影響單個分片。盡管這可能會使應用程序或網站的某些部分對某些用戶不可用，但總體影響仍然會比整個數據庫崩潰時要小。

分片的缺點

雖然分片數據庫可以使擴展更容易并提高性能，但它也可能帶來一定的限制。在這里，我們將討論其中的一些，并解釋為什么它們可能是完全避免分片的原因。

人們遇到分片的第一個困難是正確實現分片數據庫架構的復雜性。如果做得不正確，分片過程可能導致數據丟失或表損壞的風險很大。即使做得正確，分片也可能對你的團隊工作流程產生重大影響。用戶必須管理跨越多個分片位置的數據，而不是從一個單一的入口點訪問和管理數據，這可能會對某些團隊造成干擾。

用戶在分片數據庫后有時會遇到的一個問題是分片最終變得不平衡。舉個例子，假設你有一個數據庫有兩個獨立的分片，一個用于姓氏以字母A到M開頭的客戶，另一個用于姓氏以字母N到Z開頭的客戶。然而，你的應用程序為姓氏以字母G開頭的人提供了過多服務。因此，A-M分片逐漸積累了比N-Z分片更多的數據，導致應用程序減速并為大量用戶停滯不前。A-M分片已經成為了所謂的數據庫熱點。在這種情況下，分片數據庫的任何好處都被減速和崩潰所抵消。數據庫可能需要修復和重新分片，以實現更均勻的數據分布。

另一個主要缺點是一旦數據庫被分片，就很難將其恢復到未分片的架構。在分片之前制作的數據庫備份不會包括自分區以來寫入的數據。因此，重建原始未分片架構需要將新分區數據與舊備份合并，或者將分區數據庫轉換回單個數據庫，這兩者都是昂貴且耗時的努力。

最后一個需要考慮的缺點是分片不是每個數據庫引擎都原生支持的。例如，PostgreSQL不包括自動分片作為功能，盡管可以手動分片PostgreSQL數據庫。有一些Postgres分支確實包括自動分片，但這些通常落后于最新的PostgreSQL發布，并且缺少某些其他功能。一些專門的數據庫技術——如MySQL Cluster或某些數據庫即服務產品，如MongoDB Atlas——確實包括自動分片作為功能，但這些數據庫管理系統的普通版本則不支持。因此，分片通常需要“自己搞定”的方法。這意味著分片的文檔或故障排除提示通常很難找到。

當然，這些只是分片前的一些問題。根據其用例，分片數據庫可能還有許多其他潛在的缺點。

分片架構

一旦你決定分片你的數據庫，接下來你需要弄清楚你將如何進行。在運行查詢或將傳入數據分布到分片表或數據庫時，確保它去到正確的分片是至關重要的。否則，可能會導致數據丟失或查詢緩慢。在這一部分，我們將討論一些常見的分片架構，每種架構都使用稍微不同的過程來在分片之間分布數據。

基于鍵的分片

基于鍵的分片，也稱為基于哈希的分片，涉及使用從新寫入數據中取出的值——例如客戶的ID號、客戶端應用程序的IP地址、郵政編碼等——并將其插入哈希函數以確定數據應該去哪個分片。哈希函數是一種函數，它將數據（例如客戶電子郵件）作為輸入，并輸出一個離散值，稱為哈希值。在分片的情況下，哈希值是一個分片ID，用于確定傳入數據將存儲在哪個分片上?？偟膩碚f，過程是這樣的：

圖片

為了確保條目以正確的分片和一致的方式放置，輸入哈希函數的值應該都來自同一列。這個列被稱為分片鍵。簡單來說，分片鍵類似于主鍵，因為兩者都用于為單個行建立唯一標識符。廣義上講，分片鍵應該是靜態的，這意味著它不應該包含隨時間變化的值。否則，它將增加更新操作的工作量，并可能減慢性能。

雖然基于鍵的分片是一種相當常見的分片架構，但在嘗試動態添加或刪除數據庫服務器時，它可能會使事情變得棘手。當你添加服務器時，每個服務器都需要一個相應的哈希值，如果你不添加它們，許多現有條目，如果不是全部的話，都需要重新映射到它們新的、正確的哈希值，然后遷移到適當的服務器。當你開始重新平衡數據時，新的和舊的哈希函數都將無效。因此，你的服務器在遷移期間將無法寫入任何新數據，你的應用程序可能會受到停機的影響。

這種策略的主要吸引力在于它可以用來均勻地分布數據，以防止熱點。此外，因為它算法性地分布數據，所以不需要像范圍或目錄基于分片的其他策略那樣維護所有數據位置的映射。

基于范圍的分片

基于范圍的分片涉及根據給定值的范圍進行分片數據。為了說明，假設你有一個數據庫存儲了零售商目錄中的所有產品信息。你可以創建幾個不同的分片，并根據它們所屬的價格范圍分配每個產品的信息，如下所示：

圖片

基于范圍的分片的主要好處是它相對容易實現。每個分片保存不同的數據集，但它們都有一個與原始數據庫相同的模式。

應用程序代碼讀取數據屬于哪個范圍，然后將其寫入相應的分片。

另一方面，基于范圍的分片不能防止數據分布不均，導致上述數據庫熱點?？纯词纠龍D，即使每個分片保存相等數量的數據，特定產品可能會比其他產品受到更多關注。它們各自的分片將反過來接收不成比例的讀取數量。

基于目錄的分片

要實現基于目錄的分片，必須創建和維護一個使用分片鍵跟蹤哪個分片保存哪個數據的查找表。查找表是一個保存有關特定數據位置的靜態信息的表。下面的圖示展示了基于目錄分片的簡單示例：

圖片

在這里，配送區域列被定義為分片鍵。來自分片鍵的數據被寫入查找表，以及每行相應的分片。這與基于范圍的分片類似，但不是確定分片鍵數據屬于哪個范圍，而是每個鍵都與其自己的特定分片相關聯?；谀夸浀姆制窃诜制I基數較低——意味著它有少量可能的值——并且對于一個分片來說存儲一系列鍵沒有意義的情況下，比基于范圍的分片更好的選擇。請注意，它也與基于鍵的分片不同，因為它不需要通過哈希函數處理分片鍵；它只是檢查鍵與查找表，看看數據需要寫入哪里。

基于目錄的分片的主要吸引力在于其靈活性?；诜秶姆制軜嬒拗颇阒付ㄖ档姆秶?，而基于鍵的分片限制你使用固定的哈希函數，這如前所述，以后更改起來可能非常困難。另一方面，基于目錄的分片允許你使用任何系統或算法將數據條目分配給分片，并且使用這種方法動態添加分片相對容易。

雖然基于目錄的分片是這里討論的分片方法中最靈活的，但每次查詢或寫入前都需要連接到查找表可能會對應用程序的性能產生不利影響。此外，查找表可能成為單點故障：如果它變得損壞或以其他方式失敗，可能會影響寫入新數據或訪問現有數據的能力。

我應該分片嗎？

是否應該實施分片數據庫架構幾乎總是一個有爭議的問題。一些人認為，對于達到一定規模的數據庫來說，分片是不可避免的結果，而另一些人則認為，由于分片帶來的操作復雜性，除非絕對必要，否則應避免分片。

由于這種增加的復雜性，分片通常只在處理非常大的數據量時才執行。以下是一些可能有益于分片數據庫的常見場景：

• 應用程序數據量增長到超過單個數據庫節點的存儲容量。
• 數據庫的寫入或讀取量超過單個節點或其只讀副本的處理能力，導致響應時間變慢或超時。
• 應用程序所需的網絡帶寬超過了單個數據庫節點及其任何只讀副本可用的帶寬，導致響應時間變慢或超時。

在進行分片之前，你應該嘗試所有其他優化數據庫的選項。你可能需要考慮的一些優化包括：

• 設置遠程數據庫。如果你正在使用一個所有組件都駐留在同一臺服務器上的單體應用程序，你可以通過將數據庫移動到它自己的機器上來提高數據庫的性能。這不會像分片那樣增加太多復雜性，因為數據庫的表保持完整。然而，它仍然允許你將數據庫與其余基礎設施分開垂直擴展。
• 實施緩存。如果你的應用程序的讀取性能是造成問題的原因，緩存是一種可以幫助提高性能的策略。緩存涉及將已經請求的數據暫時存儲在內存中，允許你稍后更快地訪問它。
• 創建一個或多個只讀副本。這是另一種可以幫助提高讀取性能的策略，它涉及將數據從一個數據庫服務器（主服務器）復制到一個或多個輔助服務器。在此之后，每個新的寫入都會先發送到主服務器，然后再復制到輔助服務器，而讀取則專門在輔助服務器上進行。像這樣分配讀取和寫入可以防止任何一臺機器承擔過多的負載，有助于防止減速和崩潰。請注意，創建只讀副本涉及更多的計算資源，因此成本更高，這可能對一些人來說是一個重要的約束。
• 升級到更大的服務器。在大多數情況下，將數據庫服務器升級到具有更多資源的機器比分片需要的努力要少。與創建只讀副本一樣，升級的服務器將擁有更多的資源，可能會花費更多的錢。因此，只有在調整大小確實是你的最佳選擇時，你才應該進行調整。

請記住，如果你的應用程序或網站增長到一定程度，這些策略中的任何一個都將不足以單獨提高性能。在這種情況下，分片確實可能是你的最佳選擇。

結論

分片對于那些尋求水平擴展數據庫的人來說可能是一個很好的解決方案。然而，它也增加了相當大的復雜性，并為你的應用程序創造了更多的潛在故障點。分片對某些人來說可能是必要的，但創建和維護分片架構所需的時間和資源可能會超過其他人的利益。

通過閱讀這篇概念性文章，你應該對分片的利弊有了更清晰的了解。展望未來，你可以利用這些見解來做出更明智的決策，關于是否分片數據庫架構適合你的應用程序。