資料庫讀寫分離,資料庫效能瓶頸

2021-09-27 13:28:35 字數 1505 閱讀 2037

有一些技術同學可能對於「讀寫分離」了解不多,認為資料庫的負載問題都可以使用「讀寫分離」來解決。

這其實是乙個非常大的誤區,我們要用「讀寫分離」,首先應該明白「讀寫分離」是用來解決什麼樣的問題的,而不是僅僅會用這個技術。

什麼是讀寫分離?

其實就是將資料庫分為了主從庫,乙個主庫用於寫資料,多個從庫完成讀資料的操作,主從庫之間通過某種機制進行資料的同步,是一種常見的資料庫架構。

乙個組從同步集群,通常被稱為是乙個「分組」。

資料庫分組架構解決什麼問題?

大多數網際網路業務,往往讀多寫少,這時候,資料庫的讀會首先稱為資料庫的瓶頸,這時,如果我們希望能夠線性的提公升資料庫的讀效能,消除讀寫鎖衝突從而提公升資料庫的寫效能,那麼就可以使用「分組架構」(讀寫分離架構)。

用一句話概括,讀寫分離是用來解決資料庫的讀效能瓶頸的。

但是,不是任何讀效能瓶頸都需要使用讀寫分離,我們還可以有其他解決方案。

在網際網路的應用場景中,常常資料量大、併發量高、高可用要求高、一致性要求高,如果使用「讀寫分離」,就需要注意這些問題:

資料庫連線池要進行區分,哪些是讀連線池,哪個是寫連線池,研發的難度會增加;

為了保證高可用,讀連線池要能夠實現故障自動轉移;

主從的一致性問題需要考慮。

在這麼多的問題需要考慮的情況下,如果我們僅僅是為了解決「資料庫讀的瓶頸問題」,為什麼不選擇使用快取呢?

為什麼用快取

快取,也是網際網路中常常使用到的一種架構方式,同「讀寫分離」不同,讀寫分離是通過多個讀庫,分攤了資料庫讀的壓力,而儲存則是通過快取的使用,減少了資料庫讀的壓力。他們沒有誰替代誰的說法,但是,如果在快取的讀寫分離進行二選一時,還是應該首先考慮快取。

為什麼呢?

快取的使用成本要比從庫少非常多;

快取的開發比較容易,大部分的讀操作都可以先去快取,找不到的再滲透到資料庫。

當然,如果我們已經運用了快取,但是讀依舊還是瓶頸時,就可以選擇「讀寫分離」架構了。簡單來說,我們可以將讀寫分離看做是快取都解決不了時的一種解決方案。

當然,快取也不是沒有缺點的

對於快取,我們必須要考慮的就是高可用,不然,如果快取一旦掛了,所有的流量都同時聚集到了資料庫上,那麼資料庫是肯定會掛掉的。

對於常見的資料庫瓶頸是什麼呢?

其實是資料容量的瓶頸。例如訂單表,資料量只增不減,歷史資料又必須要留存,非常容易成為效能的瓶頸,而要解決這樣的資料庫瓶頸問題,「讀寫分離」和快取往往都不合適,最適合的是什麼呢?

資料庫水平切分

什麼是資料庫水平切分?

資料庫水平切分,也是一種常見的資料庫架構,是一種通過演算法,將資料庫進行分割的架構。乙個水平切分集群中的每個資料庫,通常稱為乙個「分片」。每乙個分片中的資料沒有重合,所有分片中的資料並集組成全部資料。

水平切分架構解決什麼問題呢?

大部分的網際網路業務,資料量都非常大,單庫容量最容易成為瓶頸,當單庫的容量成為了瓶頸,我們希望提高資料庫的寫效能,降低單庫容量的話,就可以採用水平切分了。

而有少部分程式設計師,會沒有分析資料庫的效能瓶頸是什麼,就貿貿然的使用「讀寫分離」,殊不知「水平切分」才是正道。

資料庫讀寫分離

隨著乙個 的業務不斷擴充套件,資料不斷增加,資料庫的壓力也會越來越大,對資料庫或者sql的基本優化可能達不到最終的效果,我們可以採用讀寫分離的策略來改變現狀。讀寫分離現在被大量應用於很多大型 這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle,聽說是用 quest share p...

資料庫讀寫分離

隨著乙個 的業務不斷擴充套件,資料不斷增加,資料庫的壓力也會越來越大,對資料庫或者sql的基本優化可能達不到最終的效果,我們可以採用讀寫分離的策略來改變現狀。讀寫分離現在被大量應用於很多大型 這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle,聽說是用 quest share p...

資料庫讀寫分離

隨著乙個 的業務不斷擴充套件,資料不斷增加,資料庫的壓力也會越來越大,對資料庫或者sql的基本優化可能達不到最終的效果,我們可以採用讀寫分離的策 略來改變現狀。讀寫分離現在被大量應用於很多大型 這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle,聽說是用 quest share ...