如何構建千萬使用者級別 後臺資料庫架構設計的思路
阿新 • • 發佈：2019-01-28
關於如何構建千萬級別使用者的後臺資料庫架構話題，在ITPUB及CSDN論壇都有不少網友提問，新型問答網站知乎上也有人提問，並且順帶梳理了下思路，方便更多的技術朋友有章可循，整理一篇拋磚引玉性的文章。
一、技術朋友給出的背景資料：
(1). 網站型應用，主要指：SNS社交網站、新聞門戶型網站、郵件系統、SNS Game社交遊戲、電子商務網站、即時通訊IM等型別系統；
(2). 註冊使用者為千萬級別，也即1KW註冊使用者以內；
二、要求
構建千萬級別使用者的後臺資料庫架構分析思路，對資料層架構設計的有章可循，必須考慮資料量的大小，以及資料庫提供服務的效能和系統的可靠性，適當地考慮使用者量超過，以及需要使用的伺服器資源等資訊。
三、構建千萬級別使用者的後臺資料庫架構的分析思路
曾經發過一篇文章，關於千萬級別使用者應用架構設計的歌謠，供大家參考 千萬級架構設計訣竅，接下來我們針對如何構建千萬級別使用者的後臺資料庫架構，給出通用性分析思路的建議，未必完全靠譜，但求基本靠譜（注：畢竟很多事情需要看具體業務而定的）：
(1). 一定要區分業務型別，可能達到千萬使用者級別的應用業務場景，可歸類描述為： SNS社交平臺、SNS社交遊戲、即時通訊IM系統、電子商務、郵件系統、新聞入口網站等，這些不同型別的業務場景做法會不一樣，主要是由他們業務性質決定，後續分析項中逐一描述；
(2). 應用業務的核心KPI數值，產品每天的日活躍使用者量大概多少？若是網站型別應用，還需要加入其他引數PV,UV等資料輔助決策，即時通訊IM的訊息量，郵件系統的新增郵件數，SNS社交平臺的Feeds量等核心資料；
(3). 系統中每個使用者可能產生的資料量大概多大，分固定部分，以及動態部分的方式統計分析，對非固定部分以參考值和結合實踐跨度（註釋：1年為硬性指標，2年為預期，3年可選，再長的時間段不考慮）的方式進行分析，然後預測出整個系統的使用者鎖產生的資料條數和資料容量大概的估值；
(4). 註冊使用者並不等於活躍使用者，為此需要預估日活躍使用者量大概多少？周活躍使用者量大概？月活躍使用者量大概多少？系統設計的最高併發量為多少？這數字還是非常有必要，不管是對資料量預估，還是對技術實現方案的選擇都有幫助；
(5). 根據應用業務的特點，以及系統不同模組的功能特點，初期必須判斷出可能負載最大的系統模組，對於可以靜態化模組或功能，儘量要Cache起來，以降低系統的負載和提高前端響應速度；若是非Cache技術能解決的，是否可以考慮獨立或通過整體水平擴充套件方式解決系統的負載和效能問題；
(6). 針對系統中各個模組的功能或業務特點，大致那些使用者資料會累計比較大，以及那些資料操作頻率比較高；
(7). 不同的業務其對資料操縱不一樣，要大致明白自己的應用：讀寫比如關係，也即：SELECT:UPDATE:DELETE:UPDATE=？；
(8). 系統的整體架構中，必須考慮系統的穩定性、負載均衡和響應速度，為此必須考慮一些模組藉助Cache、非同步、訊息佇列等技術，進行一些特殊處理或折中做法，以達到目標；
(9). 若使用MySQL資料庫產品作為後臺資料庫提供資料服務，建議儘量使簡潔的SQL語句，並不是說不用JOIN，而是要考慮MySQL對JOIN的實現演算法，符合Nested loop join優缺點中的優點；
(10). 資料庫結構設計
既然說是構建千萬級別使用者的後臺資料庫架構，前面講清楚如何熟悉和理解業務模型，清楚系統可能存在的瓶頸、技術難度，以及一些技術實現方案，現在必須迴歸到資料庫設計階段。
開始討論如何收集、分析和設計資料庫結構之前，我們先簡單地對資料庫，什麼情況下要考慮進行水平拆分？尤其針對網際網路行業流行的資料庫產品MySQL來討論，各大資料庫技術論壇或個人部落格型技術網站，有不少名言式的基調：資料量超過100W，就需要分表，MySQL無法支援大資料量的服務等等？
以前的MySQL（主要指：MySQL5.0以前版本）版本確實存在諸多問題，以及當時跑MySQL的伺服器一般都是超低配置，還依然記得當時我們的資料庫伺服器最高也就8G記憶體，一般都是2G記憶體，硬碟都是單盤且轉速是10K，甚至7500轉的，而當時大多主流資料庫產品Oracle跑的伺服器配置卻很少這麼差。我們大家要一時俱進，技術人員尤其DBA或架構師，要學會以資料說話，以其中一測試用例，DELL 2950 4*15K*146G RAID1+0 ，16G記憶體，E5410 CPU*2 ，一張分31個分割槽的區表業務模型只有INSERT+SELECT，且以50個INSERT+10個SELECT執行緒併發執行，總記錄寫入資料量6KW行左右，單表資料容量超過100G，併發從最高的9100 TPS/S下降到8700 TPS/S之後就穩定在此值。
上面論述MySQL支援大表並沒有太大的效能方面的下降，但是並不表示筆者建議大家這麼做，至少有二點MySQL的備份和資料庫結構變更非常麻煩，尤其資料庫結構變更其特殊的做法，使其成為一大瓶頸，也不知道要犧牲我們多少DBA的睡眠，具體的資訊大家可以參考文章MySQL資料庫生產環境維護，但是對於新聞內容的儲存需求，可以把新聞主題內容單獨放到一張表中，以子表的方式存在，提供資料伺服器，且該資料很少做變更，一般情況下是INSERT之後就只有讀為主，那麼就不會是任何問題，阿里巴巴旺旺彈出的新聞頁面的內容就是採用此方式儲存，當時單表容量接近1T，早高峰的時候也不會出現伺服器效能問題，以及系統負載都非常穩定。
我們繼續回到構建千萬級別使用者的後臺資料庫架構的話題上，具體建議或做法如下所示：
10.1> 資料庫的設計開始之前，必須優先進行業務的資料流梳理（註釋：必須儘量考慮應用所有可能的功能模組），以及對業務優先進行優化和規劃，然後根據資料流和功能 考慮資料庫的結構設計和優化；
10.2> 千萬級別使用者量，若是非遊戲行業的產品（SNS遊戲除外），建議考慮使用者資料拆分架構設計，以及考慮後續未來1-2年的承受量，若是SNS平臺必須考慮拆分，除非考慮上SSD、Fusion-io、儲存等更高階的裝置，用金錢換時間的方式支援技術改造；
10.3> 資料拆分的核心與難處：同一個使用者的資料儘量放一起（拆分規則要儘量簡單可執行），拆分之後使用者關係的資料如何儲存的抉擇有多種（存2份或存1份放一個地方），難處資料的分頁，統計合併等；
10.4> 要考慮一些冗餘的方式解決SQL效能問題，但是又不能過多引入冗餘而造成IO開銷增加太多，冗餘欄位要儘量整型欄位；
10.5> 資料庫表物件的欄位屬性，要儘量考慮數字化，尤其遊戲行業；
10.6> 資料庫設計過程中，對於索引組織結構要偏向共同操作最優先，其次應用外部使用者級別的操作效能優先，最後內部使用者的操作，硬儘量隔離，例如：搜尋引擎Build操作、內部編輯團隊稽核等操作；
10.7> 資料庫要從設計角度規避一些無法通過其他技術手段解決的模糊查詢，類似全文索引的模糊查詢，要走搜尋引擎的模式，再通過資料庫讀具體的資料，一些必要的計數型別的資料，適當地考慮快取；
10.8> 重點解決資料庫級別的資料分頁問題，要學會從前端應用使用者的體驗不降低的情況下，達到更高效的資料分頁做法，類如論壇中帖子分樓的做法；
10.9> 資料庫的設計必須考慮使用什麼型別配置的物理伺服器，核心引數：記憶體、CPU、硬碟（這個是關鍵：硬碟型別（注： SATA、SAS、SSD）、多少塊盤、轉速、容量，以及做RAID幾），RAID卡記憶體及RAID寫模式也需要考慮進去，必須結合資料量和讀寫能力要求進行一個預算規劃，不一定超準確，但是要八九不離十；
【結束】
主要是想通過回答網友的提問“如何構建千萬使用者級別後臺資料庫”，把對於此類使用者級別通用性分析和設計的思路描述清楚，實在不善於文字描述，可能很多地方沒有講述到位，還請各位一起補充完畢和糾正。
一、技術朋友給出的背景資料：
(1). 網站型應用，主要指：SNS社交網站、新聞門戶型網站、郵件系統、SNS Game社交遊戲、電子商務網站、即時通訊IM等型別系統；
(2). 註冊使用者為千萬級別，也即1KW註冊使用者以內；
二、要求
構建千萬級別使用者的後臺資料庫架構分析思路，對資料層架構設計的有章可循，必須考慮資料量的大小，以及資料庫提供服務的效能和系統的可靠性，適當地考慮使用者量超過，以及需要使用的伺服器資源等資訊。
三、構建千萬級別使用者的後臺資料庫架構的分析思路
曾經發過一篇文章，關於千萬級別使用者應用架構設計的歌謠，供大家參考 千萬級架構設計訣竅，接下來我們針對如何構建千萬級別使用者的後臺資料庫架構，給出通用性分析思路的建議，未必完全靠譜，但求基本靠譜（注：畢竟很多事情需要看具體業務而定的）：
(1). 一定要區分業務型別，可能達到千萬使用者級別的應用業務場景，可歸類描述為： SNS社交平臺、SNS社交遊戲、即時通訊IM系統、電子商務、郵件系統、新聞入口網站等，這些不同型別的業務場景做法會不一樣，主要是由他們業務性質決定，後續分析項中逐一描述；
(2). 應用業務的核心KPI數值，產品每天的日活躍使用者量大概多少？若是網站型別應用，還需要加入其他引數PV,UV等資料輔助決策，即時通訊IM的訊息量，郵件系統的新增郵件數，SNS社交平臺的Feeds量等核心資料；
(3). 系統中每個使用者可能產生的資料量大概多大，分固定部分，以及動態部分的方式統計分析，對非固定部分以參考值和結合實踐跨度（註釋：1年為硬性指標，2年為預期，3年可選，再長的時間段不考慮）的方式進行分析，然後預測出整個系統的使用者鎖產生的資料條數和資料容量大概的估值；
(4). 註冊使用者並不等於活躍使用者，為此需要預估日活躍使用者量大概多少？周活躍使用者量大概？月活躍使用者量大概多少？系統設計的最高併發量為多少？這數字還是非常有必要，不管是對資料量預估，還是對技術實現方案的選擇都有幫助；
(5). 根據應用業務的特點，以及系統不同模組的功能特點，初期必須判斷出可能負載最大的系統模組，對於可以靜態化模組或功能，儘量要Cache起來，以降低系統的負載和提高前端響應速度；若是非Cache技術能解決的，是否可以考慮獨立或通過整體水平擴充套件方式解決系統的負載和效能問題；
(6). 針對系統中各個模組的功能或業務特點，大致那些使用者資料會累計比較大，以及那些資料操作頻率比較高；
(7). 不同的業務其對資料操縱不一樣，要大致明白自己的應用：讀寫比如關係，也即：SELECT:UPDATE:DELETE:UPDATE=？；
(8). 系統的整體架構中，必須考慮系統的穩定性、負載均衡和響應速度，為此必須考慮一些模組藉助Cache、非同步、訊息佇列等技術，進行一些特殊處理或折中做法，以達到目標；
(9). 若使用MySQL資料庫產品作為後臺資料庫提供資料服務，建議儘量使簡潔的SQL語句，並不是說不用JOIN，而是要考慮MySQL對JOIN的實現演算法，符合Nested loop join優缺點中的優點；
(10). 資料庫結構設計
既然說是構建千萬級別使用者的後臺資料庫架構，前面講清楚如何熟悉和理解業務模型，清楚系統可能存在的瓶頸、技術難度，以及一些技術實現方案，現在必須迴歸到資料庫設計階段。
開始討論如何收集、分析和設計資料庫結構之前，我們先簡單地對資料庫，什麼情況下要考慮進行水平拆分？尤其針對網際網路行業流行的資料庫產品MySQL來討論，各大資料庫技術論壇或個人部落格型技術網站，有不少名言式的基調：資料量超過100W，就需要分表，MySQL無法支援大資料量的服務等等？
以前的MySQL（主要指：MySQL5.0以前版本）版本確實存在諸多問題，以及當時跑MySQL的伺服器一般都是超低配置，還依然記得當時我們的資料庫伺服器最高也就8G記憶體，一般都是2G記憶體，硬碟都是單盤且轉速是10K，甚至7500轉的，而當時大多主流資料庫產品Oracle跑的伺服器配置卻很少這麼差。我們大家要一時俱進，技術人員尤其DBA或架構師，要學會以資料說話，以其中一測試用例，DELL 2950 4*15K*146G RAID1+0 ，16G記憶體，E5410 CPU*2 ，一張分31個分割槽的區表業務模型只有INSERT+SELECT，且以50個INSERT+10個SELECT執行緒併發執行，總記錄寫入資料量6KW行左右，單表資料容量超過100G，併發從最高的9100 TPS/S下降到8700 TPS/S之後就穩定在此值。
上面論述MySQL支援大表並沒有太大的效能方面的下降，但是並不表示筆者建議大家這麼做，至少有二點MySQL的備份和資料庫結構變更非常麻煩，尤其資料庫結構變更其特殊的做法，使其成為一大瓶頸，也不知道要犧牲我們多少DBA的睡眠，具體的資訊大家可以參考文章MySQL資料庫生產環境維護，但是對於新聞內容的儲存需求，可以把新聞主題內容單獨放到一張表中，以子表的方式存在，提供資料伺服器，且該資料很少做變更，一般情況下是INSERT之後就只有讀為主，那麼就不會是任何問題，阿里巴巴旺旺彈出的新聞頁面的內容就是採用此方式儲存，當時單表容量接近1T，早高峰的時候也不會出現伺服器效能問題，以及系統負載都非常穩定。
我們繼續回到構建千萬級別使用者的後臺資料庫架構的話題上，具體建議或做法如下所示：
10.1> 資料庫的設計開始之前，必須優先進行業務的資料流梳理（註釋：必須儘量考慮應用所有可能的功能模組），以及對業務優先進行優化和規劃，然後根據資料流和功能 考慮資料庫的結構設計和優化；
10.2> 千萬級別使用者量，若是非遊戲行業的產品（SNS遊戲除外），建議考慮使用者資料拆分架構設計，以及考慮後續未來1-2年的承受量，若是SNS平臺必須考慮拆分，除非考慮上SSD、Fusion-io、儲存等更高階的裝置，用金錢換時間的方式支援技術改造；
10.3> 資料拆分的核心與難處：同一個使用者的資料儘量放一起（拆分規則要儘量簡單可執行），拆分之後使用者關係的資料如何儲存的抉擇有多種（存2份或存1份放一個地方），難處資料的分頁，統計合併等；
10.4> 要考慮一些冗餘的方式解決SQL效能問題，但是又不能過多引入冗餘而造成IO開銷增加太多，冗餘欄位要儘量整型欄位；
10.5> 資料庫表物件的欄位屬性，要儘量考慮數字化，尤其遊戲行業；
10.6> 資料庫設計過程中，對於索引組織結構要偏向共同操作最優先，其次應用外部使用者級別的操作效能優先，最後內部使用者的操作，硬儘量隔離，例如：搜尋引擎Build操作、內部編輯團隊稽核等操作；
10.7> 資料庫要從設計角度規避一些無法通過其他技術手段解決的模糊查詢，類似全文索引的模糊查詢，要走搜尋引擎的模式，再通過資料庫讀具體的資料，一些必要的計數型別的資料，適當地考慮快取；
10.8> 重點解決資料庫級別的資料分頁問題，要學會從前端應用使用者的體驗不降低的情況下，達到更高效的資料分頁做法，類如論壇中帖子分樓的做法；
10.9> 資料庫的設計必須考慮使用什麼型別配置的物理伺服器，核心引數：記憶體、CPU、硬碟（這個是關鍵：硬碟型別（注： SATA、SAS、SSD）、多少塊盤、轉速、容量，以及做RAID幾），RAID卡記憶體及RAID寫模式也需要考慮進去，必須結合資料量和讀寫能力要求進行一個預算規劃，不一定超準確，但是要八九不離十；
【結束】
主要是想通過回答網友的提問“如何構建千萬使用者級別後臺資料庫”，把對於此類使用者級別通用性分析和設計的思路描述清楚，實在不善於文字描述，可能很多地方沒有講述到位，還請各位一起補充完畢和糾正。