PostgreSQL+CITUS在蘇寧物流經營結算中的實踐-企業應用專場 + 內核專場（33頁）.pdf

1、PostgreSQL+CITUS在蘇寧物流經營結算中的實踐姓名：薛俊郵箱：公司：蘇寧科技集團云軟件公司CITUS應用實踐的問題蘇寧物流經營結算產品介紹蘇寧物流經營結算技術演進路線蘇寧物流經營結算產品介紹 數據接收：業務主數據、訂單、狀態等數據 數據處理：數據分揀、數據預處理 計費：計算單筆費用 記賬：生成日賬單、月賬單、客戶賬單 結算：生成結算單據 支付開票：客戶確認賬單，支付開票 報表管理：多維度報表、經營分析計費平臺計費平臺計費平臺能力業務鏈路業務鏈路處理量級處理量級最大處理能力最大處理能力(TPS)接收物流服務平臺訂單億級/天2000+預處理物流服務平臺訂單億級/天2000+接收物流服務

2、查詢系統狀態數據億級/天5000+接收快遞服務系統包裹掃描信息千萬級/天1000+預處理快遞服務系統包裹掃描信息千萬級/天1000+接收物流分撥中心裝卸車信息千萬級/天1000+蘇寧物流經營結算技術演進路線 2006年以前ERP2006 SAP+DB2 2015JAVA+DB2 2017JAVA+PG經營結算歷史傳統架構單機(SAP)1.數據孤島2.數據中心化3.機器性能瓶頸4.數據丟失風險極大DB2CLIENT傳統分庫分表架構(JAVA+DB2)APP2APP1APP3APPN中間件DB1DB1DB1DB2DB1DB1DB1DB2DB1DB1DB1DB2DB1DB1DB1DB2現有架構(JA

3、VA+PG+CITUS)WORKERWORKERWORKERWORKERMASTERAPP1APP1APPNmasterworkerworkerworkerworker本地表分片表:參考表:明細表明細表明細表明細表明細表明細表明細表明細表維表維表維表維表維表維表維表維表Citus插件Citus插件Citus插件Citus插件Citus插件現有架構(JAVA+PG+CITUS)選擇現有架構的原因傳統分庫分表(DB2)PG+CITUSDB2維護成本巨大開源，成功實施案例分片字段變更很麻煩 平滑擴容，邏輯復制，業務影響小機器擴容，開發需要做數據規整，有額外開發工作量和額外的清理冗余，業務數據影響范圍

4、大將開發從復雜的分庫分表邏輯中釋放出來，更加專注于業務分庫分表SQL 限制多單表操作跨庫JOIN，開發需輪循多庫，效率低下可跨庫JOIN應用層需管理數據路由，應用改造成本高蘇寧物流經營結算系統規模應用集群近百臺數據庫共有15套CITUS集群，近千臺機器，規模最小的1CN 4 WORKER,規模最大的為1CN 32WORKER 3擴展WK 節點集群數據量級最大的數據總量近20T，其他集群數據量級平均10T。多張分片表的數據量級在50億以上，最大的一張分片表總數據量接近200億，單個分片在億級以上DB2應用實踐 分庫分表規則PG+CITUS手動編寫分庫分表規則，維護工作量大定義好分片數量自動分片應

5、用實踐 分頁查詢DB2PG+CITUS輪循每個庫每張表后進行合并分頁客戶端多線程查詢后合并分頁這個功能我們做不了結果集稍大即產生OOMSelect*from table limit.數據量級幾十億級，傳統分庫分表怎么解？索引太多，性能怎么保證？磁盤空間怎么辦？應用實踐 復雜查詢應用實踐 復雜查詢DB2PG+CITUS每個查詢條件建立索引索引占用磁盤空間太大輪循多庫多表性能極差創建GIN索引一堆腳本，心力憔悴！應用實踐 生產發布應用實踐 生產發布DB2PG+CITUS每個庫每張表都要寫腳本容易出錯，檢查腳本耗時耗力，發布風險高創建單份腳本一次執行應用實踐 分片擴容DB2PG+CITUS新增新的分

6、庫分表規則編寫數據遷移任務，重新按照新的規則進行分布出錯概率極大，定位問題難度極高應用遷移任務效率低，需要停機，業務中斷影響大創建新的分片表在集群內直接使用copy進行數據遷移Rename 表名應用實踐 數據庫擴容DB2PG+CITUS數據重新打散分布整庫復制，開發需要寫應用刪除多余數據停機時間長，業務影響大物理復制刪除元數據和表停機時間縮短一半以上，業務影響小CITUS應用實踐的問題CITUS應用實踐的問題問題1 CN瓶頸1.在100多臺APP的高并發請求下，單CN會存在瓶頸問題，CPU使用率會持續在70%以上2.當應用集群數量太多，CN節點連接數不變的情況下，每臺應用分配的連接數過小，在高

7、并發下應用會獲取不到連接解決方案：1.提高CN機器配置，比如虛機換物理機，調整CN節點連接數（臨時）2.使用擴展WK，將單CN變為多CN（長期）PostgreSQLPostgreSQLApp(普通)App(普通)Appworkerworkerpgbouncer包含元數據包含參考表數據不包含分片表數據實時同步CN的DDL變更擴展worker為可選組件pgbouncerPostgreSQLCoordinator擴展worker(MX node)擴展worker(MX node)PostgreSQLpgbouncerPostgreSQLpgbouncermetadatatb1PostgreSQLPo

8、stgreSQLworkerworkerpgbouncerpgbouncermetadatatb1metadatatb1tb1_1tb1_2tb1_3tb1_4 應用通過JDBC多主機URL訪問擴展worker jdbc:postgresql:/$擴展worker1,$擴展worker2,./$dbname?targetServerType=any&loadBalanceHosts=true&CITUS應用實踐的問題問題2 連接控制SQL中不帶分片字段時，CN對所有worker上的所有分片同時發起連接，并執行SQL。在高并發場景或慢SQL場景下很容易引起CPU/IO飆升或者連接數不夠用的情況，

9、并且壓測時性能上不去；解決方案：1.降低并發處理（臨時）2.添加索引表，強制走分片（長期）WKWKWKWKCN請求請求請求請求請求WKWKWKWKCN請求2請求2請求1請求1CITUS應用實踐的問題問題3 超大分片Citus只支持一個維度(字段)的分片，對于某些大數據量場景，即使分成128片，每個分片表仍然有上億數據，不易維護。比如現有合作伙伴分片表，總量在137個億左右，128分片，在任務啟動撈取數據，或者按時間段查詢數據時，底表數據量級太大，會使得集群的IO使用瞬間100%解決方案：1.擴容分片數，減少單個分片的數據量。從業務發展考慮，合理評估分片數2.數據歸檔，保留半年時間的數據3.按時

10、間分區，優化帶時間范圍的查詢CITUS應用實踐的問題問題5 數據庫擴容現有數據庫擴容采用的是物理復制方法，需要停機操作，在業務上沒有做到完全的業務無感知的地步，并且物理復制需要整數倍操作，對機器資源要求較高。解決方案：1.將物理服務改造成邏輯復制，可以擴容任意節點的WK，無需整數倍開啟任務創建一個分片遷移任務將新WK節點加入到集群中任務管理結束任務停止業務訪問數據庫停止所有CN和Worker備庫提升新Worker為“主”恢復業務讀寫DROP新老Worker上的冗余分片修改元數據添加新Worker到Citus集群總結 實現了去IOE，擁抱開源 系統擴展能力得到了加強 使開發能夠更加專注于應用層開發 為未來多機房部署，實現多活提供了很好的方案