數(shù)據庫主從復制，讀寫分離，分庫分表，分區(qū)講解
隨著互聯(lián)網應用的廣泛普及，海量數(shù)據的存儲和訪問成為了系統(tǒng)設計的瓶頸問題。對于一個大型的互聯(lián)網應用，每天幾十億的PV無疑對數(shù)據庫造成了相當高的負載。對于系統(tǒng)的穩(wěn)定性和擴展性造成了極大的問題。通過數(shù)據切分來提高網站性能，橫向擴展數(shù)據層已經成為架構研發(fā)人員首選的方式。
mysql主從復制原理
主要涉及三個線程：binlog 線程、I/O 線程和 SQL 線程。
- binlog 線程 ：負責將主服務器上的數(shù)據更改寫入二進制日志(Binary log)中。
- I/O 線程 ：負責從主服務器上讀取二進制日志，并寫入從服務器的中繼日志(Relay log)。
- SQL 線程 ：負責讀取中繼日志，解析出主服務器已經執(zhí)行的數(shù)據更改并在從服務器中重放(Replay)。
這張圖就很清晰表達出流程
1：主庫db的更新事件(update、insert、delete)被寫到binlog
2：從庫發(fā)起連接，連接到主庫
3：此時主庫創(chuàng)建一個binlog dump thread線程，把binlog的內容發(fā)送到從庫
4：從庫啟動之后，創(chuàng)建一個I/O線程，讀取主庫傳過來的binlog內容并寫入到relay log
5：還會創(chuàng)建一個SQL線程，從relay log里面讀取內容，從Exec_Master_Log_Pos位置開始執(zhí)行讀取到的更新事件，將更新內容寫入到slave的db.
主從同步復制模式：
讀寫分離：
MYSQL讀寫分離的原理其實就是讓Master數(shù)據庫處理事務性增、刪除、修改、更新操作(CREATE、INSERT、UPDATE、DELETE)，而讓Slave數(shù)據庫處理SELECT操作，MYSQL讀寫分離前提是基于MYSQL主從復制，這樣可以保證在Master上修改數(shù)據，Slave同步之后，WEB應用可以讀取到Slave端的數(shù)據。
數(shù)據庫分區(qū)：
分區(qū)并不是生成新的數(shù)據表，而是將表的數(shù)據均衡分攤到不同的硬盤，系統(tǒng)或是不同服務器存儲介子中，實際上還是一張表。另外，分區(qū)可以做到將表的數(shù)據均衡到不同的地方，提高數(shù)據檢索的效率，降低數(shù)據庫的頻繁IO壓力值，分區(qū)的優(yōu)點如下：
- 相對于單個文件系統(tǒng)或是硬盤，分區(qū)可以存儲更多的數(shù)據;
- 數(shù)據管理比較方便，比如要清理或廢棄某年的數(shù)據，就可以直接刪除該日期的分區(qū)數(shù)據即可;
- 精準定位分區(qū)查詢數(shù)據，不需要全表掃描查詢，大大提高數(shù)據檢索效率;
- 可跨多個分區(qū)磁盤查詢，來提高查詢的吞吐量;
- 在涉及聚合函數(shù)查詢時，可以很容易進行數(shù)據的合并;
1、水平分區(qū)
這種形式分區(qū)是對表的行進行分區(qū)，通過這樣的方式不同分組里面的物理列分割的數(shù)據集得以組合，從而進行個體分割(單分區(qū))或集體分割(1個或多個分區(qū))。所有在表中定義的列在每個數(shù)據集中都能找到，所以表的特性依然得以保持。
2、垂直分區(qū)
這種分區(qū)方式一般來說是通過對表的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分區(qū)，每個分區(qū)都包含了其中的列所對應的行。
什么時候考慮使用分區(qū)?
- 一張表的查詢速度已經慢到影響使用的時候。
- sql經過優(yōu)化
- 數(shù)據量大
- 表中的數(shù)據是分段的
- 對數(shù)據的操作往往只涉及一部分數(shù)據，而不是所有的數(shù)據
分庫分表：
分庫分表的原因：
- 隨著單庫中的數(shù)據量越來越大，相應的，查詢所需要的時間也越來越多，相當于數(shù)據的處理遇到了瓶頸
- 單庫發(fā)生意外的時候，需要修復的是所有的數(shù)據，而多庫中的一個庫發(fā)生意外的時候，只需要修復一個庫(當然，也可以用物理分區(qū)的方式處理這種問題)
什么時候考慮使用分庫?
單臺DB的存儲空間不夠
隨著查詢量的增加單臺數(shù)據庫服務器已經沒辦法支撐
分庫解決的問題：
其主要目的是為突破單節(jié)點數(shù)據庫服務器的 I/O 能力限制，解決數(shù)據庫擴展性問題。
垂直拆分
將系統(tǒng)中不存在關聯(lián)關系或者需要join的表可以放在不同的數(shù)據庫不同的服務器中。
按照業(yè)務垂直劃分。比如：可以按照業(yè)務分為資金、會員、訂單三個數(shù)據庫。
需要解決的問題：跨數(shù)據庫的事務、jion查詢等問題。
水平拆分
例如，大部分的站點。數(shù)據都是和用戶有關，那么可以根據用戶，將數(shù)據按照用戶水平拆分。
按照規(guī)則劃分，一般水平分庫是在垂直分庫之后的。比如每天處理的訂單數(shù)量是海量的，可以按照一定的規(guī)則水平劃分。需要解決的問題：數(shù)據路由、組裝。
什么時候考慮分表?
- 一張表的查詢速度已經慢到影響使用的時候。
- sql經過優(yōu)化
- 數(shù)據量大
- 當頻繁插入或者聯(lián)合查詢時，速度變慢
分表解決的問題
分表后，單表的并發(fā)能力提高了，磁盤I/O性能也提高了，寫操作效率提高了
- 查詢一次的時間短了
- 數(shù)據分布在不同的文件，磁盤I/O性能提高
- 讀寫鎖影響的數(shù)據量變小
- 插入數(shù)據庫需要重新建立索引的數(shù)據減少
垂直分表
水平分表
存儲演變：
單庫單表
單庫單表是最常見的數(shù)據庫設計，例如，有一張用戶(user)表放在數(shù)據庫db中，所有的用戶都可以在db庫中的user表中查到。
單庫多表
隨著用戶數(shù)量的增加，user表的數(shù)據量會越來越大，當數(shù)據量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。
可以通過某種方式將user進行水平的切分，產生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數(shù)據剛好是一份完整的數(shù)據。
多庫多表
隨著數(shù)據量增加也許單臺DB的存儲空間不夠，隨著查詢量的增加單臺數(shù)據庫服務器已經沒辦法支撐。這個時候可以再對數(shù)據庫進行水平拆分。
數(shù)據庫額外小知識：
MySQL 使用自增ID主鍵和UUID 作為主鍵的優(yōu)劣比較詳細過程(從百萬到千萬表記錄測試)
(1)單實例或者單節(jié)點組：
經過500W、1000W的單機表測試，自增ID相對UUID來說，自增ID主鍵性能高于UUID，磁盤存儲費用比UUID節(jié)省一半的錢。所以在單實例上或者單節(jié)點組上，使用自增ID作為首選主鍵。
(2)分布式架構場景：
20個節(jié)點組下的小型規(guī)模的分布式場景，為了快速實現(xiàn)部署，可以采用多花存儲費用、犧牲部分性能而使用UUID主鍵快速部署;
20到200個節(jié)點組的中等規(guī)模的分布式場景，可以采用自增ID+步長的較快速方案。
200以上節(jié)點組的大數(shù)據下的分布式場景，可以借鑒類似twitter雪花算法構造的全局自增ID作為主鍵。
