Sharding-jdbc（一）分庫分表理解

一、什麼是分庫分表

　　所謂的分庫分表就是數據的分片（Sharding）。

二、爲何須要分庫分表

　　由於隨着公司的業務愈來愈大，對於現成單機單個應用瓶頸問題，對數據持久化硬盤如何進行擴容。

　　能夠從4個方面就行考慮：

　　一、表的設計要符合業務需求

　　二、sql語句的優化

　　三、讀寫分離

　　四、分庫分表

三、什麼是讀寫分離

　　將操做的sql語句到指定的庫中操做，達到讀寫分開操做不一樣的數據庫。

　　數據庫的角色：主庫（master，就是寫庫），從庫（slave，就是讀庫）。

　　讀寫分離對insert、update、delete語句的操做走主庫，select語句走從庫，（所謂的crud操做）

　　應用：對於讀多寫少業務對從庫的壓力比較大，對於寫多讀少業務對主庫壓力比較大。

　　讀寫分離java開源框架分類：

　　　　客戶端（應用層）：TDDL、Sharding-jdbc

　　　　這裏講解Sharding-jdbc：

　　　　

　　　　特色：

 　　　　　　優勢：一、程序自動完成，數據源方便管理；二、不須要維護、由於沒有中間件；三、理論支持任何數據庫（sql標準）

 　　　　　　缺點：一、存在代碼入侵性；二、加大開發成本；三、不能作到動態添加數據源，添加數據源還須要重啓程序；四、程序開發完後，運維人員參與不了

　　　　中間件（代理層 proxy）：mysql proxy、mycat、altas（360開發的）

　　　　

　　　　特色：

 　　　　　　優勢：一、數據添加不會影響到程序；二、應用層不需管理數據庫層方面，由代理層去管理；三、添加數據源不須要重啓程序

　　　　　　 缺點：一、程序依賴的中間件，提升維護工做；二、容易出現高可用問題；三、中間件致使切換數據庫變的困難；二、增長了proxy，程序性能降低

四、什麼是分庫分表

　　分庫分表實際上是基於讀寫分離上面提出的方案（也就是目前關係型數據庫終極解決方案）。

　　讀寫分離：當數據寫很大的時候，（例如：雙十一 天貓、京東下單時寫的數據很大）master寫的壓力大的問題以及公司隨着業務增大以後產生瓶頸問題，須要數據分片來解決。

　　分庫分表：目前數據庫終極解決方案：解決高併發、數據分片。

　　分庫（表）類型：

　　　　垂直：

　　　　　　將一個比較多字段的表拆分紅多個小表，將不一樣字段放到不一樣的小表中，下降單表（單庫）大小的目的來提升性能。

　　　　　　通俗：大表拆小表，拆分是基於關係型數據庫表的列（字段）來進行。

　　　　　　特色：每一個表（庫）的結構都不同

　　　　　　　　    每一個表（庫）的列數據至少有一列是同樣的

　　　　　　　　    每一個表（庫）並集是整個數據庫的全量數據

　　　　　　　　    每一個表（庫）數據量同樣（不會變）：例如（user-info字段 + user-basse字段 = user的全字段）

　　　    水平：

　　　　　　某個字段按照必定規律進行拆分，將一個表的數據分到多個表（庫）中。

　　　　　　下降表的數據量，優化查詢數據量的方式來提升性能。例如：（user1（數據） + user2 （數據） = user所有數據）

　　　　　　特色：每一個表（庫）的結構同樣

　　　　　　　　    每一個表（庫）數據量不同。（要是同樣只能說太剛好了，可是不能夠存在同樣的數據）

　　　　　　　　    每一個表（庫）的並集是整個數據庫（表）全量數據。

五、分庫分表常見的算法：

　　一、Hash（取模）：經過表的一列字段進行hash取出code值來區分的。

　　二、Range（範圍）：按年份、按時間、按某值等。

　　三、List預約義：事先定於好。

六、分庫分表以後帶來什麼問題

　　一、查詢數據結果集合須要查詢多個庫，比較麻煩。

　　二、sql語句須要修改，將以前沒分庫分表的語句須要從新修改，比較麻煩。

　　三、分佈式事務

　　四、全局惟一性id，以前哪些只增的id都無論用，水平拆分後的表，多個表之間的id不能使用自增，須要一個惟一全局id。

七、如何設計一個永遠都不須要遷移的方案？