開源數(shù)據(jù)庫架構設計原則

01. 技術選型

選擇成熟的平臺和技術，同時是最熟悉的，能做到極致的，用好不用壞，用熟不用生。目前業(yè)界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。

02. 高可用選擇

高可用解決方案探討的本質上是低宕機時間解決方案，可以理解成高可用的反面是不可用，絕大部分情況下數(shù)據(jù)庫宕機才會導致數(shù)據(jù)庫不可用。隨著技術發(fā)展，開源數(shù)據(jù)庫方面很多高可用組件（主從復制、半同步、MGR、MHA、Galera Cluster）,對應場景，只有適合的，沒有萬能的，需要理解每個高可用優(yōu)缺點。

03. 表設計

表設計方面目前一致堅持和提倡的原則：

• 單表數(shù)據(jù)量
  

所有表都需要添加注釋，單表數(shù)據(jù)量建議控制在 3000 萬以內

• 不保存大字段數(shù)據(jù)
  

不在數(shù)據(jù)庫中存儲圖片、文件等大數(shù)據(jù)

• 表使用規(guī)范

拆分大字段和訪問頻率低的字段，分離冷熱數(shù)據(jù)

單表字段數(shù)控制在 20 個以內

• 索引規(guī)范
  

1.單張表中索引數(shù)量不超過 5 個

2.單個索引中的字段數(shù)不超過 5 個

3.INNODB 主鍵推薦使用自增列，主鍵不應該被修改，字符串不應該做主鍵，

如果不指定主鍵，INNODB 會使用唯一且非空值索引代替

4.如果是復合索引，區(qū)分最大的字段放在索引前面

5. 避免冗余或重復索引：合理創(chuàng)建聯(lián)合索引（避免冗余）

6. 不在低基數(shù)列上建立索引，例如‘性別'

7. 不在索引列進行數(shù)學運算和函數(shù)運算

• 字符集utf8mb4(偏生字，表情符)
  

04. 優(yōu)化原則

05. 復制方式

MySQL復制方式提供異步方式、半同步方式、全局事務強一致性、binglog同步。需要不同業(yè)務系統(tǒng)間 或 兩個數(shù)據(jù)庫間進行同步。異步方式可以防止故障和效率問題的蔓延，擴大化；但強一致性會更復雜，并發(fā)、事務大小都有求限制。

06. 分離原則

區(qū)分核心的業(yè)務，重要業(yè)務，渠道，內部業(yè)務的業(yè)務系統(tǒng)，對不同的系統(tǒng)設置不同的架構。為核心業(yè)務設置 最佳為分庫，多活 專用高速公路，其他業(yè)務可以做讀寫分離，緩存。

07. 擴展性

對于系統(tǒng)來說擴展性很重要，盡量做到水平擴展。避免過度依賴縱向擴展，同時具備縱向，橫向擴展的能力，例如無狀態(tài)應用應該多套負載均衡多活部署，數(shù)據(jù)庫分庫架構。

08. 讀寫分離

• 讀多寫少場景（10%寫 90%讀）
• 復制存在延遲，業(yè)務對延遲不敏感的
• 實現(xiàn)方式：

1. 通過應用代碼配置讀寫分離，

2. 通過中間代理方式路由只讀庫 &

3. 業(yè)務和數(shù)據(jù)庫為一個單位

09. 分庫分表

• 當表中數(shù)據(jù)記錄的數(shù)量超過3000萬條，再好的索引也已經(jīng)不能提高數(shù)據(jù)查詢的速度，這時需要將表拆分成更多的小表，增加性能，增加彈性，避免發(fā)生垮庫進行操作。
• 引入中間價要考慮性能代價,聚合需求。
• 分庫原則盡量在app 上層進行分庫，就是流量。
• 分多少合適：可用性和性能滿足TPS。
• 路由：寫入配置文件 或則 插表 或則 zookeeper。
  

10. 歸檔原則

歷史數(shù)據(jù)定期進行歸檔 或則 移到其他大數(shù)據(jù)平臺。能讓輕量級數(shù)據(jù)庫更多緩存有用的數(shù)據(jù)。

在MySQL分區(qū)表里 注意要避免分區(qū)鎖，只能寫讀的場景。

11. 連接池的要求

長鏈接，自動重鏈，延時和異常記錄， 彈性鏈接，檢測滿，異常告警，進階要求

是記錄所有訪問情況，可以擴展出很多能力。

應用和數(shù)據(jù)庫連接池設置，數(shù)據(jù)庫允許的連接數(shù)設置，常見問題。

A ）應用的數(shù)據(jù)庫連接池設置偏小，一旦數(shù)據(jù)庫相應慢（新上線應用，缺少索引 等）則應。

用排隊嚴重，甚至雪崩，而遺憾的是數(shù)據(jù)庫能力還遠為用盡。

B ）不具備失效及時發(fā)現(xiàn)和重新鏈接數(shù)據(jù)庫能力。

C ）隔離級別設置：RR 和 RC下不同的表現(xiàn)。

12. 應用解耦

通過應用訪問數(shù)據(jù)庫而不是直接訪問，重要業(yè)務不能依賴低保障級別的系統(tǒng)，應用層重要業(yè)務和普通業(yè)務解耦，關鍵業(yè)務要獨立。

13. 組件失效免疫能力

單一應用，單一硬件，甚至單一基礎設施，單一站點容災，業(yè)務影響，故障恢復能力，要季度級別進行演練。

14. 關鍵詞組件減負

特別是數(shù)據(jù)庫訪問,數(shù)據(jù)庫成本最高，擴展性最難，可用性保障最難，恢復難度和時間最大。

減負：能不用就不用，使用最簡單，成本最低的語句，避免大事務，慎用兩階段事務。

15. 灰度數(shù)據(jù)庫

減少發(fā)布時變更數(shù)據(jù)庫對全局的影響,只有應用程序灰度是不夠的，還要有專門的灰度數(shù)據(jù)庫。在分庫、讀寫分離架構下，一套含數(shù)據(jù)庫的完整應用架構，變的很自然。

所為灰度環(huán)境就是生產環(huán)境，生產數(shù)據(jù)，所影響的也是生產環(huán)境，只是范圍比測試環(huán)境更廣，更真實。其實就是小范圍的生產環(huán)境。類似于游戲內測。

16. 高仿真架構體系

建立高仿真架構體系

• 數(shù)據(jù)庫，操作系統(tǒng)升級：應用是否適應，性能會變好， 還是變壞
• 應用上線發(fā)布，系統(tǒng)變更（列如換平臺），提前判斷業(yè)務影響和性能瓶頸
• 應對突發(fā)交易量，例如雙十一，性能極限在哪里，瓶頸在哪里。
  

17. 容災保障

高可用是運維核心要求，容災是最后屏障

例如 雙活比單活好，MGR比復制架構好，重要系統(tǒng)要做好高可用，容災建設。

18. 多中心建設

冗余是基礎，多中心建設是為了提升容災能力和擴展能力，并保障業(yè)務。

19. 應用和數(shù)據(jù)庫是一個整體

應用和運維人員一起，解決應用解耦，數(shù)據(jù)庫解耦，追賬補數(shù)，業(yè)務監(jiān)控，應用路由，故障切換等?？捎眯?，效率，故障恢復等方面都要一起參與。

20. 性能提升

開源數(shù)據(jù)庫使用應該合理且有效的結合周邊的其他類型數(shù)據(jù)庫，做到性能最大化。比如：Redis、MongoDB、ES、ClickHouse等。

總結

1. 最適合的架構是結合軟件特性和業(yè)務場景，又能取得成本收益平衡；

2. 大數(shù)據(jù)情況下可以是利用讀寫分離、分庫分表，但要選擇合適的；

3. 不適合分庫的應該考慮竭盡所能把核心庫做小，然后通過垂直擴展來擴容；

4. 用盡各種技術， 高可用 和 容災手段保證其可用。

以上就是MySQL20個高性能架構設計原則（值得收藏）的詳細內容，更多關于MySQL 架構設計的資料請關注腳本之家其它相關文章！

最新評論