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节点连接数不变