關系型數據庫的架構演變


關系型數據庫的架構演變


在互聯網場景下,關系型數據庫常見的性能瓶頸主要有兩個

  • 大量的並發 讀/寫操作,導致倒庫出現難以承受的負載壓力
  • 單表存儲數據量過大,導致檢索效率低下

數據庫讀寫分離


在系統初期,整體的並發了相對較小,因此一般都是將所有的數據信息存儲在單庫中進行讀/寫操作。但是隨着用戶規模不斷提升,單庫逐漸力不從心,TPS/QPS越來越低。因此到了這個時候,dba會將數據庫設置為讀寫分離狀態(生產環境一般會采用一主一從或者一主多從),Master負責寫操作,Slave作為備庫,不開放寫操作,但是允許讀操作,主從之間保持數據同步即可。
讀寫分離之后,可以大大提升單庫無法支撐的負載壓力
需要注意的是:如果Master存在TPS存在較高的情況,Master之前最好將同一份數據落到緩存中,以避免高並發情況下,從Slave中獲取不到指定數據的情況發生
[MySQL 主從同步延遲的原因及解決辦法(https://blog.csdn.net/soar_away/article/details/72615012)

數據垂直分庫


讀寫分離讓系統的吞吐量相對於單庫來說有了一定的提升,但是只依靠讀寫分離並不能一勞永逸,隨着用戶規模攀升,系統瓶頸一定會暴露。
因為,這個階段Dba會對數據庫執行垂直分庫,垂直分庫就是根據自身業務垂直划分,將表拆分到不同的業務庫中。實現分而治之的數據管理和讀寫操作。

單表數據量一大,讀操作會逐漸成為瓶頸
寫操作因為是順序寫,所以基本上數據庫的寫入操作不會因為數據膨脹而成為瓶頸,但是讀操作一定會存在上限;
讀操作成為瓶頸的時候,就該做水平分庫了

數據庫水平分庫與水平分表


水平分表:將原本冗余在單庫中的單個業務表拆分成為n個“邏輯相關”的業務字表(如:tab_000、tab_0001、…..)
水平分庫:如果Master的TPS過高,則還可以對垂直分庫后的單一業務進行水平化,同水平分表類似。

分庫分表操作主要是為了解決:高並發場景下單庫的性能瓶頸,並充分利用分布式的威力提升數據庫的讀/寫能力。
假設后續業務表中的數據量又一次達到存儲閾值並對性能產生影響時,DBA只需要再次對現有業務庫和業務表橫向擴容,並遷移數據即可。

Mysql Sharding 和 Mysql Cluster區別


Mysql Cluster只是一個數據庫的集群,其優勢只是擴展了數據庫的並行處理能力,但是其使用成本、維護成本非常高,並且實施起來比較復雜

Mysql sharding 不近提升數據庫的並行處理能力,還能夠解決因為單表數據量過大所產生的檢索瓶頸。

Mysql Cluster前者是集群模式,Mysql sharding是分布式模式。Sharding是當下互聯網最好的選擇


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



數據庫架構的演變 數據庫架構演變概要 直播平台的數據庫架構演變 關系型數據庫 關系型數據庫 關系型數據庫 什么是關系型數據庫 關系型數據庫 關系型數據庫 什么是關系型數據庫?
 
粤ICP备14056181号  © 2014-2020 ITdaan.com