大資料環境下的資料庫結構描述

標籤：http   io   ar   資料   cti   on   c   amp   ad   

隨著資料的快速增長，分表，分庫，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。

分庫

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

更複雜的搜尋

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

大資料環境下的資料庫結構描述