想用資料庫「讀寫分離」 請先明白「讀寫分離」解決什麼問題

2020-12-16 會技術的葛大爺

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

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

什麼是讀寫分離?

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

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

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

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

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

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

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

資料庫連接池要進行區分,哪些是讀連接池,哪個是寫連接池,研發的難度會增加;為了保證高可用,讀連接池要能夠實現故障自動轉移;主從的一致性問題需要考慮。在這麼多的問題需要考慮的情況下,如果我們僅僅是為了解決「資料庫讀的瓶頸問題」,為什麼不選擇使用緩存呢?

為什麼用緩存

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

為什麼呢?

緩存的使用成本要比從庫少非常多;緩存的開發比較容易,大部分的讀操作都可以先去緩存,找不到的再滲透到資料庫。當然,如果我們已經運用了緩存,但是讀依舊還是瓶頸時,就可以選擇「讀寫分離」架構了。簡單來說,我們可以將讀寫分離看做是緩存都解決不了時的一種解決方案。

當然,緩存也不是沒有缺點的

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

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

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

資料庫水平切分

什麼是資料庫水平切分?

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

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

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

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

【官方正品】ZTM無線藍牙耳機運動跑步雙耳塞入耳頭戴式開車重低音炮可接聽電話超長待機蘋果手機通用耳麥

相關焦點

  • 資料庫讀寫分離提高性能詳解,原理是什麼
    一部分程式設計師雖然知道處理大數據量時,資料庫要做讀寫分離,但是為什麼讀寫分離可以提高性能呢,原理是什麼?
  • 終於學會了 MySQL 主從配置和讀寫分離
    MySQL 讀寫分離的?面試官:那你說說資料庫是主從怎麼配置?小阿花:額,都是 DBA 幫我們搞好的,我們直接用就好了。面試官:你們主從結構遇到過什麼故障沒,比如從庫或者主庫掛掉了,怎麼解決的?小阿花:這個也是 DBA 搞的。面試官:(微笑)好的,今天就到這裡,回去等通知吧。
  • SpringBoot + MyBatis + MySQL讀寫分離實踐!
    引言讀寫分離要做的事情就是對於一條SQL該選擇哪個資料庫去執行,至於誰來做選擇資料庫這件事兒,無非兩個,要麼中間件幫我們做,要麼程序自己做。因此,一般來講,讀寫分離有兩種實現方式。第一種是依靠中間件(比如:MyCat),也就是說應用程式連接到中間件,中間件幫我們做SQL分離;第二種是應用程式自己去做分離。
  • SpringBoot+MyBatis+MySQL讀寫分離(實例)
    引言讀寫分離要做的事情就是對於一條SQL該選擇哪個資料庫去執行,至於誰來做選擇資料庫這件事兒,無非兩個,要麼中間件幫我們做,要麼程序自己做。因此,一般來講,讀寫分離有兩種實現方式。第一種是依靠中間件(比如:MyCat),也就是說應用程式連接到中間件,中間件幫我們做SQL分離;第二種是應用程式自己去做分離。
  • 輕量級讀寫分離客戶端 MyRWSplit 0.2 版發布
    輕量級讀寫分離客戶端 MyRWSplit 0.2 版發布了。
  • 緩存與資料庫的數據一致性的解決方案
    笑笑談科技分享編程基礎知識,科技發展動態,與大家共同學習進步,請多多支持關注前言上篇文章提到,一般存儲數據,都用市面上比較流行的MYSQL和ORACLE資料庫存儲,但隨著數據量的增加雖說這樣能減輕資料庫壓力,但是如果修改刪除數據,在多線程高並發的場景下會有可能導致緩存和資料庫數據不一致問題,那該如何解決呢?
  • 程式設計師基礎知識,資料庫的主從分離,了解這些就夠了
    我們都知道,是機器就可能會出問題,並且還可能伴隨著網絡、電網等多種不可抗力因素,這年頭,像支付寶被挖斷光纖的事情,幾乎每年就會出現好幾起。今天,我們來聊一聊資料庫的一些事情。我們常常使用分布式,也就是多機方案來解決上述問題,最簡單的方法,我們可以使用一臺備機,將主資料庫的數據同步過去,這個時候,所有的業務系統仍然讀寫主資料庫,從資料庫只做冷備處理。
  • Python開發之:Django基於Docker實現Mysql資料庫讀寫分離、集群、主從同步詳解 | 原力計劃
    讀寫分離,基本的原理是讓主資料庫處理事務性增、改、刪操作(INSERT、UPDATE、DELETE),而從資料庫處理SELECT查詢操作。
  • ACCESS資料庫中Field對象的caption屬性讀寫
    ACCESS資料庫中Field對象的caption屬性讀寫 本文章說明如何用VBA讀寫該屬性。
  • 面試官:說說Mysql資料庫分庫分表,並且會有哪些問題
    已經談到了資料庫集群之主從集群也就是讀寫分離,也提到了讀寫分離其實只是分擔了訪問的壓力,但是存儲的壓力沒有解決。存儲的壓力說白了就是隨著系統的演化,需求的增加,可能表的數量會逐漸增多,比如一段時間上個新功能就得加個表。
  • 從上世紀80年代到今天,達夢資料庫技術架構演進與應用全記錄
    像Oracle資料庫一樣,達夢資料庫開局也是一個單機資料庫,這個單機資料庫是1988年馮玉才教授研究出來的我國第一代有自主智慧財產權的資料庫管理系統。隨著達夢資料庫在一些重要行業的廣泛應用,為了解決高可用性的需求,達夢推出了主備架構。隨著「稜鏡門」事件的發展,國家對信息安全的重視程度進一步提升,國家希望能夠推行晶片級的國產化,為了在晶片級國產化的場景裡面真正應用起來,達夢推出了讀寫分離架構。
  • Java並發包下Java多線程並發之讀寫鎖鎖學習第五篇-讀寫鎖
    一:讀寫鎖的理論什麼是讀寫鎖?多個線程同時讀一個資源類是沒有任何問題的,所以為了滿足在並發的情況下,讀取共享資源應該是可以同時進行的;但是,如果一個線程想要去寫共享資源,就不應該再有其他線程可以對該共享資源進行讀或者是寫操作了。
  • 讀寫障礙
    它的意思是讀寫障礙。她開始搜集資料,發現欣欣的表現——混淆上下左右、朗讀時跳字或跳行——這些與讀寫障礙症狀一一對應。  「不知道原因,我很困擾;當我知道的時候,我太高興了!」餘靜佳終於明白下一步應該做什麼了。  她繼續研究。每個漢字都是集聲音、外形和意義於一體,而讀寫障礙兒童正是在掌握這三者之間的聯繫時出現延遲或信號丟失。
  • 解密 雲HBase 冷熱分離技術原理
    前言HBase是當下流行的一款海量數據存儲的分布式資料庫。往往海量數據存儲會涉及到一個成本問題,如何降低成本。常見的方案就是通過冷熱分離來治理數據。冷數據可以用更高的壓縮比算法(ZSTD),更低副本數算法(Erasure Coding),更便宜存儲設備(HDD,高密集型存儲機型)。
  • 什麼是雲資料庫?雲資料庫機型版本和產品架構介紹
    老劉博客之前有文《雲資料庫有什麼用?UCloud海外MySQL雲資料庫促銷最低5折》介紹了近期UCloud的雲資料庫促銷活動內容,今天老劉博客這裡依UCloud優刻得雲資料庫UDB MySQL為例,和朋友們分享什麼是雲資料庫以及雲資料庫機型版本和產品架構是什麼樣的。
  • 作為資料庫核心成員,如何讓淘寶不卡頓?
    阿里妹導讀:TDDL(Tabao Distributed Data Layer)是淘寶開源的一個用於訪問資料庫的中間件,集成了分庫分表,主備,讀寫分離,權重調配,動態資料庫配置等功能。本文以2007年TDDL初誕生時的視角,介紹TDDL是如何一步步設計成型的,希望能幫助同學們簡單收穫:常規資料庫效率問題解決思路、TDDL框架設計基本思路以及分布式資料庫設計思路等。文末福利:《MySQL實操》技術公開課。
  • APP Store裡找不到騰訊產品,是商業問題?不,可能只是因為蘋果升級了Oracle資料庫!
    我開玩笑說:可能是蘋果升級了Oracle資料庫,檢索的排序出現了問題。 從我的檢索來看,搜索Tencent可以找到騰訊的產品,從分類裡也可以找到微信。而且蘋果App Store的後臺確實是Oracle資料庫。那麼,全球用戶訪問的壓力,如何通過集中、單一的Oracle資料庫支持這海量並發的請求呢? 這就屬於數據架構層必須解決的問題。
  • ASP.NET Core2讀寫InfluxDB時序資料庫
    InfluxDB是用Go語言編寫的,它會編譯成一個沒有外部依賴的二進位文件來運行,支持Java、JavaScript、c#等語言。InfluxDB支持類似SQL的查詢語言,同時還支持正則表達式、算術表達式和時間序列特定函數以加速數據的處理效率。
  • 英語中聽說讀寫先學哪個?
    那現在的問題就是這幾種排列組合的分別的利弊何在?第一種:聽-說-讀-寫這種次序是小孩子自然習得語言的次序。如果是0~4孩子學英語,我是非常推薦這種次序,以聽說開頭,隨著他年齡成長,逐步進入讀寫環節。這種學法的好處在於能夠培養孩子良好的語音基礎。
  • 雲時代的分布式資料庫:阿里分布式資料庫服務DRDS
    從上面的說明,我們可以發現,問題的關鍵並不是分布式事務做不出來,而是做出來了卻因為性能太差而沒有什麼卵用。資料庫領域的高手們努力了40年,但至今仍然沒有人能夠很好地解決這個問題,Google Spanner的開發負責人就經常在他的Blog上談論延遲的問題,相信也是飽受這個問題的困擾。