1．大資料量的儲存需要大量的資料庫資源；
2．資料量的不斷增長要求資料庫儲存具有可擴充套件性；
3．在保證大資料量的情況下，要保證效能、高可用性等質量要求；
4．現有框架中沒有徹底解決大資料量的儲存問題；
5．oracle等海量儲存方案**不菲，採用mysql進行分庫分表節約it成本。
1. 風險評估
1) dba資料庫管理的資源和規範要求；
2. 業務資料量規模和變化的影響
1) 對於事先可規劃的中等以上資料規模，採用單庫分表（乙個資料庫例項，分多張表）、讀寫分離、或者多庫多表（多個資料庫例項，多張表）可以滿足業務需求，且相應設計和實現相對簡單，不易出錯。
2) 對於初期資料規模不可準確預知，但隨著業務發展資料規模不斷增長的系統，要求資料儲存具有可擴充套件性。這種可擴充套件性通過分庫分表解決，要求分庫分表在路由上具有極強的伸縮性，這也是分庫分表的難點，本方案提出乙個循序漸進的實現路線逐步解決這個問題。
3. 技術積累
1) 公司已有簡單的分庫分表方案
2) 這個方案缺乏擴充套件性
3) 本方案將提出短期實現一定擴充套件性、中長期高可擴充套件性的方案
4. 開源或產品
1) 商業版資料庫sharding：mysql proxy，提供mysql協議介面（非jdbc），主從結構，可以負載平衡，讀寫分離，failover等，lua語法複雜，不支援大資料量的分庫分表；
2) amoeba，支援分資料庫例項，每個資料相同的表，不支援事務；類似mysql proxy，設計上拋棄lua，更簡單；
3) 阿里集團研究院開源的cobarclient，主要面向小規模的資料庫sharding集群訪問，基於ibatis，需要規劃資料規模，缺乏擴充套件性；另外有cobar，阿里集團內部的乙個完整dal層，實現完整jdbc**；
4) hibernateshards，hibernate提供的sharding，支援分資料庫例項，比較複雜，事先規劃資料規模，和框架不符；
6)tddl，**的dal，很強的分庫分表能力，仍然需要資料量實現規劃，動態擴充套件有限。
7) 以上某些產品在一定程度上可以滿足我們的需求，但不能徹底解決我們大資料量可擴充套件的問題。
1. 和沒有引入分庫分表時相比，每次操作最大延遲<1ms；
1. 垂直分庫，不同業務資料使用不同資料庫例項儲存
2. 資料切分：
a) 根據切分欄位hash取模；
b) 確定需要切分的資料，盡量將可能進行關聯的分片資料放在乙個資料庫例項中，例如同一使用者的基本資訊、好友資訊或者檔案資訊等；
3. 短期：分庫分表
a) 資料庫例項編號遞增
b) 每個資料庫內分表序號從1遞增，不全域性編號
c) 基於資料來源（ibatis基礎上）攔截建立訪問層，應用感知
d) 應用需在底層進行資料來源、分布式事務考慮和管理等
e) 可擴充套件性：只支援向上擴充套件，不支援收縮
4. 長期：資料庫訪問層
a) 建立靈活的資料切分和路由規則
b) 支援mysql集群
c) 讀寫分離和負載均衡
d) 可用性探測
e) 分布式事務
f) 對應用透明
附錄：
基於MySQL分庫分表方案簡介
1 大資料量的儲存需要大量的資料庫資源 2 資料量的不斷增長要求資料庫儲存具有可擴充套件性 3 在保證大資料量的情況下，要保證效能 高可用性等質量要求 4 現有框架中沒有徹底解決大資料量的儲存問題 5 oracle等海量儲存方案 不菲，採用mysql進行分庫分表節約it成本。1.風險評估 1 dba...
Mysql分庫分表方案
1.為什麼要分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。mysql中有一種機制是表鎖定和行鎖定，是為了保證資料的完整性。表鎖定表示你們都不能對這張表進行操作，必須等我對錶操作完才行。行鎖...
mysql分庫分表方案
分庫分表的幾種方式 1 把乙個例項中的多個資料庫拆分到不同的例項 2 把乙個庫中的表分離到不同的資料庫中 3 對乙個庫中的相關表進行水平拆分到不同的例項資料庫中 如何選擇分割槽鍵 1 分割槽鍵要能盡量避免跨分片查詢的發生 2 分割槽鍵要能盡量使各個分片中的資料平均 如何儲存無需分片的表 1 每個分片...