本文提供了一些數據分片的一些原則和經驗，遵循這些提示，有助於確保數據正確的分片，而不是阻礙你的應用程序的可擴展性。
新的 SaaS 初創公司很少考慮如何擴展他們的應用程序。當然，他們會設想有一天他們會需要擴張，並將納入計划，但他們很少在早期就為可擴展性設計他們的應用程序。相反，他們更經常關注於完成他們可以銷售的功能。
但是，考慮擴展的時間應該在最開始的時候–在你的第一個客戶注冊你的服務之前。隨着公司推出一個又一個的功能，並且客戶不斷注冊，業務就會增長。隨着業務的增長，擴展最終成為一個關注點。
當一個新的 SaaS 服務遇到資源容量限制時，特別是數據訪問資源容量，擴展的需要往往變得很明顯。通常情況下，不管是什么技術，數據庫都太小了，無法滿足不斷增長的需求，而且無法擴展到一定程度。
無論你使用什么數據庫技術，也無論你投入多大的服務器或其他基礎設施來給自己留出發展空間，這個問題都會發生。遲早有一天，你會遇到擴展問題。
一旦擴展資源需求變得非常緊迫，並且需要認真做出的擴展決定，進行數據分片：將你的數據划分到多個並行數據庫中，每個數據庫持有你的業務部分。這通常是被引入的早期解決方案之一，以擴大你的應用程序的擴展能力。把數據分成多個部分，似乎是解決數據資源問題的一個簡單解決方案。如果一個數據庫太小，無法處理你的流量，讓我們試試兩個，或三個，或四個！這就是分片。 一旦你將你的應用數據分片，繼續使用同樣的方法進行擴展似乎非常簡單。隨着你的流量增長，只需向你的應用添加更多的並行數據庫。 讓我們仔細看看分片，以及如何用它來解決早期的數據庫擴展問題。
1. 分片例子
究竟什么是分片？一個典型的 SaaS 用例涉及到客戶與一些應用程序對話，然后利用存儲在數據庫中的數據。
隨着客戶數量的增加，應用程序的負載也在增加。通常，通過添加更多的服務器來處理負載，增加應用程序的容量是相對容易的。
然而，一旦你達到一定數量的客戶，你的擴展限制突然變成了你的數據庫。你的數據庫不能有效地處理更多的客戶，而你的應用程序最終會出現可用性問題、性能問題和其他問題。這在圖 1 中得到了說明。
一旦你的數據庫達到了一定的規模和容量，就很難使它再增長。相反，你可能會選擇將數據庫分成多個平行的數據庫，並在不同的數據庫之間划分客戶群。
在圖 2 中，我們把客戶分成兩個獨立的數據庫，突然間，我們可以毫無問題地處理額外的客戶。
每個數據庫都包含支持特定客戶所需的所有數據，但單個客戶被分割在不同的數據庫中。
你如何在多個數據庫中分割數據，並在應用程序中知道哪個數據庫有哪個客戶的數據？通常情況下，分片 key 被用來確定哪個數據庫包含一組特定的數據。
通常情況下，這個分片鍵是諸如客戶 ID 這樣的東西。通過將一些客戶 ID 分配到一個數據庫，將其他客戶 ID 分配到另一個數據庫，你可以將一個特定客戶的所有數據放到一個數據庫中。這樣，對於每個客戶來說，一個單一的數據庫將被用於所有的客戶請求，而且新的客戶可以在任何合理的規模下被添加到新的數據庫。
2. 分片出錯的地方
那么，這種方法有什么問題呢？當你的客戶開始增長時，問題就開始了。隨着客戶開始更多地使用應用程序，他們開始使用更多的存儲和消耗更多的資源。突然間，你的一個分片的容量超載了，你需要把一些客戶從一個分片卸載到另一個（負載較少的）分片。你必須把所有這些客戶的數據，復制到一個新的分片區，然后把他們的客戶 ID 指向新的分片區。
那么，這種方法有什么問題呢？當你的客戶開始增長時，問題就開始了。隨着客戶開始更多地使用應用程序，他們開始使用更多的存儲和消耗更多的資源。突然間，你的一個分片的容量超載了，你需要把一些客戶從一個分片卸載到另一個（負載較少的）分片。你必須把所有這些客戶的數據，復制到一個新的分片區，然后把他們的客戶 ID 指向新的分片區。
這不是一個微不足道的操作。如果你想在不給客戶造成任何明顯的停機時間的情況下完成它，那就更不簡單了。你如何為一個特定的客戶移動大量的數據而不影響客戶在移動過程中訪問應用程序的能力？答案通常涉及到編寫自定義工具。這種工具的編寫通常是不容易的，執行起來也有風險。圖 3 說明了這個過程，當一個 "大客戶 "使一個數據庫過載時，你必須把他們轉移到另一個較新的數據庫。
下一個發生的問題是，當一個客戶變得如此之大，以至於它自己需要整個數據庫分片。當你處於這種情況時，當這個客戶增長得更大一些時，會發生什么？
突然間，你沒有地方可以移動這個客戶了，你已經達到了另一個擴展極限–你目前的分片策略根本無法處理的極限。
重新分區、重新平衡、傾斜的使用、跨分片報告和分區分析是更多必須處理的問題。然而，需要處理快速變化的數據集大小，以及需要在分片之間移動數據，是高質量分片機制的最大挑戰。
3. 分片還是不分片
如果你不需要分片，就不要分片! 你可以利用其他策略，比如分庫分表，即按照服務和功能划分數據，而不是將其切成分片，來處理數據的擴展。
然而，有時分片是不可避免的。所以，如果你必須分片，請記住以下幾點：
1) 在需要它們之前就設置好分片
未雨綢繆，根據樂觀的規模預測你對分片的需求，並在實際使用需要之前很久進行分片。
2) 仔細選擇分片 key
你希望你的分片是獨立的，但也是很平衡的。使用客戶 ID 或者 利用 ID 基因，似乎是個好主意–它允許你輕松地創建獨立的數據集–但客戶的規模差異很大，基於客戶 ID 的分片平衡可能很麻煩。基於另一種公共資源的分片是可能的，但是具體的答案在很大程度上取決於你的應用程序的業務邏輯和需求。
3) 建立工具來管理分片
你需要這些工具的時間要比你預期的早得多。這些工具需要能夠快速有效地將單個分片的元素（客戶等）從一個分片透明地轉移到另一個分片。這些工具必須能夠在擴展事件中快速地重新平衡多個資源，而且你需要分析，以便在分片規模出現偏差時發出警報。
認真研究用其他方法來划分你的數據。考慮將你的數據存儲在各個服務和微服務中，而不是集中的數據存儲。數據集越小，對分片的需求就越小，在需要時管理分片就越簡單和高效。
大多數現代應用都會經歷增長–使用量的增長、數據規模和復雜性的增長、應用復雜性的增長，以及管理應用所需的人員數量和組織規模的增長。人們很容易忽視這些增長的挑戰，直到為時已晚，然后使用快速和簡單的解決方案來解決眼前的需要。但是，當涉及到數據分片時，規划和徹底的執行對於確保這種架構選擇是一種擴展的幫助，而不是一種擴展的責任至關重要。
參考資料：