題庫分庫分表架構方案

我的博客地址 https://www.texixi.com/2019/0...

方案

項目背景

在如今題庫架構下，針對新購買的1300W多道數據進行整合，不影響現有功能。因爲數據量偏多，須要進行數據的切分

目標場景

1. 兼容舊的功能
2. 對1300多W數據進行分庫分表
3. 須要對舊的數據進行整合
4. 老師端選題組卷 能夠根據 學段、學科、知識點、難度、題型 來篩選
5. 學生端根據老師端所選題目獲取對應的題目
6. 對3年內之後擴展的增量數據預留數量空間

數據樣例

學段	數據量
小學	1285336
初中	6655780
高中	6144072

學段學科	數據量
初中數學	1869524
初中化學	1356224
初中英語	288440

切分方案一

1. 切分爲3個庫， 分別是小學、初中、高中 數據佔好比上
2. 每一個庫切分10個表 根據 （學科+首級知識點）%10
3. 每一個庫一個總表

缺點：例：用到不一樣知識點時，須要多表獲取數據

優勢：數據分佈較爲平均

切分方案二 （採用）

1. 切分爲3個庫， 分別是小學、初中、高中 數據佔好比上
2. 每一個庫切分10個表(所有10個學科) 根據 學科區分， 例： 數學表、物理表
3. 每一個庫一個總表

缺點：數據不大平均， 數據量多的例數學有186W多、英語28W多

優勢：當有用到組卷等須要篩選多知識點題目時，不用多表查詢

數據id 自增區間劃分

1. 小學 1-2億
2. 中學 2-3億
3. 高中 3億起

關聯關係圖

根據知識點獲取題目流程

自增id

1. 對原有的id區間段不作處理
2. 對切分後的id自增段進行規劃

兼容舊功能

解決的問題

1. 新舊數據有重複的知識點、題目
2. 新舊數據的結構不同
3. 對舊的題庫功能代碼的修改
4. 兩套題庫合併主鍵衝突問題

兼容舊功能 方案一 （我的推薦）

1. 有操做的舊的數據洗入新的結構，舊的數據只爲兼容原有的功能數據，不作顯示。

優勢：
不用變更數據結構，最新的購買的數據結構較爲清晰。 易維護擴展，由於目前舊的數據已經整合了兩套數據

缺點：
須要修改所有舊有的功能代碼（針對新的數據結構）

兼容舊功能 方案二

1. 把新購買的數據整合進老的數據結構，同時保留三批數據，須要處理全部表的主鍵衝突、三批各表數據去重

優勢：

1. 舊有代碼只修改數據結構切分的部分，不用所有修改功能代碼

缺點：

1. 數據較亂，三套不一樣的數據同時存在數據庫
2. 須要處理新的結構整合進舊的數據結構，同時須要處理主鍵衝突，
3. 代碼上須要處理對應的數據

問題點

1. 測試環境和正式環境圖片存放在那裏？100多G，上傳cdn須要幾十天時間，有4000多W張，目前cdn不支持打包上傳

解決方案：購買單獨服務器，主備，存放圖片

1. 測試db 正式db 1300多w 目前佔用100G左右, 須要存放空間

解決方案：測試環境新加硬盤，新加db實例端口3307，正式環境db存放在圖片服務器

代碼設計模式

1. 採用適配器模式（原先的代碼結構不變）
2. 類圖

調研內容

中間件MYCAT（未使用）

什麼是MYCAT

1. 一個完全開源的，面向企業應用開發的大數據庫集羣
2. 支持事務、ACID、能夠替代MySQL的增強版數據庫
3. 一個能夠視爲MySQL集羣的企業級數據庫，用來替代昂貴的Oracle集羣
4. 一個融合內存緩存技術、NoSQL技術、HDFS大數據的新型SQL Server
5. 結合傳統數據庫和新型分佈式數據倉庫的新一代企業級數據庫產品
6. 一個新穎的數據庫中間件產品

MYCAT特性

1. ==支持庫內分表（1.6）==
2. ==支持單庫內部任意join，支持跨庫2表join，甚至基於caltlet的多表join==
3. 支持全局序列號，解決分佈式下的主鍵生成問題。
4. ==分片規則豐富==，插件化開發，易於擴展。
5. 基於Nio實現，有效管理線程，解決高併發問題。
6. ==支持經過全局表，ER關係的分片策略，實現了高效的多表join查詢==
7. 支持分佈式事務（弱xa）。
8. 支持SQL黑名單、sql注入攻擊攔截
9. ==支持MySQL、Oracle、DB二、SQL Server、PostgreSQL等DB的常見SQL語法==
10. ==遵照Mysql原生協議==，跨語言，跨平臺，跨數據庫的通用中間件代理。
11. ==基於心跳的自動故障切換，支持讀寫分離，支持MySQL主從，==以及galera cluster集羣。
12. 能夠大幅下降開發難度，提高開發速度
13. 具體看 mycat 官網

Mycat 注意事項

1. 全局表一致性檢測 1.6版本開始支持（一致性的定時檢測）
2. 分片 join（儘可能避免使用 Left join 或 Right join,而用 Inner join）

Mycat 原理

1. 應用要面對不少個數據庫的時候，這個時候就須要對數據庫層作一個抽象，來管理這些數據庫，而最上面的應用只須要面對一個數據庫層的抽象或者說數據庫中間件就行了，這就是Mycat的核心做用。
2. 分片分析、路由分析、讀寫分離分析、緩存分析等，而後將此SQL發日後端的真實數據庫，並將返回的結果作適當的處理，最終再返回給用戶。

Mycat 應用場景

1. 讀寫分離，配置簡單
2. 分表分庫，對於超過1000萬的表進行分片，最大支持1000億的單表分片
3. 報表系統，藉助於Mycat的分表能力，處理大規模報表的統計

文章整理

1. 應用場景 那些適合，那些不適合 https://www.cnblogs.com/barry...
2. 使用說明 https://juejin.im/post/59c325...

總表使用mysql MERGE 引擎(不考慮)

1. 合併的表使用的必須是MyISAM引擎
2. 表的結構必須一致，包括索引、字段類型、引擎和字符集
3. 對於增刪改查，直接操做總表便可。

數據切分原則

1. 能不切分儘可能不要切分。
2. 若是要切分必定要選擇合適的切分規則，提早規劃好。
3. 數據切分儘可能經過數據冗餘或表分組（Table Group）來下降跨庫 Join 的可能。
4. 因爲數據庫中間件對數據 Join 實現的優劣難以把握，並且實現高性能難度極大，業務讀取儘可能少使用多表 Join。
5. 儘量的比較均勻分佈數據到各個節點上
6. 該業務字段是最頻繁的或者最重要的查詢條件。