如何快速處理數(shù)據(jù)庫中大量數(shù)據(jù)

本篇內容主要講解“如何快速處理數(shù)據(jù)庫中大量數(shù)據(jù)”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何快速處理數(shù)據(jù)庫中大量數(shù)據(jù)”吧!

背景

• 將數(shù)百張數(shù)據(jù)結構相同的表（用Tn代表），合并至一張表（用C代表）

• T表數(shù)據(jù)量分布很不均衡，少至一位數(shù)，多至幾十萬

• T表間沒有業(yè)務關聯(lián)

• C表結構在T表結構的基礎上增加了幾個字段，無法使用INSERT INTO (SELECT * FROM)

• 數(shù)據(jù)總量約300萬，經單進程測試，處理速度約500/s，預估耗時約100min

目標

最大化提升數(shù)據(jù)處理速度，將耗時降至10min左右，此時C表的寫入速度約5000/s。

方案演進

方案一

因為T表間沒有業(yè)務關聯(lián)，所以每張表都可以單獨處理。

將T表按數(shù)據(jù)量排序，每個進程處理N張表，盡量平衡各進程的負載。

存在的問題：T表的數(shù)據(jù)量分布極為不均衡，有幾張表數(shù)據(jù)量在70萬左右，最終耗時約為（70萬/500）s，瓶頸問題嚴重。

方案二

在 方案一 的的基礎上，以 表+數(shù)據(jù) 的維度做并行處理，可以解決大表瓶頸問題。

存在的問題：代碼實現(xiàn)較復雜，需要考慮

• 每張T表的數(shù)據(jù)量

• 對大數(shù)據(jù)量的T表進行分割

• 避免數(shù)據(jù)重復處理

方案三

借助 Redis 的 pub/sub 機制，實現(xiàn)生產和消費的分離。

• 生產端負責將T表的 表名+ID 均衡發(fā)布至不同的channel，channel數(shù)量和進程數(shù)一致。

• 消費端每個進程訂閱不同的channel，讀取表名+ID，將表名+ID對應的數(shù)據(jù)寫入C表。

方案四

是方案三的變體，借助 Redis 的 List，實現(xiàn)生產和消費的分離。

• 生產端負責將T表的 表名+ID 寫入List

• 消費端讀取List，將 表名+ID 對應的數(shù)據(jù)寫入C表。

本方案相比 方案三 的優(yōu)勢在于代碼邏輯比較簡潔，生產端和消費端均不需要做負載均衡。消費端能者多勞，多個消費進程同步完成作業(yè)。

實現(xiàn)細節(jié)

最終采用方案四。

生產端

依次讀取T表數(shù)據(jù)，將 表名+ID 寫入List。需要注意List支持批量寫入，每次寫入100條數(shù)據(jù)，寫入速度約50000/s。

消費端

單個進程的消費速度約300/s，起10個消費進程，處理速度可以達到約3000/s。如果數(shù)據(jù)庫的寫入速度允許，可適當增加消費進程數(shù)量。

到此，相信大家對“如何快速處理數(shù)據(jù)庫中大量數(shù)據(jù)”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！