必需要了解的分庫分表知識

分庫分表產生的背景

隨着互聯網的迅速發展，會致使產生海量的數據，在數據量還比較小的時候，傳統的處理方式是將數據存儲在關係或者非關係型數據庫中，可是隨着數據量逐漸增長，單個數據庫的表已經很難容納全部數據，因此業界出現了分庫分表的概念。利用分爲知之的思想，完美的將數據進行了拆分，可是也帶來了許多比較棘手的問題，好比引入了分佈式事務、擴容等。

數據庫使用演變史

咱們在應用中使用數據庫主要經歷如下三個階段

• 單庫單表，應用初始階段，此階段因爲數據量小於數據庫承受閾值，對應用性能上基本沒有影響。
• 單庫分表，因爲數據庫中的某張表數據庫量過大，對應用的性能有了必定的影響，好比查詢等，對某個表會分爲table_1,table_2,table_N,將一張表拆分N張小表。注意此階段磁盤容量充足。可是更多的是使用的數據庫的分區，分區原理和分表原理很類似，好比mysql hash的分區

CREATE TABLE `test_user_hash` (
 `user_id` bigint(19) NOT NULL,  `user_name` varchar(50) NOT NULL,  `ext_int` int(2) NOT NULL,  `ts` bigint(19) NOT NULL,  PRIMARY KEY (`user_id`,`ext_int`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; //Mysql 分區 ALTER TABLE `test_user_hash` PARTITION BY HASH(ext_int) PARTITIONS 3 ; 複製代碼

mysql數據庫中存儲形式，因爲上述是按3hash求餘，因此會分三個存儲文件

• 分庫分表，上述兩種都沒法解決時，出現分庫分表方案，即將單數據庫數據分散在多個數據庫中。

什麼狀況下須要分庫分表

​ 原則上能不分庫儘可能不分庫，沒法避免時或者已經有趨勢顯示須要分庫分表，則使用分庫分表。

• 數據庫的吞吐量達到瓶頸，須要擴多個數據庫實例來提升；
• 數據表的數據達到必定的量級，對應用查詢等性能有了明顯的影響，能夠經過分庫分表來提高性能，有資料顯示Mysql數據庫單表數據量超過5000w後對查詢性能有影響
• 爲了不後期複雜的擴容，提早根據數據增加的趨勢預估N年後的數據量 count，count / 單庫容量 =所需 數據庫實例，屬於提早規劃，防範於未然。

常見拆分方案

常見拆分方案有兩種：垂直拆分和水平拆分，分庫分表則是一種對數據庫拆分的常看法決方案。

• 垂直拆分

垂直拆分是根據業務特色，將某些有關係的表集中存儲在的某個DB中，而且這些表的數據量通常不會過大。好比電商系統中有用戶模塊、訂單模塊

• 水平拆分

每一個db中存在相同的表結構，根據必定的規則將數據分散在多個DB中

分庫分表實現方案

主要有如下三種實現方案

• 客戶端分片
• 代理實現分片
• 分佈式數據庫

客戶端分片

客戶端分片通常有兩種實現方式，一種是應用層直接實現，應用層內包含分片邏輯以及分片算法等，與業務代碼緊耦合

應用層實現了全部邏輯，業務人員須要參與。

另一種是實現標準的JDBC協議，對應用提供包裝過的JDBC，對應用使用無感，實現邏輯做爲jar，嵌入在應用中，應用能夠靈活的切換

這種方式是實現標準的JDBC接口，對應用使用原生JDBC無影響，兩者遵循統一規範，相比於第一種方式好處是與業務代碼解耦。提升靈活性。

代理分片

代理方式實現的方式是在應用和數據庫中間增長代理層，獨立部署，代理充當數據的角色，對應用來講使用代理就等價於數據庫，原則上使用代理與直接使用數據庫是無區別，可是代理畢竟不是真實的數據庫，代理層只是解決如何充分的利用數據庫資源，代理層實現了全部分庫分表邏輯，包括分片規則等，業務人員無需關注，能夠將更多的時間投入到業務實現邏輯中。

通常會在代理層外添加一層負載。

這種方式可讓業務人員更專一於業務，可是複雜度相比第一種要高不少，增長了通信鏈路，涉及到協議轉換，因此會對性能相比於第一種方案有明顯的損耗，同時對人員的要求也比較高，須要技術大牛來支持，不然一旦出現問題很難處理。比較耳熟的有Mycat，因爲本人基於Mycat作過深度二次開發，對源碼有必定的瞭解，缺陷真的很。。。。，但願使用者仔細斟酌，題外話o(￣︶￣)o

分佈式數據庫

耳熟的有TiDB，對外提供可伸縮的架構體系，提供必定的分佈式事務，可伸縮和分佈式事務在內部實現中包裝，對用者無需直接控制這些特性，好比TiDB提供了JDBC接口，應用層使用TiDB和直連MySQL數據庫使用方式沒什麼區別

分庫分錶帶來的問題

• 數據切分後，分散在不一樣的DB中，在使用數據庫原生的Join操做時，存在跨庫Join，性能較差。
• 引入分佈式事務，分佈式事務的一致性很難解決。
• 分頁，越日後翻頁，查詢越慢，好比 查詢100w後的10條數據，limit 1000000，10。
• 不停機擴容難度增大

後續文章會分析爲了解決分庫分錶帶來的問題，業界中有哪些比較成熟的解決方案，敬請期待...