從字面上簡單理解,就是將本來存儲在一個庫的數據分塊存儲在多個庫上,將本來存儲在一個表的數據分塊存儲在多個表裏面。前端
數據的切分根據其切分規則的類型,能夠分爲以下兩種切分模式。數據庫
這樣操做的優勢:設計模式
拆分後業務清晰,拆分規則明確。
系統之間進行整合或擴展很容易。
按照成本、應用的等級、應用的類型等將表放到不一樣的機器上,便於管理。
便於實現動靜分離、冷熱分離的數據庫表的設計模式。
數據維護簡單。
複製代碼
缺點:性能
業務表多樣,SQL語句複雜。
複製代碼
水平(橫向)切分:根據表中數據的邏輯關係,將同一個表中的數據按照某種條件拆分到多臺數據庫(主機)上。與垂直切分對比,水平切分不是將表進行分類,而是將其按照某個字段的某種規則分散到多個庫中,在每一個表中包含一部分數據,全部表加起來就是全量的數據。學習
好比有一個用戶表,單張表的記錄條數達到1億條,這樣在進行查詢,插入,更新操做的時候,速度將很是慢,那咱們能夠將這些數據分配到100個表裏面,每一個表的數據量就下來了,致使單表的容量不會太大,從而保證了單表的查詢等處理能力。spa
咱們一般將數據分配的原則稱爲分片規則,常見的分片規則有對用戶的id取模。設計
注意:必定要好好決定分片規則,儘可能選擇不會變更的字段,若是選擇區域,性別,年齡等字段,當用戶修改這些信息的時候又要講數據移動到其餘數據庫,這裏面的邏輯也很頭疼。3d
這樣操做水平的優勢以下:code
單庫單表的數據保持在必定的量級,有助於性能的提升。
切分的表的結構相同,應用層改造較少,只須要增長路由規則便可。
提升了系統的穩定性和負載能力。
複製代碼
缺點以下:cdn
切分後,數據是分散的,很難利用數據庫的Join操做,跨庫Join性能較差。
拆分規則難以抽象。
分片事務的一致性難以解決。
數據擴容的難度和維護量極大。
複製代碼
數據庫負載增大時的處理:隨着咱們的應用的用戶量愈來愈大,訪問量也隨之提高,當他們提高到必定的量級以後,應用也就愈來愈慢。固然咱們能夠經過增大前端應用負載的方式來提高速度,可是直到有一天咱們發現不管如何增大前端應用負載都不能提高速度,咱們就逐步找到緣由,是數據庫的問題。由於數據庫是存在性能瓶頸的,這是沒法避免的。
MyCat:是一箇中間件的第三方應用,使用mycat時不須要改代碼。 咱們在使用的時候,若是有多個庫,咱們在代碼裏面就只要寫mycat對外的一個邏輯庫信息就行,而數據庫層面的配置,好比總共有多少個庫,每一個庫裏面的表,每一個表的分片規則,這些都是在mycat裏面配置,不須要修改代碼信息。 具體的邏輯圖以下:
Sharding JDBC:是一個jar包,使用sharding-jdbc時須要修改代碼。 咱們在使用的時候,須要引入sharding jdbc的jar包,在配置文件裏面寫明總共有多少個庫,每一個庫裏面的表,每一個表的分片規則等信息。
具體的邏輯圖以下:
如何選擇中間件?
sharding-jdbc和mycat使用不一樣的理念,sharding-jdbc目前是基於jdbc驅動,無需額外的proxy,所以也無需關注proxy自己的高可用。Mycat 是基於 Proxy,它複寫了 MySQL 協議,將 Mycat Server 假裝成一個 MySQL 數據庫,而 Sharding-JDBC 是基於 JDBC 接口的擴展,是以 jar 包的形式提供輕量級服務的。
其實MyCAT很適合中小企業使用的。能夠很是容易的實現數據庫的讀寫分離和分庫分表,反而對於大企業來講,都會本身開發適合本身的數據庫中間層應用,好比sharding jdbc原來就是噹噹網內部的數據庫中間件,後來開源出來的。