架構師_程序員

 找回密碼
 注冊[Register]

QQ登錄

只需一步,快速開始

查看: 107|回復: 0
打印 上一主題 下一主題

[資料] 數據庫架構:讀寫分離到CQRS

[復制鏈接]
跳轉到指定樓層
樓主
發表于 2020-5-4 09:58:50 | 只看該作者
讀寫分離

當一個公司業務不斷擴展,用戶量大量增加,原來使用的數據庫很可能就撐不住了。那么可以

  • Scale-in,擴充硬件的性能,但是很可能用戶量繼續增長,增加的性能很快就吃光了。
  • 讀寫分離:數據庫撐不住了,無非就是讀寫量過大,特別是有一些復雜的查詢比如最近24小時最熱門的產品等。需要很復雜的SQL語句,運行起來當然是慢。


但是為了讀寫分離,需要把數據庫拆分為master庫和Slave庫,

市面上主要的關系數據庫都支持數據復制功能,所以可以把一個數據庫拆分為Master和Slave兩種角色,寫操作在主上,由Master服務器向其他Slave服務器進行同步。

而讀操作以及數據分析等離線操作都在Slave服務器上進行。

我們知道互聯網的很多應用都是讀的,這樣有多個Slave可以負載分擔一下,又可以保證數據的可用性和正確性。



但是相應的原有的應用代碼也需要修改,必須改為寫數據用master庫,讀數據的時候使用slave庫,就相當于重寫了。

復雜查詢

但是就算重寫了代碼,發現性能還是無法得到明顯的提升,原因仍然是使用了太多復雜的查詢,數據庫組成部分里面我們都說過,聯接非常消耗性能。

那么我們可不可以單獨用一張表來存放過去24小時的熱門產品啊,這樣只需要使用簡單的SQL就能搞定。

也就是說,一套單一的數據庫表對報表、搜索、事務等不同的行為是不適當的。

現在的表是為了新增、修改數據而設計的,對復雜查詢不適合。

但是我們還需要考慮這個查詢庫如何更新的問題,還就是可能不是實時更新,我們能否忍受這種延遲的問題。

CQRS

能否忍受延遲的問題需要從業務上來看,比如過去24小時熱門的極品,一點點過時的信息沒有太大的影響,只要求最終一致即可。

我們可以使用CQRS(Command Query Responsibility Segregation),也就是增刪改的命令與查詢責任分離。



在CQRS中,強調的是讀(Query)寫(Command)分離,因為用戶讀到的數據通常是過時的,那么為什么還需要從數據庫讀一遍呢,可以直接建立一個讀數據源??梢允荂ache,可以是XML、JSON等。

那之前提到的怎么更新的問題怎么解決?可以使用Event,也就是事件,比如某個產品賣出去了,可以發布一個事件,修改原有的Read Model。

這樣就通過事件機制把同步變成了異步。

最后,這種方法最好只在復雜查詢中用,原來的簡單查詢依然在關系型數據庫里面取。為什么呢?因為引入一種新的技術需要付出代價,比如同步變異步了,還需要事件機制,我們不能只看到新技術的優點,而看不到缺點了。






上一篇:濟寧新型冠狀病毒實時大數據報告源碼下載
下一篇:引用項目類庫時dll.refresh文件的影響
帖子永久地址: 

架構師_程序員 - 論壇版權1、本主題所有言論和圖片純屬會員個人意見,與本論壇立場無關
2、本站所有主題由該帖子作者發表,該帖子作者與架構師_程序員享有帖子相關版權
3、其他單位或個人使用、轉載或引用本文時必須同時征得該帖子作者和架構師_程序員的同意
4、帖子作者須承擔一切因本文發表而直接或間接導致的民事或刑事法律責任
5、本帖部分內容轉載自其它媒體,但并不代表本站贊同其觀點和對其真實性負責
6、如本帖侵犯到任何版權問題,請立即告知本站,本站將及時予與刪除并致以最深的歉意
7、架構師_程序員管理員和版主有權不事先通知發貼者而刪除本文

碼農網,只發表在實踐過程中,遇到的技術難題,不誤導他人。
您需要登錄后才可以回帖 登錄 | 注冊[Register]

本版積分規則

免責聲明:
碼農網所發布的一切軟件、編程資料或者文章僅限用于學習和研究目的;不得將上述內容用于商業或者非法用途,否則,一切后果請用戶自負。本站信息來自網絡,版權爭議與本站無關。您必須在下載后的24個小時之內,從您的電腦中徹底刪除上述內容。如果您喜歡該程序,請支持正版軟件,購買注冊,得到更好的正版服務。如有侵權請郵件與我們聯系處理。

Mail To:help@itsvse.com

QQ|Archiver|手機版|小黑屋|架構師 ( 魯ICP備14021824號-2 )|網站地圖

GMT+8, 2020-6-4 12:50

Powered by Discuz! X3.4

Copyright © 2001-2020, Tencent Cloud.

快速回復 返回頂部 返回列表
捕鸟达人老版