超大型資料庫的大小常常達到數百gb，有時甚至要用tb來計算。而單錶的資料量往往會達到上億的記錄，並且記錄數會隨著時間而增長。這不但影響著資料庫的執行效率，也增大資料庫的維護難度。除了表的資料量外，對錶不同的訪問模式也可能會影響效能和可用性。在單個伺服器上管理資料儲存的解決方案（詳見
什麼是資料的表分割槽-垂直縮放方案）存在以下問題：
通過新增更多磁碟容量、處理能力、記憶體和網路連線進行垂直縮放可推遲其中某些限制的影響，但這只是一種臨時解決方案。 能夠支援大量使用者和大量資料的水平分割槽能夠接近無限縮放，因此垂直縮放並不一定是最佳解決方案。
解決此需求的方案是什麼？
答案是將資料儲存按一定規則劃分成多片，這樣可儲存和訪問大量資料時提高可伸縮性。
將資料儲存劃分為水平分割槽或分片。 每個分片具有相同的架構，但儲存其自己資料的不同子集，並且它們可以在不同的伺服器上作為儲存節點執行。
此模式具有以下優點：
將資料儲存分割成分片時，決定每個分片中應放置哪些資料。 乙個分片通常包含屬於由資料的乙個或多個屬性決定的指定範圍內的項。 這些屬性構成分片鍵（有時稱為分割槽鍵）。分片鍵應為靜態。 它不應基於可能會更改的資料。
分片以物理方式組織資料。 應用程式儲存和檢索資料時，分片邏輯應能幫助應用程式定位向到相應分片。 可以將此分片邏輯實現為應用程式中資料訪問**的一部分，或者它以一種更透明方式支援分片，則可由資料儲存系統中間實現它。
提取分片邏輯中資料的物理位置可提供哪些分片包含哪些資料的高階控制。 此外，如果分片中的資料稍後需要進行重新分配（例如，分片變得不平衡的情況），則還可以在無需重新處理應用程式的業務邏輯情況下，使資料在分片間進行遷移。 權衡是在確定每個資料項被檢索時的位置所需的附加資料訪問開銷。
若要確保獲得最佳效能和可伸縮性，以適合於應用程式執行查詢的型別方式拆分資料至關重要。 在許多情況下，分片方案不可能完全匹配每個查詢的要求。 例如，在三方或四方物流快遞相關系統（如訂單、倉儲、配送等子系統）多貨主系統中，應用程式可能需要以貨主id 檢索資料，但還可能需要根據其他某些屬性（例如貨主的名稱或位置）查詢此資料。 若要處理這些情況，請使用支援最常執行的查詢的分片鍵實現分片策略。
如果查詢定期使用屬性值結合檢索資料，則可以通過將屬性鏈結在一起定義復合分片鍵。或者如索引模式（例如索引表）來提供針對基於分片鍵未覆蓋屬性的資料的快速查詢。
選擇分片鍵並決定如何在分片之間分發資料時，通常使用三種策略。 注意，分片和託管它們的伺服器之間並不一定是一一對應關係—單個伺服器可以託管多個分片。 策略包括：
查詢策略。 在此策略中，分片邏輯實現了乙個對映，可使用分片鍵將對資料的請求路由到包含該資料的分片。 在多貨主應用程式中，將貨主id 用作分片鍵，可將某個貨主的所有資料一同儲存在該分片中。 同時多個貨主可以共享同一分片，但是單個貨主的資料不會分布於多個分片中。
分片鍵和物理儲存之間的對映可基於每個分片鍵對映到物理分割槽的物理分片。 或者用於重新平衡分片的更靈活方法是虛擬分割槽，其中分片鍵對映到同一編號的虛擬分片，這樣依次對映到更少的物理分割槽。 在此方法中，應用程式使用引用虛擬分片的分片鍵查詢資料，並且以透明方式將虛擬分片對映到物理分割槽。 無需修改應用程式**，虛擬分片和物理分割槽之間的對映既可以更改為使用一組不同的分片鍵。
範圍策略。 此策略將相關專案組合在同一分片中，並通過分片鍵對其進行排序 — 分片鍵是連續的。 它對於經常使用範圍查詢檢索項集的應用程式很有用（返回一組屬於給定範圍內的分片鍵的資料項的查詢）。 例如，如果應用程式經常需要查在給定月份中的所有訂單，如果某月的全部訂單以日期和時間順序儲存在同一分片中，則此資料可以更快地檢索所有訂單。 如果每個訂單儲存在不同分片中，則需要將通過執行大量的點查詢（返回單個資料項的查詢）單獨提取訂單。 下乙個圖說明了分片中資料的儲存順序集（範圍）。
在此示例中，分片鍵是包含將下單月份作為最重要元素（後面是訂單日期和時間）的復合鍵。 新建訂單並將其新增到分片時，訂單資料按自然順序排序。 一些資料儲存支援分片中的兩部分分片鍵，包含可標識分片的分割槽鍵元素和唯一標識某個項的行鍵。 資料通常會以行鍵順序保留在分片中。 受範圍查詢支配並需要組合在一起的項可以使用具有同一分割槽鍵值的分片鍵，但行鍵值是唯一的。
雜湊策略。 此策略的目的是降低形成熱點的可能性（接收不成比例的負載的分片）。 它以在每個分片的大小和每個分片將承載的平均負載之間取得平衡的方式在分片間分發資料。分片邏輯基於資料的乙個或多個屬性的雜湊來計算用於儲存專案的分片。 所選的雜湊函式應在分片間平均分發資料，可能將某些隨機元素引入計算。 下乙個圖採用多貨方委託三方物流企業管理倉庫情景所使用的倉儲系統來說明了基於貨主 id 雜湊的分片貨主資料。
要通過其他分片策略了解雜湊策略的優勢，請考慮按順序註冊新貨主的多貨主應用程式如何將貨主分配到資料儲存區中的分片。 使用範圍策略時，貨主 1 到 n 的資料都將儲存在分片 a 中，貨主 n+1 到 m 的資料都儲存在分片 b 上，依次類推。 如果最近註冊的貨主也是最活躍的貨主，則多數資料活動將發生在少數分片中，這會導致熱點。 與此相反，雜湊策略根據貨主 id 的雜湊將貨主分配到分片中。 這意味著連續的貨主最有可能被分配到不同的分片，這會在分片間分發負載。 上圖展示了為貨主 55 和 56 分發負載的過程。
者三個分片策略的優勢和注意事項如下：
最常見的分片系統會實現上述方法之一，但是你還應考慮應用程式的業務要求及其資料使用模式。 例如，在多貨主應用程式中：
每個分片策略表示用於管理縮小、擴大、資料移動和維護狀態的不同能力和複雜性水平。
查詢策略允許在聯機或離線時，在使用者級別執行縮放和資料移動操作。 該技術可以暫停某些或所有使用者活動（可能在非高峰時段）、將資料移動到新的虛擬分割槽或物理分片、更改對映、使儲存此資料的任何快取無效或重新重新整理這些快取，然後允許使用者活動恢復。 通常可以集中管理此型別的操作。 查詢策略要求高度可快取及可友好複製的狀態。
範圍策略對縮放和資料移動操作施加了一些限制，這些限制通常必須在部分或全部資料儲存離線時執行，因為資料必須在分片間進行拆分和合併。 如果大多數活動是針對相同範圍內的相鄰分片鍵或資料識別符號，則將資料移動到重新平衡分片可能無法解決負載不均的問題。 範圍策略還可能需要維護一些狀態，以便將範圍對映到物理分割槽。
雜湊策略使縮放和資料移動操作更複雜，因為分割槽鍵是分片鍵或資料識別符號的雜湊。 必須從雜湊函式或經修改以提供正確對映的函式中確定每個分片的新位置。 但是，雜湊策略不需要狀態維護。
在決定如何實現此模式時，請考慮以下幾點：
Mycat水平分片策略（水平分表拆分）
可以實現按照地區進行分表 根據不同的列舉 常量 進行分表儲存 1.mysql中建立3個資料庫分別為user db1 user db2 user db3 2.在3個資料庫中建立3個一樣的資料表 order info order info表中有字段name 3.配置mycat環境 schema.xml ...
資料的水平分割
早前公司有個大系統沒有做資料的水平分割，導致興許的效能優化不能做到最佳，有些功能優化到7s，8s就無法繼續了。這個大系統曾經是分21個點部署，然後進行了大集中，僅僅部署了乙個點。1.在做資料的水平切割之前一定要理解系統的業務。我的系統是mis，資料能夠分為兩類 一類是基礎資料，一類是業務流程資料。基...
mycat 水平分片配置 最基礎入門學習
前提，準備3至4臺伺服器，如果3臺的話，其中一台既是mysql，也是mycat伺服器 並在每台伺服器上 安裝好jdk1.8和mysql jdk1.8安裝步驟，可檢視博文 mysql安裝步驟，可檢視博文，mysql的遠端訪問許可權，最好開啟，方便測試，方法自行baidu 主機分布情況 172.16.2...