[[311773]]

隨著互聯網應用的廣泛普及，海量數據的存儲和訪問成為了系統設計的瓶頸問題。對于一個大型的互聯網應用，每天幾十億的PV無疑對數據庫造成了相當高的負載。對于系統的穩定性和擴展性造成了極大的問題。通過數據切分來提高網站性能，橫向擴展數據層已經成為架構研發人員首選的方式。

mysql主從復制原理

主要涉及三個線程：binlog 線程、I/O 線程和 SQL 線程。

• binlog 線程 ：負責將主服務器上的數據更改寫入二進制日志(Binary log)中。
• I/O 線程 ：負責從主服務器上讀取二進制日志，并寫入從服務器的中繼日志(Relay log)。
• SQL 線程 ：負責讀取中繼日志，解析出主服務器已經執行的數據更改并在從服務器中重放(Replay)。

這張圖就很清晰表達出流程

1：主庫db的更新事件(update、insert、delete)被寫到binlog

2：從庫發起連接，連接到主庫

3：此時主庫創建一個binlog dump thread線程，把binlog的內容發送到從庫

4：從庫啟動之后，創建一個I/O線程，讀取主庫傳過來的binlog內容并寫入到relay log

5：還會創建一個SQL線程，從relay log里面讀取內容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db.

主從同步復制模式：

讀寫分離：

MYSQL讀寫分離的原理其實就是讓Master數據庫處理事務性增、刪除、修改、更新操作(CREATE、INSERT、UPDATE、DELETE)，而讓Slave數據庫處理SELECT操作，MYSQL讀寫分離前提是基于MYSQL主從復制，這樣可以保證在Master上修改數據，Slave同步之后，WEB應用可以讀取到Slave端的數據。

數據庫分區：

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

• 相對于單個文件系統或是硬盤，分區可以存儲更多的數據;
• 數據管理比較方便，比如要清理或廢棄某年的數據，就可以直接刪除該日期的分區數據即可;
• 精準定位分區查詢數據，不需要全表掃描查詢，大大提高數據檢索效率;
• 可跨多個分區磁盤查詢，來提高查詢的吞吐量;
• 在涉及聚合函數查詢時，可以很容易進行數據的合并;

1、水平分區

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

2、垂直分區

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

什么時候考慮使用分區?

• 一張表的查詢速度已經慢到影響使用的時候。
• sql經過優化
• 數據量大
• 表中的數據是分段的
• 對數據的操作往往只涉及一部分數據，而不是所有的數據

分庫分表：

分庫分表的原因：

1. 隨著單庫中的數據量越來越大，相應的，查詢所需要的時間也越來越多，相當于數據的處理遇到了瓶頸
2. 單庫發生意外的時候，需要修復的是所有的數據，而多庫中的一個庫發生意外的時候，只需要修復一個庫(當然，也可以用物理分區的方式處理這種問題)

什么時候考慮使用分庫?

單臺DB的存儲空間不夠

隨著查詢量的增加單臺數據庫服務器已經沒辦法支撐

分庫解決的問題：

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

垂直拆分

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

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

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

水平拆分

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

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

什么時候考慮分表?

• 一張表的查詢速度已經慢到影響使用的時候。
• sql經過優化
• 數據量大
• 當頻繁插入或者聯合查詢時，速度變慢

分表解決的問題

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

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

垂直分表

水平分表

存儲演變：

單庫單表

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

單庫多表

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

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

多庫多表

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

數據庫額外小知識：

MySQL 使用自增ID主鍵和UUID 作為主鍵的優劣比較詳細過程(從百萬到千萬表記錄測試)

(1)單實例或者單節點組：

經過500W、1000W的單機表測試，自增ID相對UUID來說，自增ID主鍵性能高于UUID，磁盤存儲費用比UUID節省一半的錢。所以在單實例上或者單節點組上，使用自增ID作為首選主鍵。

(2)分布式架構場景：

20個節點組下的小型規模的分布式場景，為了快速實現部署，可以采用多花存儲費用、犧牲部分性能而使用UUID主鍵快速部署;

20到200個節點組的中等規模的分布式場景，可以采用自增ID+步長的較快速方案。

200以上節點組的大數據下的分布式場景，可以借鑒類似twitter雪花算法構造的全局自增ID作為主鍵。