本文源自今年系統架構師大會，我在會上分享《資料庫工程架構實踐》的前3頁PPT，資料庫架構設計中的一些基本概念。
畫外音：會上分享了近4個小時.
所有概念均以“使用者中心”舉例。
畫外音：這是一個提供使用者注冊、登入、資訊查詢與修改的常見業務。
一、單庫架構
- user-service：使用者中心服務，對調用者提供友好的RPC接口
- user-db：一個庫進行資料存儲
二、分組架構
資料庫分組架構，即最常見的一主多從，主從同步，讀寫分離資料庫架構：
user-service：依舊是使用者中心服務user-db-M(master)：主庫，提供資料庫寫服務user-db-S(slave)：從庫，提供資料庫讀服務主和從構成的資料庫叢集稱為“一組”。
同一個組裡的資料庫叢集：
主從之間通過binlog進行資料同步多個執行個體資料庫結構完全相同多個執行個體存儲的資料也完全相同，本質上是将資料進行複制 資料庫分組架構究竟解決什麼問題？大部分網際網路業務讀多寫少，資料庫的讀往往最先成為性能瓶頸，如果希望：線性提升資料庫讀性能通過消除讀寫鎖沖突提升資料庫寫性能通過備援從庫實作資料的“讀高可用”此時可以使用分組架構，需要注意的是，分組架構中，資料庫的主庫依然是寫單點。 一句話總結，分組解決的是“資料庫讀寫高并發量高”問題，常實施的架構設計。 三、分片架構
資料庫分片架構，是大夥最常說的水準切分(sharding)：
user-service：依舊是使用者中心服務user-db1：水準切分成2份中的第一份user-db2：水準切分成2份中的第二份分片後，多個資料庫執行個體也會構成一個資料庫叢集。 水準切分，到底是分庫還是分表？強烈建議分庫，因為：分表依然公用一個資料庫檔案，仍然有磁盤IO的競争分庫能夠很容易的将資料遷移到不同資料庫執行個體，甚至資料庫機器上，擴充性更好畫外音：當然，分庫後，資料庫連接配接數會更多。
如何進行水準切分？常見的方法是“範圍法”和“哈希法”：
範圍法如上，以使用者中心的業務主鍵uid為劃分依據，将資料水準切分到兩個資料庫執行個體上去。
哈希法如，也是以使用者中心的業務主鍵uid為劃分依據，将資料水準切分到兩個資料庫執行個體上去。
畫外音：本例中雜湊演算法是“取模”。
哈希法在網際網路資料庫架構中，使用較為廣泛。 分片架構，同一個叢集裡的各個分片：多個執行個體之間本身不直接産生聯系，不像主從間有binlog同步多個執行個體資料庫結構，也完全相同多個執行個體存儲的資料之間沒有交集，所有執行個體間資料并集構成全局資料 分片架構究竟解決什麼問題？大部分網際網路業務資料量很大，單庫容量容易成為瓶頸，此時通過分片可以：線性提升資料庫寫性能，需要注意的是，分組架構是不能線性提升資料庫寫性能的降低單庫資料容量 一句話總結，分片解決的是“資料庫資料量大”問題，常實施的架構設計。 四、分組+分片架構
如果業務讀寫并發量很高，資料量也很大，通常需要實施分組+分片的資料庫架構：
通過分片來降低單庫的資料量，線性提升資料庫的寫性能通過分組來線性提升資料庫的讀性能，保證讀庫的高可用畫外音：大部分線上的真實架構，是這樣子的。
五、垂直切分資料庫垂直切分，也是一類常見的資料庫架構設計，垂直切分一般和業務結合比較緊密。
還是以使用者中心為例，可以這麼進行垂直切分：
User_Base(uid, uname, passwd, sex, age, …)User_EX(uid, intro, sign, …)垂直切分開的表，主鍵都是uid登入名，密碼，性别，年齡等屬性放在一個垂直表（庫）裡自我介紹，個人簽名等屬性放在另一個垂直表（庫）裡 如何進行垂直切分？根據業務對資料進行垂直切分時，一般要考慮屬性的“長度”和“通路頻度”兩個因素：長度較短，通路頻率較高的放在一起長度較長，通路頻度較低的放在一起這是因為，資料庫會以行(row)為機關，将數load到記憶體(buffer)裡，在記憶體容量有限的情況下，長度短且通路頻度高的屬性，記憶體能夠load更多的資料，命中率會更高，磁盤IO會減少，資料庫的性能會提升。
垂直切分和水準切有相似的地方，又不太相同：
多個執行個體之間也不直接産生聯系，即沒有binlog同步多個執行個體資料庫結構，都不一樣多個執行個體存儲的資料之間至少有一列交集，一般來說是業務主鍵，所有執行個體間資料并集構成全局資料 垂直切分解決什麼問題？垂直切分即可以降低單庫的資料量，還可以降低磁盤IO進而提升吞吐量，但它與業務結合比較緊密，并不是所有業務都能夠進行垂直切分的。
文章較長，簡單總結：業務初期用單庫讀壓力大，讀高可用，用分組資料量大，寫線性擴容，用分片屬性短，通路頻度高的屬性，垂直拆分到一起 希望大夥有收獲。
畫外音：3頁ppt寫這麼多真是累，其他91頁ppt咋整呢？
本文轉自“架構師之路”公衆号，58沈劍提供。