SaaS訂單中心作用
爲垂直領域的商家提供訂單管理能力，管理線上（各種互聯網平臺渠道）、線下等不同渠道的訂單；
需求分析
只是爲商家端提供訂單管理能力，其特點是訪問頻次低，查詢數據量大，需要支持靈活的訂單查詢，能夠容忍一定的延時（相對於C端）；
存儲方案設計
- 讀寫分離：寫請求到主庫，讀請求到備庫（主備同步有ms級別延時，實時性要求特別高的可以顯式指定主庫）；
- 水平拆分 + 基因法：按照商戶id水平拆分，訂單id中融入商戶id分庫基因來支持基於訂單id的查詢；
- 垂直拆分 + 信息冗餘：訂單表數據過多時需要垂直拆分，訂單表只保留最核心的數據，其餘屬性拆分成單獨的表，同時可以在訂單表中冗餘部分經常被查詢到的信息，提高查詢效率；
- ES外置索引：利用ES聚合分表數據，同時建立到訂單id的索引；（通過ES支持複雜的查詢，獲得訂單id，然後從DB查詢訂單信息，ES只是存儲索引，不存儲訂單數據，因爲存儲成本太高）
- 冷熱分離/數據歸檔：訂單中心的特點是時間越久被訪問的頻次越低，可以按照時間維度劃分冷人數據，冷數據歸檔存儲到OSS等雲存儲上（便宜、彈性且支持多種計算引擎），既可以讓數據庫瘦身保持性能，同時也能降低存儲成本；
數據傾斜方案
現象： 按照門店或商家分庫分表時，由於個別門店/商家訂單數據量大，導致分表數據不均勻，個別分表數據量特別多；
影響： 如果不擴容，個別分表的容量會特別大，出現性能問題，影響到同個分表的其它門店或商家；如果擴容，導致空間浪費，因爲大部分分表並不需要擴容；
方案1：均勻打散
方案： 數據量大的門店或商家均勻打散到各分表中（門店id固定無法均勻打散，需使用隨機因素），其它門店或商家仍按照門店id分表，通過ES聚合分表數據，查詢時先查詢ES到訂單id及其所在分表，然後從數據庫查詢對應的訂單；
缺點： 數據量大的門店或商家無法直接按照門店查詢數據庫，需要先查詢ES外置索引，查詢時延增加；
方案2：獨立存儲
方案： 數據量大的門店或商家存儲到單獨的表，其它門店或商家仍按照門店id分表，通過ES聚合分表數據，查詢時先查詢ES獲取到訂單id及其所在分表，然後從數據庫查詢對應的訂單；
缺點： 需要先查詢ES外置索引，查詢時延增加，門店或商家數據量大時仍需要考慮分表；
參考：