數據庫分區、分表、分庫、分片

一、分區的概念

        數據分區是一種物理數據庫的設計技術，它的目的是為了在特定的SQL操作中減少數據讀寫的總量以縮減響應時間。

        分區並不是生成新的數據表，而是將表的數據均衡分攤到不同的硬盤，系統或是不同服務器存儲介子中，實際上還是一張表。另外，分區可以做到將表的數據均衡到不同的地方，提高數據檢索的效率，降低數據庫的頻繁IO壓力值，分區的優點如下：

1、相對於單個文件系統或是硬盤，分區可以存儲更多的數據；

2、數據管理比較方便，比如要清理或廢棄某年的數據，就可以直接刪除該日期的分區數據即可；

3、精准定位分區查詢數據，不需要全表掃描查詢，大大提高數據檢索效率；

4、可跨多個分區磁盤查詢，來提高查詢的吞吐量；

5、在涉及聚合函數查詢時，可以很容易進行數據的合並；

二、分類 （row 行 ，column 列）

1、水平分區

 

這種形式分區是對表的行進行分區，通過這樣的方式不同分組里面的物理列分割的數據集得以組合，從而進行個體分割（單分區）或集體分割（1個或多個分區）。所有在表中定義的列在每個數據集中都能找到，所以表的特性依然得以保持。

舉個簡單例子：一個包含十年發票記錄的表可以被分區為十個不同的分區，每個分區包含的是其中一年的記錄。（朋奕注：這里具體使用的分區方式我們后面再說，可以先說一點，一定要通過某個屬性列來分割，譬如這里使用的列就是年份）

2、垂直分區

這種分區方式一般來說是通過對表的垂直划分來減少目標表的寬度，使某些特定的列被划分到特定的分區，每個分區都包含了其中的列所對應的行。

舉個簡單例子：一個包含了大text和BLOB列的表，這些text和BLOB列又不經常被訪問，這時候就要把這些不經常使用的text和BLOB了划分到另一個分區，在保證它們數據相關性的同時還能提高訪問速度。

在數據庫供應商開始在他們的數據庫引擎中建立分區（主要是水平分區）時，DBA和建模者必須設計好表的物理分區結構，不要保存冗余的數據（不同表中同時都包含父表中的數據）或相互聯結成一個邏輯父對象（通常是視圖）。這種做法會使水平分區的大部分功能失效，有時候也會對垂直分區產生影響。

三、分區、分表、分庫的詳細理解

一、什么是分區、分表、分庫

分區

就是把一張表的數據分成N個區塊，在邏輯上看最終只是一張表，但底層是由N個物理區塊組成的

分表

就是把一張表按一定的規則分解成N個具有獨立存儲空間的實體表。系統讀寫時需要根據定義好的規則得到對應的字表明，然后操作它。

分庫

一旦分表，一個庫中的表會越來越多

將整個數據庫比作圖書館，一張表就是一本書。當要在一本書中查找某項內容時，如果不分章節，查找的效率將會下降。而同理，在數據庫中就是分區。

二、常用的單機數據庫的瓶頸

問題描述

• 單個表數據量越大，讀寫鎖，插入操作重新建立索引效率越低。
• 單個庫數據量太大（一個數據庫數據量到1T-2T就是極限）
• 單個數據庫服務器壓力過大
• 讀寫速度遇到瓶頸（並發量幾百）

三、分區

什么時候考慮使用分區？

• 一張表的查詢速度已經慢到影響使用的時候。

• sql經過優化

• 數據量大

• 表中的數據是分段的

• 對數據的操作往往只涉及一部分數據，而不是所有的數據

分區解決的問題

主要可以提升查詢效率

分區的實現方式（簡單）

mysql5 開始支持分區功能

1.  
   CREATE TABLE sales (
2.  
   id INT AUTO_INCREMENT,
3.  
   amount DOUBLE NOT NULL,
4.  
   order_day DATETIME NOT NULL,
5.  
   PRIMARY KEY(id, order_day)
6.  
   ) ENGINE=Innodb
7.  
   PARTITION BY RANGE(YEAR(order_day)) (
8.  
   PARTITION p_2010 VALUES LESS THAN (2010),
9.  
   PARTITION p_2011 VALUES LESS THAN (2011),
10.  
    PARTITION p_2012 VALUES LESS THAN (2012),
11.  
    PARTITION p_catchall VALUES LESS THAN MAXVALUE);

四、分表

什么時候考慮分表？

• 一張表的查詢速度已經慢到影響使用的時候。

• sql經過優化

• 數據量大

• 當頻繁插入或者聯合查詢時，速度變慢

分表解決的問題

分表后，單表的並發能力提高了，磁盤I/O性能也提高了，寫操作效率提高了

• 查詢一次的時間短了
• 數據分布在不同的文件，磁盤I/O性能提高
• 讀寫鎖影響的數據量變小
• 插入數據庫需要重新建立索引的數據減少

分表的實現方式（復雜）

需要業務系統配合遷移升級，工作量較大

分區和分表的區別與聯系

• 分區和分表的目的都是減少數據庫的負擔，提高表的增刪改查效率。

• 分區只是一張表中的數據的存儲位置發生改變，分表是將一張表分成多張表。
• 當訪問量大，且表數據比較大時，兩種方式可以互相配合使用。

• 當訪問量不大，但表數據比較多時，可以只進行分區。

常見分區分表的規則策略（類似）

1. Range（范圍）
2. Hash（哈希）
3. 按照時間拆分
4. Hash之后按照分表個數取模
5. 在認證庫中保存數據庫配置，就是建立一個DB，這個DB單獨保存user_id到DB的映射關系

12306的訂單是如何存儲的？

 

五、分庫

什么時候考慮使用分庫？

• 單台DB的存儲空間不夠
• 隨着查詢量的增加單台數據庫服務器已經沒辦法支撐

分庫解決的問題

其主要目的是為突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。 

垂直拆分

將系統中不存在關聯關系或者需要join的表可以放在不同的數據庫不同的服務器中。

按照業務垂直划分。比如：可以按照業務分為資金、會員、訂單三個數據庫。

需要解決的問題：跨數據庫的事務、jion查詢等問題。

水平拆分

例如，大部分的站點。數據都是和用戶有關，那么可以根據用戶，將數據按照用戶水平拆分。

按照規則划分，一般水平分庫是在垂直分庫之后的。比如每天處理的訂單數量是海量的，可以按照一定的規則水平划分。需要解決的問題：數據路由、組裝。

讀寫分離

對於時效性不高的數據，可以通過讀寫分離緩解數據庫壓力。需要解決的問題：在業務上區分哪些業務上是允許一定時間延遲的，以及數據同步問題。

思路

垂直分庫-->水平分庫-->讀寫分離

六、拆分之后面臨新的問題

問題

• 事務的支持，分庫分表，就變成了分布式事務
• join時跨庫，跨表的問題
• 分庫分表，讀寫分離使用了分布式，分布式為了保證強一致性，必然帶來延遲，導致性能降低，系統的復雜度變高。

常用的解決方案：

對於不同的方式之間沒有嚴格的界限，特點不同，側重點不同。需要根據實際情況，結合每種方式的特點來進行處理。

選用第三方的數據庫中間件（Atlas，Mycat，TDDL，DRDS），同時業務系統需要配合數據存儲的升級。

七、數據存儲的演進

單庫單表

單庫單表是最常見的數據庫設計，例如，有一張用戶(user)表放在數據庫db中，所有的用戶都可以在db庫中的user表中查到。

單庫多表

隨着用戶數量的增加，user表的數據量會越來越大，當數據量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。

可以通過某種方式將user進行水平的切分，產生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數據剛好是一份完整的數據。

多庫多表

隨着數據量增加也許單台DB的存儲空間不夠，隨着查詢量的增加單台數據庫服務器已經沒辦法支撐。這個時候可以再對數據庫進行水平拆分。

八、總結

總的來說，優先考慮分區。當分區不能滿足需求時，開始考慮分表，合理的分表對效率的提升會優於分區。

九、案例分析

京東的商品評價存儲設計，原文地址

現狀

• 商品的評論數量：數十億條
• 每天的服務調用：數十億次
• 每年成倍增長

整體的數據存儲：基礎數據存儲，文本存儲

基礎數據存儲

Mysql：只存儲非文本的基礎信息。包括：評論狀態，用戶，時間等基礎數據。以及圖片，標簽，點贊等附加信息。數據組織形式（不同的數據又可選擇不同的庫表拆分方案）：

• 評論基礎數據按用戶ID進行拆庫並拆表
• 圖片及標簽處於同一數據庫下，根據商品編號分別進行拆表
• 其它的擴展信息數據，因數據量不大、訪問量不高，處理於同一庫下且不做分表即可

文本存儲

文本存儲（評論的內容）使用了mongodb、hbase

• 選擇nosql而非mysql
• 減輕了mysql存儲壓力，釋放msyql，龐大的存儲也有了可靠的保障
• nosql的高性能讀寫大大提升了系統的吞吐量並降低了延遲

 

轉自：http://www.cnblogs.com/bluebluesky/articles/6413831.html

作者：bluebluesky

 

也可參考：https://blog.csdn.net/kingcat666/article/details/78324678

里面會有詳細的說明！！我就不轉載了！！

 

數據分片

在分布式存儲系統中，數據需要分散存儲在多台設備上，數據分片（Sharding）就是用來確定數據在多台存儲設備上分布的技術。數據分片要達到三個目的：

1. 分布均勻，即每台設備上的數據量要盡可能相近；
2. 負載均衡，即每台設備上的請求量要盡可能相近；
3. 擴縮容時產生的數據遷移盡可能少。

數據分片方法

數據分片一般都是使用Key或Key的哈希值來計算Key的分布，常見的幾種數據分片的方法如下：

1. 划分號段。這種一般適用於Key為整型的情況，每台設備上存放相同大小的號段區間，如把Key為[1, 10000]的數據放在第一台設備上，把Key為[10001, 20000]的數據放在第二台設備上，依次類推。這種方法實現很簡單，擴容也比較方便，成倍增加設備即可，如原來有N台設備，再新增N台設備來擴容，把每台老設備上一半的數據遷移到新設備上，原來號段為[1, 10000]的設備，擴容后只保留號段[1, 5000]的數據，把號段為[5001, 10000]的數據遷移到一台新增的設備上。此方法的缺點是數據可能分布不均勻，如小號段數據量可能比大號段的數據量要大，同樣的各個號段的熱度也可能不一樣，導致各個設備的負載不均衡；並且擴容也不夠靈活，只能成倍地增加設備。
2. 取模。這種方法先計算Key的哈希值，再對設備數量取模（整型的Key也可直接用Key取模），假設有N台設備，編號為0~N-1，通過Hash(Key)%N就可以確定數據所在的設備編號。這種方法實現也非常簡單，數據分布和負載也會比較均勻，可以新增任何數量的設備來擴容。主要的問題是擴容的時候，會產生大量的數據遷移，比如從N台設備擴容到N+1台，絕大部分的數據都要在設備間進行遷移。
3. 檢索表。在檢索表中存儲Key和設備的映射關系，通過查找檢索表就可以確定數據分布，這里的檢索表也可以比較靈活，可以對每個Key都存儲映射關系，也可結合號段划分等方法來減小檢索表的容量。這樣可以做到數據均勻分布、負載均衡和擴縮容數據遷移量少。缺點是需要存儲檢索表的空間可能比較大，並且為了保證擴縮容引起的數據遷移量比較少，確定映射關系的算法也比較復雜。
4. 一致性哈希。一致性哈希算法（Consistent Hashing）在1997年由麻省理工學院提出的一種分布式哈希（DHT）實現算法，設計目標是為了解決因特網中的熱點(Hot Spot)問題，該方法的詳細介紹參考此處 http://blog.csdn.net/sparkliang/article/details/5279393。一致性哈希的算法簡單而巧妙，很容易做到數據均分布，其單調性也保證了擴縮容的數據遷移是比較少的。

通過上面的對比，在這個系統選擇一致性哈希的方法來進行數據分片。

虛擬服務器

為了讓系統有更好的擴展性，這里提出存儲層VServer（虛擬服務器）的概念，一個VServer是一個邏輯上的存儲服務器，是分布式存儲系統的一個存儲單元，一台物理設備上可以部署多個VServer，一個VServer支持一個寫進程和多個讀進程。

通過VServer的方式，會有下面一些好處：

1. 提高單機性能。為了不引入復雜的鎖機制，采用了單寫進程的設計，如果單機只有一個寫進程，寫並發能力會受到限制，通過VServer方式把單機上的存儲資源（內存、硬盤）划分為多個存儲單元，這樣就支持多個寫進程同時工作，大大提升單機寫並發能力。
2. 部署擴展性更好。VServer的方式在部署上非常靈活，可以根據單機的資源情況來確定VServer的數量，針對不同的機型配置不同的VServer數量，這樣不同的機型都能充分利用機器上的資源，即使在一個系統中使用多種機型，也能做到機器的負載比較均衡。

一致性哈希的應用

數據分片是在接口層實現的，目的是把數據均勻地划分到不同的VServer上。有了接口層的存在，邏輯層尋址就輕量了很多，尋址存儲層VServer的工作全部由接口層負責，邏輯層只需要隨機選一個接口層機器訪問即可。

接口層使用了一致性哈希的割環算法來實現數據分片，在割環算法中，為了讓數據均勻分布到各個VServer，每個VServer需要有多個VNode（虛擬節點）。一個Key尋址的過程如下圖所示，首先根據Hash(Key)在哈希環上找到對應的VNode，在根據VNode和VServer的映射表確定所屬的VServer。

由上述查找過程可知，需要事先離線計算出VNode在哈希環上的分布、VServer和VNode映射關系。為了是計算結果具有通用性，即在擁有任何數量VServer的一個系統都可以使用該結果得到一致性哈希的映射表，這就要求結果是與機器無關的，比如不能使用IP來計算VNode的哈希值。在計算前需要確定每個VServer包含的VNode數量，以及一個系統所支持的最大VServer數量。一個簡單的方法是類似上文鏈接中提到的方法，但不能和IP相關，可以改用VServer和VNode的編號來計算哈希值，如Hash("1#1")，Hash("1#2")… 這種方法要求一個VServer包含的VNode的數量比較多，大概需要500個才能使各個VServer上的數據比較均勻。當然還有其他的一些方法做到一個VServer上包含更少的VNode數量，並且讓數據分布偏差在一定范圍內。

Google提出了一種新的一致性哈希算法Jump Consistent Hash，此算法零內存消耗，均勻分配，快速，並且只有5行代碼，優勢非常明顯，詳細介紹見此處http://my.oschina.net/u/658658/blog/424161。和上面介紹的方法相比，一個最大的不同點是，在擴容重新分布數據時，在上面的方法中，新機器的一個VNode上的數據只會來自一個老機器上的VNode，而這種方法是會來自所有老機器上的VNode。這個問題可能會導致一些設計上復雜化，所以使用的時候要慎重考慮。

 

轉：http://www.cnblogs.com/Leo_wl/p/5654789.html

 

分片模式是什么？

 

數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。

（1）一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切分可以稱之為數據的垂直（縱向）切分 

（2）另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多台數據庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。

分片相關的概念

邏輯庫(schema) ：

通常對實際應用來說，並不需要知道中間件的存在，業務開發人員只需要知道數據庫的概念，所以數據庫中間件可以被看做是一個或多個數據庫集群構成的邏輯庫。

• 邏輯表（table）：

既然有邏輯庫，那么就會有邏輯表，分布式數據庫中，對應用來說，讀寫數據的表就是邏輯表。邏輯表，可以是數據切分后，分布在一個或多個分片庫中，也可以不做數據切分，不分片，只有一個表構成。

• 分片表：

是指那些原有的很大數據的表，需要切分到多個數據庫的表，這樣，每個分片都有一部分數據，所有分片構成了完整的數據。 總而言之就是需要進行分片的表。

• 非分片表：

一個數據庫中並不是所有的表都很大，某些表是可以不用進行切分的，非分片是相對分片表來說的，就是那些不需要進行數據切分的表。

• 分片節點(dataNode)

數據切分后，一個大表被分到不同的分片數據庫上面，每個表分片所在的數據庫就是分片節點（dataNode）。

• 節點主機(dataHost)

數據切分后，每個分片節點（dataNode）不一定都會獨占一台機器，同一機器上面可以有多個分片數據庫，這樣一個或多個分片節點（dataNode）所在的機器就是節點主機（dataHost）,為了規避單節點主機並發數限制，盡量將讀寫壓力高的分片節點（dataNode）均衡的放在不同的節點主機（dataHost）。

• 分片規則(rule)

前面講了數據切分，一個大表被分成若干個分片表，就需要一定的規則，這樣按照某種業務規則把數據分到某個分片的規則就是分片規則，數據切分選擇合適的分片規則非常重要，將極大的避免后續數據處理的難度。

 

轉：https://blog.csdn.net/weixin_38074050/article/details/78640004