空間換時間的數(shù)據(jù)庫設(shè)計
導讀：數(shù)據(jù)庫設(shè)計是工作中經(jīng)常會涉及到的，下文中將為大家?guī)?strong>空間轉(zhuǎn)換時間的詳細講解。大家都知道，我們的系統(tǒng)中很常會用到SMS、Email等的發(fā)送，在我們的設(shè)計中通常會創(chuàng)建一個Tb_outbox表，當產(chǎn)生數(shù)據(jù)時，插入到Tb_outbox表，由定時器去讀取Tb_outbox的數(shù)據(jù)進行發(fā)送，發(fā)送完了再修改Tb_outbox的發(fā)送狀態(tài)。是的，這就是通常的做法，但是當我們的SMS、Email的發(fā)送頻率和數(shù)量足夠大的時候，我們的系統(tǒng)就會出現(xiàn)性能、表被鎖等問題。那么如何能夠解決這些問題呢？
下面的設(shè)計的一個思想就是如標題所述：空間換時間。就個人而言，我感覺這個描述更加貼切：對象的職責分離，把Insert、Update、Delete等分離在不同的表中。下面就來看看這個設(shè)計圖：
圖：邏輯圖
Tb_NotSent_buffer：待發(fā)送短信緩存表(即時清理).
該表是為了避免應(yīng)用過多對Tb_NotSent同時操作產(chǎn)生鎖表情況。
主要考慮到產(chǎn)生待發(fā)短信的邏輯通常會比較復雜,或者長事務(wù)。
一次性將已經(jīng)在buffer表里的短信insert到Tb_NotSent,這次插入沒有長事務(wù)計算,由一條insert from select完成。
該表并非一定用到,視乎產(chǎn)生待發(fā)短信的邏輯的事務(wù)復雜度,和量而定。
Tb_NotSent：待發(fā)送的短信(會被定時清理)
會將該已經(jīng)發(fā)送的短信的處理結(jié)果存儲在jms消息隊列里。
把這些數(shù)據(jù)從Tb_NotSent copy到Tb_outbox同時,插一條記錄到Tb_Sent.這樣作是為了下一步刪除Tb_NotSent里已經(jīng)發(fā)送的信息.同時又不因為刪除而鎖Tb_NotSent表(應(yīng)用使用)
使用空間換時間的思想,減少對同一張表(Tb_outbox)的過多操作和過程時間的操作,導致鎖表出現(xiàn)系統(tǒng)瓶頸。
Tb_outbox：存儲歷史記錄的主表,該表需建立在獨立的數(shù)據(jù)庫。
減少備份文件大小，可靈活調(diào)整,大大減少備份空間的需求。
減少對主數(shù)據(jù)庫的影響。
Tb_Sent：一個參照表，為刪除Tb_NotSent表做基表
已經(jīng)發(fā)送短信(會定時清理),存放已經(jīng)被網(wǎng)關(guān)處理的短信(發(fā)送成功或者失敗)。
這個表不一定要保存和Tb_NotSent一樣多的字段，也許只要兩個字段，那就是ID值和狀態(tài)值。
數(shù)據(jù)庫設(shè)計中空間轉(zhuǎn)換時間就為大家介紹這么多，相信大家通過上文的學習，對數(shù)據(jù)庫設(shè)計中國空間轉(zhuǎn)換時間有所了解，希望大家都能夠從中有所收獲。
【編輯推薦】
