無限容量數據庫架構總結
本文是對58同城沈劍的文章二次整理，並結合自己的實踐再加工得來。所以非常感謝沈劍。
一、引子
- 故事：業務遇到了瓶頸，多張表每個月新增億級數據，如何仍然保證高可用。
- 開始：所有不與業務結合的架構都是耍流氓，針對具體場景進行分析得出具體方案。
- 收集：所以先需要對所有數據庫架構有所了解，才能比較。以下內容分為三個話題：
- 數據庫架構
- 數據水平切分實踐
- 遷移或者擴容方案
二、數據庫架構
1、單庫方案
2、分組架構：
常見為一主多從、主從同步、讀寫分離架構；
技術實現方式常見有數據庫在線或者歸檔日誌（oracle goldengate、mysql binlog）、ETL技術。
適用於讀多寫少場景，用於解決讀瓶頸；
3、分片架構：分表、分區、分庫。
相同點：減少索引的B-樹深度，所以提高了插入或者查詢數據的效率；
不同點：分表在同一個表空間，仍有IO競爭、分區支持不同表空間可改善IO競爭、分庫可實現徹底物理隔離；
分片常見算法有hash算法、範圍算法、和復合算法（此外，還有列表分片）；
適用於數據庫量過大的場景，一般建議數據量多大則分庫，原因見上。
4、分組+分片復合架構
適用於讀寫量都巨大的場景。
5、垂直切分
包含垂直分表和垂直分表分庫；
需要考慮長度和訪問頻度，長度短、訪問頻度高的放在一起。例如用戶表與用戶擴展信息表。
適用於業務字段較多、訪問頻度且不一致的場景，這樣可以使得訪問頻度高的數據加載到內存，減少IO，加快訪問速度。如果分庫，還也可以降低單庫容量。
三、數據庫水平切分實踐
1、單key業務
A、使用分片架構，詳見2.3章節；
B、單key衍生場景——
A、用戶多弱key業務，例如，：戶登錄，UID為key，後續業務都用UID處理。同時需要支持手機、身份證號等登錄。
（1）部分時候可參照多key場景
（2）基本方案為：索引外置（索引表法、映射緩存法）和基因法（弱key內置key中，弱key的分片算法結果內置key中）
B、運營側業務，常見問題場景是批量分頁或者統計查詢
（1）解耦：中間件、數據庫、數據庫表層解耦。
（2）可以是插入時冗余一套數據，也可以使用ods庫、或者索引外置的方案
2、一對多業務
A、切分方案，分庫場景如下——
外鍵分庫，導致外聯表分到不同庫中，需要遍歷庫；主鍵分庫，導致根據外鍵查詢詳細信息時，需要先反向查找主鍵定位庫，可結合索引外置方案；基因法分庫，目前最好的實踐。
B、衍生場景，分庫後的弱key查詢——
元數據與索引數據分離：元數據用於滿足key查詢；索引數據用於根據弱key查找key，然後就能根據key找到對應庫，並且根據key查詢元數據。
3、多對多業務
A、基本思路：數據冗余方式分庫
B、實踐方式：例如，A關註B，則為在關註表中，A關註了B，在被關註表中，B是A的粉絲。這樣單個查詢命中單庫就能滿足要求。
C、關鍵點：數據存儲多份要保證（最終）一致性。
4、多key業務
A、基本思路：通過冗余的方式來降維，通過降維來用低維度的手段解決問題；
B、實踐方式：例如訂單關系中的客戶與商家，則為客戶存儲訂單信息，變為一對多；也為商家存儲訂單信息，變為一對多；實踐中有時是變為多對多。
C、關鍵點：數據存儲多份要保證（最終）一致性。
四、遷移或者擴容方案
遷移和擴容是兩個不同的事件，有時擴容伴隨著遷移。
- 遷移方案：
- 全量遷移+停機增量遷移：停機是為了保證不會在遷移期間產生新的增量數據；
- 雙寫法（非停機）遷移：舊庫修改變為新舊庫同時修改，在此期間遷移數據到新庫，最終對比數據，然後切換過去。
- 擴容方案：
- 全量遷移+停機增量遷移
- 雙主同步方案（完美方案）——
（1）假設，現在有A/B兩臺，%2=0路由到A，%2=1路由到B
（2）現在為AB建立雙主同步庫，A對應C、B對應D
（3）修改配置項建立新的鏈接，%4=0對應A、%4=1對應B、%4=2對應C、%4=3對應D
（4）撤銷雙主，A與C、B與D不再建立關系
（5）數據縮容：例如將A中%4=2的全部幹掉，C中%4=0的全部幹掉。完美結束。
- 數據遷移的效率：
大表遷移數據的幾種有效方式——
新表不建立索引，遷移完成再建立索引。有實踐為證，億級表無索引遷移需要約10分鐘，有索引遷移約需要50個小時；
hint語句：加上append、nologging、parallel等能極大優化效率；
如果是分區表，可單張分區表獨立遷移。
無限容量數據庫架構總結