資料庫分庫分表--前奏篇
- 2020 年 2 月 24 日
- 筆記
資料庫和表的演變
單庫單表
項目前期基本都是單庫單表，單庫單表也是最常見的資料庫設計，比如說：有一張用戶表User，被放到資料庫中，所有的用戶的資訊都被存儲在該資料庫的這張User表裡。
單庫多表
隨著用戶量的增加，User表的數據越來越多，一旦當數據量達到一定量的時候，對User表的查詢會變得越來越慢，從而漸漸的影響整個數據的性能。有時候可能涉及到需要對User表添加一列，如果Mysql版本較低的話，這時候Mysql會鎖表，會導致所有的讀寫操作只能等待添加操作完畢。
這時候可以通過某種機制或者規則將表裡的數據進行拆分。比如說：user_id是0到10000的放到User_01表裡，將user_id是10001到20000的用戶資訊放到User_02表裡,......。這些表組合起來就是一個系統完整用戶資訊。
多庫多表
隨著用戶數據量的不斷增加，單台資料庫的存儲空間也許就不夠用了，並且隨著查詢量的不斷增加，單台資料庫的服務已經沒法支撐這些查詢了，因為表的數據量太大，所以在增加和減少索引時需要消耗很長時間。這時候可以針對User_01，User_02，....User_10放到一個資料庫里，User_11，User_12，...User_20放到一個資料庫里.....這樣就之前的一個資料庫，拆分成了n多個資料庫。這時候表和資料庫就從單表單庫到了多表多庫了。
何為分開分表
由於用戶數據量不斷的增加，我們怎樣存儲這些數據呢？要怎樣才能讓系統不會因此而受到影響呢?
目前，數據拆分是這兩個問題的主流解決方案。最終目的就是講用戶數據進行分而治之，在資料庫存儲方面是通過對資料庫和表進行分庫分表來實現，對數據的拆分主要有兩種手段：垂直拆分和水平拆分
垂直拆分
根據業務的維度，將原本的一個庫或者表拆分成多個庫或者表，每個庫或者表的結構和原來的結構有所不同。
比如說：之前的資料庫里除了用戶的資訊表User以外，可能還有交易表等。而現在按照垂直拆分後，用戶資訊放在一個庫，交易資訊放一個庫。
水平拆分
根據分片演算法，將一個數據或者表拆分成多個庫或者多個表，每個庫和表保留著原來的結構。
比如說：一個庫拆分成多個庫後，每個庫里也是有用戶的資訊表、交易表的結構都是一樣的，只是數據存的不一樣了。
上面的兩種拆分方法可能也會在一個系統里同時存在，在互聯網應用的開發過程中，通常先進行垂直拆分，是單體應用變成多個微服務結構，在微服務中在進行水平拆分庫或者表。
在什麼情況下需要咱們進行分庫分表呢
首先，如果在一個庫中的表數據超過了一定的數量，可以理解為閾值。比如說：在Mysql的表中達到千萬級別數據就需要考慮分庫分表（這個千萬也是相對的，和你的表設計還是有些關係的），這樣，數據就被分散在不同的表上，單表的索引大小得到控制，會提升查詢性能的，對索引以及表結構的變更會更加方便和高效的。當資料庫實例的吞吐量達到性能瓶頸的時候，我們需要擴展資料庫實例，讓每個資料庫實例承擔其中一部分資料庫的請求，分解大量請求帶來的整體壓力。
現在，大多數資料庫實例都可以創建多個資料庫，那麼為什麼在分庫分表中要創建多資料庫呢？因為如果擴容時候有多個資料庫，則只要通過DBA的操作，就可以將不同的資料庫移動到不同的資料庫實例中，在應用層不用對數據和表的配置進行變更，只需要增加對實例的引用。
下面總結一下在什麼情況下需要分庫分表？
- 如果在資料庫中的表中的數據量達到一定程度或者是閾值，則需要進行分庫分表，分解單表的大數據量對索引查詢帶來的壓力，並方便對索引和表結構進行變更。
- 如果資料庫的吞吐量達到瓶頸了，就需要增加資料庫實例，利用多個資料庫實例來分解大量的數據請求帶來的系統壓力。
- 如果希望在擴容時候對應用層的配置改變最少，就需要在每個數據實例中預留足夠的資料庫數量。
