聊聊大資料環境下的資料庫架構

2021-08-27 06:11:57 字數 993 閱讀 6794

隨著資料的快速增長,分表,分庫,memcache,redis,mongodb,hadoop,bigtable等,各種解決方案呼之欲出。經過測試,在mysql中,無論如何加索引,資料超過百w時,查詢起來耗時很明顯。

因此mysql分表分庫+memcache+redis也不失是乙個完美解決方案。

由於redis不支援複雜查詢,redis的讀取效能還是趕不上mem這些劣勢,因此才需要一些搭擋。

流程從crud看底層架構。

1. 插入資料

一般情況下,對使用者是沒有必要分表的,使用者的文章或者微博才分表,畢竟使用者表和微博表是無法比擬,不乙個等級的。

插入時,任何表,mysql只儲存索引字段,其它資料儲存在redis上。文章錶可按一定規則進行靜態分表,比如按使用者id分100張表,每個使用者發的文章都會路由到同一張表中。

資料總數需要乙個單獨的字段儲存在redis中,每個使用者都有乙個key進行儲存文章總數。有時總數資料會與實際總條數有所不同,因此需要定期執行mysql count進行更新redis中的總數。

下面是分表路由,把uid對100取餘:

1protectedfunctiongettablename($name,$id=null)

2. 查詢資料

每第一次資料查詢時,根據mysql中的索引從redis查詢,需要將查詢結果儲存在memcache中,下次查詢直接從memcache獲取。查詢某人文章時,直接從一張表中進行limit查詢。

關於動態頁面查詢,比如登入後的豆瓣首頁,會有一些動態好友的更新資訊。這些資訊是儲存在一張臨時表中的,只儲存10天的更新。

3. 刪除資料

整個系統無任何實際操作,只進行字段狀態修改。

4. 修改資料

修改資料時,需要更新對應的memcache。

分庫更複雜的搜尋

**:

資料庫 大資料

spark 百萬級的資料,無論側重oltp還是olap,當然就是mysql了。過億級的資料,側重oltp可以繼續mysql,側重olap,就要分場景考慮了。實時計算場景 強調實時性,常用於實時性要求較高的地方,可以選擇storm 批處理計算場景 強調批處理,常用於資料探勘 分析,可以選擇hadoop...

大資料架構詳解 資料中臺架構下的大資料應用

有了資料中臺,資料在資訊化體系中不再是分散 凌亂 重複的存在,系統可以對資料進行實時的分類 整理 加工,使其成為清晰有序 有條理 有脈絡的有用資訊。這些資料可以進一步分享給業務應用系統以開展資料應用和實現資料變現,結果將通過前端展現系統以多樣化 視覺化的形式展現出來。1 資料中臺徹底消除企業的資訊孤...

資料庫 3 1 資料庫架構

如何設計乙個關係型資料庫?乙個關係型資料庫應該包括以下內容 資料庫最主要的功能是什麼?就是儲存資料,因此它會有乙個儲存模組,來負責儲存我們的資料,儲存模組就類似於我們的os檔案系統,將資料最終持久化存入磁碟中,如存入機械硬碟,或者ssd固態硬碟,抑或是它們的磁碟陣列矩陣中。可是光有儲存是不行的,我們...