分庫分表的幾種常見形式以及可能遇到的難題

一般分表分庫是按部就班的過程，若是一開始就分表分庫設計，除非有大量的開發設計時間；要否則都顯得過分設計；

通常是在數據庫讀寫出現瓶頸是才考慮分表分庫，若是數據表設計的合理，但張表達到一千萬的數據，查詢也不會出現性能問題；

那麼若是實在要分表分庫，應該怎麼設計，網上也提供了各類資料；我總結一些我看過的

1、垂直分表

也就是大表分小表，這個最好是在表設計時就考慮到；把經常使用的字段和管理的不經常使用字段分別放在不一樣的表，設計成主表和額外信息表；

2、水平分表

也稱爲橫向分表，就是把表中不一樣數據行按照必定的規律分佈到不一樣的數據庫表中（依然是同一個數據庫），如此下降單張表的數據量，

能提升查詢性能；最多見的方式就是經過主鍵或者時間等字段進行hash和取模後拆分，爲的是避免熱點數據；這是這種方式也同時未能

解決同一個庫IO瓶頸問題；

3、垂直分庫

也就是把不一樣的業務數據表，分在不一樣的數據庫中；這種方式有利於系統的維護和擴展。但這種方式也會帶來更大開發難度，若是把不一樣

數據庫放在不一樣機器上，那麼會帶來沒法跨庫join、分佈式事務等問題；

四，水平分庫分表

其實意思跟水平分表差很少，只是把水平分的表再分到不一樣的庫中；

解決的問題：單機的IO壓力，鏈接數；

帶來的問題：投入的硬件資源多，技術更加複雜（如分片查詢問題，分佈試事務等），如下分析這些難題的解決辦法；

分片查詢問題：

    一、join查詢

        1）字段冗餘；

        2）若是是字典表，能夠每一個庫中都放一份相同的表；

    二、關聯查詢

        一、系統組裝；不一樣的模塊提供查詢接口，在代碼層本身把查詢數據組裝；

        二、報表查詢的話選擇其餘技術實現，不如OLAP和OLTP；

        三、丟給spark進行處理；

參考：分庫分表的幾種常見形式以及可能遇到的難題