數據庫分庫和分表是什么意思

這篇文章主要介紹“數據庫分庫和分表是什么意思”，在日常操作中，相信很多人在數據庫分庫和分表是什么意思問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫分庫和分表是什么意思”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、什么情況下拆

• 數據量不斷增加的情況下，當前單個的數據庫和數據表已經無法滿足海量數據。索引壓力大。

• 數據庫的吞吐量達到了瓶頸。

• 希望在后期擴容時，對應用層的配置改變最少。

這個時候，就需要重新設計，一個字，拆！

二、常見的拆分手法

拆分的總思想：分而治之

1. 水平拆分

保留原有的數據庫（表）結構，將一個庫（表）拆分為多個庫（表）。比如t_user表拆分為t_user1、t_user2。

優點：

• 單庫（表）的數據保持的一定數量級范圍內，保證性能

• 切分時結構相同，代碼改造少

• 提高了系統的穩定性和負載能力

分片緯度

• 哈希

數據切片比較均勻，壓力被分散了。 但是，查詢就需要進行聚合了。

• 時間

適用于有明顯時間特點的。針對不同時間段的數據訪問頻率不同，可以配置不同的硬件資源來節約成本。也方便歸檔。

2. 垂直拆分

根據業務的緯度，將原本的一個庫（表）拆分為多個庫（表），每個庫（表）和原來的結構不同。比如t_user表拆分為t_user_basic、t_user_detail。

優點：

• 業務邏輯更清晰

• 動靜分離、冷熱分離

冷數據查詢多，可以考慮MyISAM引擎；熱數據更新多，可以考慮InnoDB引擎。

讀多寫少的數據，可以多配置幾個從庫；對于熱數據，可以使用多個主庫構建分庫分表的結構。

對于特殊的活躍數據，可以考慮使用redis等緩存，等累計到一定數據量時再更新數據庫。

• 數據維護簡單

• 按照成本、應用的等級、應用的類型將表放到不同的機器上，方便管理

兩種方式統一的缺點：

• 分布式事務的問題

• join的問題

• 跨節點的排序、分頁問題

• 多數據源的管理問題

三、實現方案

1. 客戶端分片

2. 代理層分片

3. 支持事務的分布式數據庫（TiDB、OceanBase）

四、帶來的問題

1. 擴容

• 操作繁瑣

• 遷移數據時，數據量大會導致不一致，要先清洗舊數據，洗完之后再使用新規則，再做全量對比。

• 金融交易數據，將數據動靜分離。歷史數據不會被更新，可以拉長雙寫的時間窗口，當過了這個窗口后，直接遷移那些不會被更新的歷史數據。

• 數據量大時，抽樣對比。

2. 查詢問題

• 難支持多維度查詢，可以做數據異構冗余。或者搜索引擎。

• 買家下單后的商品信息查詢時不能和下單前不一致，這個時候需要做快照。

3. 事務問題

4. 同組數據的跨庫問題

• 盡量把同一組數據放到同一臺數據庫服務器上。

五、實戰

去年2018年，在*美時，做的一個物流電商項目，其中在存儲運單時，由于每個月的運單數當時已經成型（百萬）。所以，將訂單表按照時間分片，并且將主鍵和復雜查詢數據存儲至es。這樣，在以時間維度查詢時直接走DB，在其他查詢條件時，先走es查詢出主鍵，再根據主鍵信息查詢DB。

• 這樣建表，有個好處是表可以無限制的根據時間創建并使用。

• 同時，也會帶來壞處，當業務猛增，數據量暴增時，按月分可能無法滿足，這個時候就需要改變路由策略。

• 最大的壞處是，這樣會產生冷數據問題，比如一年前、兩年前、甚至更久的數據可能已經幾乎不會再訪問。這種情況可以走es或者離線hive

到此，關于“數據庫分庫和分表是什么意思”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！