分布式數(shù)據(jù)庫拆分表常用的方法

1、分布式數(shù)據(jù)庫拆分表常用的方法分布式數(shù)據(jù)庫拆分表常用的方法在大容量，高負荷的web系統(tǒng)中，對數(shù)據(jù)庫進行一系列拆分，可有效提升數(shù)據(jù)庫容量和性能。在初學程序的早期，程序員通常都喜歡按傳統(tǒng)數(shù)據(jù)庫設計模式，設計為單庫和單一功能表的結構，這樣的結構在數(shù)據(jù)量和并發(fā)量達到一定程度之后，會出現(xiàn)嚴重性能問題和維護問題。在出現(xiàn)問題的時候才著手進行優(yōu)化，會非常痛苦，所以應該在系統(tǒng)架設之初就考慮好之后會出現(xiàn)的問題。目前有些數(shù)據(jù)庫策略是采用單庫結構，然后通過同步分

2、發(fā)到數(shù)臺服務器實現(xiàn)讀寫分離。個人覺得這樣的策略非常笨拙，還是想辦法將其分隔開來好，否則每臺機器的內存都很容易超支。一般只對數(shù)據(jù)量比較大的表進行拆分，這應該沒有什么異議；還有一種是有可能會進行維護的比較重要的表，比如文章目錄表，如果有從其它系統(tǒng)倒數(shù)據(jù)進來的可能的話，也要拆掉，不然倒數(shù)據(jù)時一不小心把目錄表弄壞了，發(fā)現(xiàn)忘了備份，那真是欲哭無淚。下面來分析一下：一、時間結構如果業(yè)務系統(tǒng)對時效性較高，比如新聞發(fā)布系統(tǒng)的文章表，可以把數(shù)據(jù)庫設計成時

3、間結構，按時間分有幾種結構：1)平板式表類似：article_200901article_200902article_200903用年來分還是用月可自定，但用日期的話表就太多了，也沒這必要。一般建議是按月分就可以。這種分法，其難處在于，假設我要列20條數(shù)據(jù)，結果這三張表里都有2條，那么業(yè)務上很有可能要求讀三次表。如果時間長了，有幾十張表，而每張表是0條，那不就是要讀完整個系統(tǒng)的表才行么？另外這個結構，要作分頁是比較難實現(xiàn)的。主鍵：在這個

4、系統(tǒng)中，主鍵是13位帶毫秒的時間戳，不要用自動編號，否則難以通過主鍵定位到表，也可以在查詢時帶上時間，但比較煩瑣。2)歸檔式表類似：article_oldtieba_汽車tieba_飛機tieba_火箭tieba__unite這個表汽車、火箭表是屬于熱門表，定義為新建的版塊放在unite表里面，待到其超過一萬張主貼的時候才開對應表結構。因為在貼吧這種系統(tǒng)中，冷門版塊肯定比熱門版塊多得多，這些冷門版塊通常只有幾張?zhí)?，為它們開表也太浪費了

5、；同時熱門版塊數(shù)量和訪問量等，又比冷門版塊多得多，非常有特點。unite表還可以擴展成哈希表，利用詞條的md5編碼，可以分成n張表，我算了一下，md5前一位可分16張表，兩位即是256張表。tieba_unite_abtieba_unite_ac…三、哈希結構哈希結構通常用于博客之類的基于用戶的場合，在博客這樣的系統(tǒng)里有幾個特點，1是用戶數(shù)量非常多，2是每個用戶發(fā)的文章數(shù)量都較少，3是用戶發(fā)文章不定期，4是每個用戶發(fā)得不多，但總量仍非常