背景

傳統的將數據集中存儲至單一節點的解決方案，在性能、可用性和運維成本這三方面已經難于滿足海量數據的場景。

從性能方面來說，由于關系型數據庫大多采用 B+ 樹類型的索引，在數據量超過閾值的情況下，索引深度的增加也將使得磁盤訪問的 IO 次數增加，進而導致查詢性能的下降； 同時，高并發訪問請求也使得集中式數據庫成為系統的最大瓶頸。

從可用性的方面來講，服務化的無狀態性，能夠達到較小成本的隨意擴容，這必然導致系統的最終壓力都落在數據庫之上。 而單一的數據節點，或者簡單的主從架構，已經越來越難以承擔。數據庫的可用性，已成為整個系統的關鍵。

從運維成本方面考慮，當一個數據庫實例中的數據達到閾值以上，對于 DBA 的運維壓力就會增大。 數據備份和恢復的時間成本都將隨著數據量的大小而愈發不可控。一般來講，單一數據庫實例的數據的閾值在 1TB 之內，是比較合理的范圍。

在傳統的關系型數據庫無法滿足互聯網場景需要的情況下，將數據存儲至原生支持分布式的 NoSQL 的嘗試越來越多。 但 NoSQL 對 SQL 的不兼容性以及生態圈的不完善，使得它們在與關系型數據庫的博弈中始終無法完成致命一擊，而關系型數據庫的地位卻依然不可撼動。

數據分片指按照某個維度將存放在單一數據庫中的數據分散地存放至多個數據庫或表中以達到提升性能瓶頸以及可用性的效果。 數據分片的有效手段是對關系型數據庫進行分庫和分表。分庫和分表均可以有效的避免由數據量超過可承受閾值而產生的查詢瓶頸。 除此之外，分庫還能夠用于有效的分散對數據庫單點的訪問量；分表雖然無法緩解數據庫壓力，但卻能夠提供盡量將分布式事務轉化為本地事務的可能，一旦涉及到跨庫的更新操作，分布式事務往往會使問題變得復雜。 使用多主多從的分片方式，可以有效的避免數據單點，從而提升數據架構的可用性。

通過分庫和分表進行數據的拆分來使得各個表的數據量保持在閾值以下，以及對流量進行疏導應對高訪問量，是應對高并發和海量數據系統的有效手段。 數據分片的拆分方式又分為垂直分片和水平分片。

垂直分片

按照業務拆分的方式稱為垂直分片，又稱為縱向拆分，它的核心理念是專庫專用。 在拆分之前，一個數據庫由多個數據表構成，每個表對應著不同的業務。而拆分之后，則是按照業務將表進行歸類，分布到不同的數據庫中，從而將壓力分散至不同的數據庫。 下圖展示了根據業務需要，將用戶表和訂單表垂直分片到不同的數據庫的方案。

垂直分片往往需要對架構和設計進行調整。通常來講，是來不及應對互聯網業務需求快速變化的；而且，它也并無法真正的解決單點瓶頸。 垂直拆分可以緩解數據量和訪問量帶來的問題，但無法根治。如果垂直拆分之后，表中的數據量依然超過單節點所能承載的閾值，則需要水平分片來進一步處理。

水平分片

水平分片又稱為橫向拆分。 相對于垂直分片，它不再將數據根據業務邏輯分類，而是通過某個字段（或某幾個字段），根據某種規則將數據分散至多個庫或表中，每個分片僅包含數據的一部分。 例如：根據主鍵分片，偶數主鍵的記錄放入 0 庫（或表），奇數主鍵的記錄放入 1 庫（或表），如下所示。

select * from t_user where id=1

select * from t_user where id=2

水平分片從理論上突破了單機數據量處理的瓶頸，并且擴展相對自由，是數據分片的標準解決方案。

挑戰

雖然數據分片解決了性能、可用性以及單點備份恢復等問題，但分布式的架構在獲得了收益的同時，也引入了新的問題。

面對如此散亂的分片之后的數據，應用開發工程師和數據庫管理員對數據庫的操作變得異常繁重就是其中的重要挑戰之一。 他們需要知道數據需要從哪個具體的數據庫的子表中獲取。

另一個挑戰則是，能夠正確的運行在單節點數據庫中的 SQL，在分片之后的數據庫中并不一定能夠正確運行。 例如，分表導致表名稱的修改，或者分頁、排序、聚合分組等操作的不正確處理。

跨庫事務也是分布式的數據庫集群要面對的棘手事情。 合理采用分表，可以在降低單表數據量的情況下，盡量使用本地事務，善于使用同庫不同表可有效避免分布式事務帶來的麻煩。 在不能避免跨庫事務的場景，有些業務仍然需要保持事務的一致性。 而基于 XA 的分布式事務由于在并發度高的場景中性能無法滿足需要，并未被互聯網巨頭大規模使用，他們大多采用最終一致性的柔性事務代替強一致事務。

目標

盡量透明化分庫分表所帶來的影響，讓使用方盡量像使用一個數據庫一樣使用水平分片之后的數據庫集群。

總結

以上是生活随笔為你收集整理的数据 分片的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。