開源數(shù)據(jù)庫架構(gòu)設(shè)計原則
01. 技術(shù)選型
選擇成熟的平臺和技術(shù),同時是最熟悉的,能做到極致的,用好不用壞,用熟不用生。目前業(yè)界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。
02. 高可用選擇
高可用解決方案探討的本質(zhì)上是低宕機時間解決方案,可以理解成高可用的反面是不可用,絕大部分情況下數(shù)據(jù)庫宕機才會導致數(shù)據(jù)庫不可用。隨著技術(shù)發(fā)展,開源數(shù)據(jù)庫方面很多高可用組件(主從復制、半同步、MGR、MHA、Galera Cluster),對應場景,只有適合的,沒有萬能的,需要理解每個高可用優(yōu)缺點。
03. 表設(shè)計
表設(shè)計方面目前一致堅持和提倡的原則:
所有表都需要添加注釋,單表數(shù)據(jù)量建議控制在 3000 萬以內(nèi)
不在數(shù)據(jù)庫中存儲圖片、文件等大數(shù)據(jù)
拆分大字段和訪問頻率低的字段,分離冷熱數(shù)據(jù)
單表字段數(shù)控制在 20 個以內(nèi)
1.單張表中索引數(shù)量不超過 5 個
2.單個索引中的字段數(shù)不超過 5 個
3.INNODB 主鍵推薦使用自增列,主鍵不應該被修改,字符串不應該做主鍵,
如果不指定主鍵,INNODB 會使用唯一且非空值索引代替
4.如果是復合索引,區(qū)分最大的字段放在索引前面
5. 避免冗余或重復索引:合理創(chuàng)建聯(lián)合索引(避免冗余)
6. 不在低基數(shù)列上建立索引,例如‘性別'
7. 不在索引列進行數(shù)學運算和函數(shù)運算
04. 優(yōu)化原則
05. 復制方式
MySQL復制方式提供異步方式、半同步方式、全局事務強一致性、binglog同步。需要不同業(yè)務系統(tǒng)間 或 兩個數(shù)據(jù)庫間進行同步。異步方式可以防止故障和效率問題的蔓延,擴大化;但強一致性會更復雜,并發(fā)、事務大小都有求限制。
06. 分離原則
區(qū)分核心的業(yè)務,重要業(yè)務,渠道,內(nèi)部業(yè)務的業(yè)務系統(tǒng),對不同的系統(tǒng)設(shè)置不同的架構(gòu)。為核心業(yè)務設(shè)置 最佳為分庫,多活 專用高速公路,其他業(yè)務可以做讀寫分離,緩存。
07. 擴展性
對于系統(tǒng)來說擴展性很重要,盡量做到水平擴展。避免過度依賴縱向擴展,同時具備縱向,橫向擴展的能力,例如無狀態(tài)應用應該多套負載均衡多活部署,數(shù)據(jù)庫分庫架構(gòu)。
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è)置,數(shù)據(jù)庫允許的連接數(shù)設(shè)置,常見問題。
A )應用的數(shù)據(jù)庫連接池設(shè)置偏小,一旦數(shù)據(jù)庫相應慢(新上線應用,缺少索引 等)則應。
用排隊嚴重,甚至雪崩,而遺憾的是數(shù)據(jù)庫能力還遠為用盡。
B )不具備失效及時發(fā)現(xiàn)和重新鏈接數(shù)據(jù)庫能力。
C )隔離級別設(shè)置:RR 和 RC下不同的表現(xiàn)。
12. 應用解耦
通過應用訪問數(shù)據(jù)庫而不是直接訪問,重要業(yè)務不能依賴低保障級別的系統(tǒng),應用層重要業(yè)務和普通業(yè)務解耦,關(guān)鍵業(yè)務要獨立。
13. 組件失效免疫能力
單一應用,單一硬件,甚至單一基礎(chǔ)設(shè)施,單一站點容災,業(yè)務影響,故障恢復能力,要季度級別進行演練。
14. 關(guān)鍵詞組件減負
特別是數(shù)據(jù)庫訪問,數(shù)據(jù)庫成本最高,擴展性最難,可用性保障最難,恢復難度和時間最大。
減負:能不用就不用,使用最簡單,成本最低的語句,避免大事務,慎用兩階段事務。
15. 灰度數(shù)據(jù)庫
減少發(fā)布時變更數(shù)據(jù)庫對全局的影響,只有應用程序灰度是不夠的,還要有專門的灰度數(shù)據(jù)庫。在分庫、讀寫分離架構(gòu)下,一套含數(shù)據(jù)庫的完整應用架構(gòu),變的很自然。
所為灰度環(huán)境就是生產(chǎn)環(huán)境,生產(chǎn)數(shù)據(jù),所影響的也是生產(chǎn)環(huán)境,只是范圍比測試環(huán)境更廣,更真實。其實就是小范圍的生產(chǎn)環(huán)境。類似于游戲內(nèi)測。
16. 高仿真架構(gòu)體系
建立高仿真架構(gòu)體系
- 數(shù)據(jù)庫,操作系統(tǒng)升級:應用是否適應,性能會變好, 還是變壞
- 應用上線發(fā)布,系統(tǒng)變更(列如換平臺),提前判斷業(yè)務影響和性能瓶頸
- 應對突發(fā)交易量,例如雙十一,性能極限在哪里,瓶頸在哪里。
17. 容災保障
高可用是運維核心要求,容災是最后屏障
例如 雙活比單活好,MGR比復制架構(gòu)好,重要系統(tǒng)要做好高可用,容災建設(shè)。
18. 多中心建設(shè)
冗余是基礎(chǔ),多中心建設(shè)是為了提升容災能力和擴展能力,并保障業(yè)務。
19. 應用和數(shù)據(jù)庫是一個整體
應用和運維人員一起,解決應用解耦,數(shù)據(jù)庫解耦,追賬補數(shù),業(yè)務監(jiān)控,應用路由,故障切換等。可用性,效率,故障恢復等方面都要一起參與。
20. 性能提升
開源數(shù)據(jù)庫使用應該合理且有效的結(jié)合周邊的其他類型數(shù)據(jù)庫,做到性能最大化。比如:Redis、MongoDB、ES、ClickHouse等。
總結(jié)
1. 最適合的架構(gòu)是結(jié)合軟件特性和業(yè)務場景,又能取得成本收益平衡;
2. 大數(shù)據(jù)情況下可以是利用讀寫分離、分庫分表,但要選擇合適的;
3. 不適合分庫的應該考慮竭盡所能把核心庫做小,然后通過垂直擴展來擴容;
4. 用盡各種技術(shù), 高可用 和 容災手段保證其可用。
以上就是MySQL20個高性能架構(gòu)設(shè)計原則(值得收藏)的詳細內(nèi)容,更多關(guān)于MySQL 架構(gòu)設(shè)計的資料請關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- MySQL雙主(主主)架構(gòu)配置方案
- 深入了解Mysql邏輯架構(gòu)
- MySQL 整體架構(gòu)介紹
- MySQL 4種常用的主從復制架構(gòu)
- MySQL 學習總結(jié) 之 初步了解 InnoDB 存儲引擎的架構(gòu)設(shè)計
- MySQL架構(gòu)體系知識點總結(jié)
- Mysql邏輯架構(gòu)詳解
- MySQL數(shù)據(jù)庫體系架構(gòu)詳情