聊聊大數據環境下的數據庫架構

隨著數據的快速增長，分表，分庫，memcache,redis,mongodb,hadoop,bigtable等，各種解決方案呼之欲出。經過測試，在MySQL中，無論如何加索引，數據超過百w時，查詢起來耗時很明顯。 因此mysql分表分庫+memcache+redis也不失是一個完美解決方案。 由于redis不

隨著數據的快速增長，分表，分庫，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取余：

protected function getTableName($name, $id=null) {
 $tableName = self::SYS_DB_PREFIX . $name;
 if (is_numeric($id) && $id > 0)
 return $tableName . '_' . ($id % $this->tableNum);
} 

2. 查詢數據

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

關于動態頁面查詢，比如登錄后的豆瓣首頁，會有一些動態好友的更新信息。這些信息是存儲在一張臨時表中的，只保存10天的更新。

3. 刪除數據

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

4. 修改數據

修改數據時，需要更新對應的memcache。

分庫

當系統應用更加復雜時，一臺數據庫服務器的壓力是很大的，可根據系統的業務流進行分庫，比如文章一個獨立庫，評論一個獨立庫等。

更復雜的搜索

比如招聘網站中的，按地點，按行業，按規模等更多條件查詢時，就需要一定的搜索系統來完成，這里不做更多搜索細節討論。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com