關系型數(shù)據(jù)庫常見瓶頸和架構的演變

發(fā)布時間：2021-09-03 19:00:24 來源：億速云閱讀：447 作者：chen 欄目：大數(shù)據(jù)

本篇內(nèi)容主要講解“關系型數(shù)據(jù)庫常見瓶頸和架構的演變”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“關系型數(shù)據(jù)庫常見瓶頸和架構的演變”吧!

一、關系型數(shù)據(jù)庫常見瓶頸

1、大量并發(fā)讀/寫操作，導致單庫出現(xiàn)難以承受的負載壓力；

2、單表存儲數(shù)據(jù)量過大，導致檢索效率低下；

二、架構演變

演變1、數(shù)據(jù)庫讀寫分離

由Master負責寫操作，而Slave作為備庫，不開放寫權限，但允許讀權限，主從之前保持數(shù)據(jù)同步。

如果Master存在TPS（每秒處理事務數(shù)，區(qū)別于QPS）較高的情況，主從之間同步數(shù)據(jù)會存在延遲，因此寫入Master之前最好將同一份數(shù)據(jù)落到緩存中，以免高并發(fā)情況下備份庫取不到數(shù)據(jù)的情況。

演變2、數(shù)據(jù)庫垂直分庫

所謂垂直分庫就是根據(jù)企業(yè)的實際業(yè)務的垂直劃分，將原本冗余在單庫中的數(shù)據(jù)表拆分到不同的業(yè)務庫中，實現(xiàn)分而治之的數(shù)據(jù)管理和讀/寫操作。

以實際生產(chǎn)經(jīng)驗來看，以mysql為例，單表數(shù)據(jù)超過500萬行時，讀操作就會逐漸成為瓶頸，哪怕是索引重建也無法解決因為數(shù)據(jù)膨脹而帶來的檢索效率低下的問題，由于寫是順序寫，基本上寫入操作不會成為瓶頸，讀操作會存在上限。

演變3、數(shù)據(jù)庫的水平分庫與水平分表

水平分表就是將原本冗余在單庫中的單個業(yè)務表拆分為n個“邏輯相關”的業(yè)務子表（如： tab_011 tab_013...），不同的業(yè)務子表存儲到不同的區(qū)間數(shù)據(jù)，對外形成一個整體，這就是大家所說的分片（Sharding）操作。如果Master的TPS過高，也可以進行水平分庫，這個實施比較復雜，需要借助專門的分片中間件負責數(shù)據(jù)的路由工作。

后續(xù)存儲達到一定閥值時，只需對現(xiàn)有業(yè)務庫和業(yè)務表橫向擴容，并遷移數(shù)據(jù)即可。

三、MySQL Sharding 與MySQL Cluster 區(qū)別

MySQL Cluster 是集群模式，擴展了數(shù)據(jù)庫的并行處理能力，但是使用成本、維護成本巨大

MySQL Sharding 是分布式模式，不僅可以提升數(shù)據(jù)庫并行能力，還能夠解決單表數(shù)據(jù)量過大產(chǎn)生的檢索瓶頸。

四、Sharding中間件

1、明確定義SQL語句中的Shard Key（路由條件），因為路由維度決定數(shù)據(jù)的落盤的位置，需要定義一套特定的路由算法和規(guī)則。

2、常見Sharding中間件：

Cobar：開源，Proxy架構，支持MySQL數(shù)據(jù)庫

Mycat：開源，Proxy架構，支持任意數(shù)據(jù)庫

TDDL：部分開源，應用集成架構，支持MySQL和Oracle

Shark（推薦）：開源，應用集成架構，支持MySQL

3、多機SequenceID解決方案

要兼顧生成的ID的唯一性和連續(xù)性，依賴一個獨立的外圍單點系統(tǒng)來負責完成則不失為一個可取的方案，如果每生成一次就去數(shù)據(jù)庫中申請必然降低性能，建議從數(shù)據(jù)庫中取出一段ID，然后緩存在本地。

4、分布式事務

通過使用消息中間件的方式保證數(shù)據(jù)最終一致性。

五、數(shù)據(jù)庫的HA方案

1、基于配置中心實現(xiàn)主從切換，將數(shù)據(jù)源信息統(tǒng)一配置在ZooKeeper中，主從切換之前我們必須確保Slave已經(jīng)打開了讀寫權限。

2、基于Keepalived實現(xiàn)主從切換，在主從機器上裝上Keepalived程序，需要修改/etc/keepalive/keepalive.conf配置文件，配置好VIP（Virtual IP Address，虛擬IP地址）。

3、保障主從數(shù)據(jù)庫切換過程中的數(shù)據(jù)一致性

半同步復制可以理解為主從之間的強制數(shù)據(jù)同步，保證主從數(shù)據(jù)的實時性，只有從節(jié)點響應，主節(jié)點才會響應請求方已經(jīng)完成的事務，在流量較大的場景下不建議開啟此功能。

通過冗余表實現(xiàn)數(shù)據(jù)一致性，冗余數(shù)據(jù)核對。

消息隊列或者日志比對。

到此，相信大家對“關系型數(shù)據(jù)庫常見瓶頸和架構的演變”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

向AI問一下細節(jié)

關系型數(shù)據(jù)庫常見瓶頸和架構的演變

猜你喜歡

最新資訊

相關推薦

相關標簽