架構之數據庫分表分庫

時間 2019-12-09

原文原文鏈接

1 基本思想之什麼是分庫分表？
從字面上簡單理解，就是把本來存儲於一個庫的數據分塊存儲到多個庫上，把本來存儲於一個表的數據分塊存儲到多個表上。
2 基本思想之爲何要分庫分表？

數據庫中的數據量不必定是可控的，在未進行分庫分表的狀況下，隨着時間和業務的發展，庫中的表會愈來愈多，表中的數據量也會愈來愈大，相應地，數據操做，增刪改查的開銷也會愈來愈大；另外，因爲沒法進行分佈式式部署，而一臺服務器的資源（CPU、磁盤、內存、IO等）是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。

分庫分表有垂直切分和水平切分兩種。
3.1 何謂垂直切分，即將表按照功能模塊、關係密切程度劃分出來，部署到不一樣的庫上。例如，咱們會創建定義數據庫workDB、商品數據庫payDB、用戶數據庫userDB、日誌數據庫logDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表、日誌數據表等。
3.2 何謂水平切分，當一個表中的數據量過大時，咱們能夠把該表的數據按照某種規則，例如userID散列，進行劃分，而後存儲到多個結構相同的表，和不一樣的庫上。例如，咱們的userDB中的用戶數據表中，每個表的數據量都很大，就能夠把userDB切分爲結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分爲不少userTable：userTable0、userTable1等，而後將這些表按照必定的規則存儲到多個userDB上。
3.3 應該使用哪種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
若是數據庫是由於表太多而形成海量數據，而且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明瞭、容易實施的垂直切分必是首選。
而若是數據庫中的表並很少，但單表的數據量很大、或數據熱度很高，這種狀況之下就應該選擇水平切分，水平切分比垂直切分要複雜一些，它將本來邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度作好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
在現實項目中，每每是這兩種狀況兼而有之，這就須要作出權衡，甚至既須要垂直切分，又須要水平切分。咱們的遊戲項目便綜合使用了垂直與水平切分，咱們首先對數據庫進行垂直切分，而後，再針對一部分表，一般是用戶數據表，進行水平切分。
4 分庫分表存在的問題。

4.1 事務問題。
在執行分庫分表以後，因爲數據存儲到了不一樣的庫上，數據庫事務管理出現了困難。若是依賴數據庫自己的分佈式事務管理功能去執行事務，將付出高昂的性能代價；若是由應用程序去協助控制，造成程序邏輯上的事務，又會形成編程方面的負擔。
4.2 跨庫跨表的join問題。
在執行了分庫分表以後，難以免會將本來邏輯關聯性很強的數據劃分到不一樣的表、不一樣的庫上，這時，表的關聯操做將受到限制，咱們沒法join位於不一樣分庫的表，也沒法join分表粒度不一樣的表，結果本來一次查詢可以完成的業務，可能須要屢次查詢才能完成。
4.3 額外的數據管理負擔和數據運算壓力。
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重複執行問題，這些均可以經過應用程序解決，但必然引發額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表以前，只需一個order by語句就能夠搞定，可是在進行分表以後，將須要n個order by語句，分別查出每個分表的前100名用戶數據，而後再對這些數據進行合併計算，才能得出結果。