1. 导言
日前，中国电商ERP系统开发商龙头之一万里牛, 在其ERP系统中引入了阿里云瑶池旗下的云原生数据库PolarDB，借助PolarDB一站式事务处理和数据分析解决方案，同时利用In-Memory Column Index（IMCI）和并行执行提供的HTAP实时数据分析能力，以及高压缩引擎X-Engine提供的低成本海量记录读写能力，实现了SaaS ERP系统的“增效降本”，解决了ERP SaaS平台客户数据快速增长后的复杂查询分析效率难题，以及历史订单记录数增长带来的存储成本飙升难题，通过一站式的解决方案快速满足业务发展。
2. 关于万里牛
万里牛是湖畔网络旗下的产品品牌，万里牛以ERP为核心，形成包括WMS、跨境ERP、BI、门店零售、云订货等在内的产品矩阵，服务于开展国内电商、跨境电商和实体门店等零售业务场景的企业，经过多年发展，万里牛已成为国内电商ERP领域的龙头SaaS服务提供商。
万里牛基于阿里云丰富的云产品体系构建其电商SaaS平台。在数据库方面，大量使用了OLTP型产品PolarDB MySQL、RDS MySQL，NoSQL使用了Redis、Lindorm等，在OLAP型产品方面，使用了在线数仓、离线分析产品，通过产品和方案的组合来满足电商SaaS各个业务模块对数据库的多种需求。
3. 万里牛电商SaaS ERP系统
在电商领域，ERP系统可以帮助商家降低履约成本，提升作业协同效率，同时助力提高企业管理效率，涉及到电商业务流程的各个方面，覆盖订单处理、仓储管理、采购协同、分销管理、库存管理、售后工单、业财一体、数据分析等各个模块。
3.1 订单管理（OMS)
订单处理是万里牛ERP的核心模块，万里牛支持来自200多个国内外电商平台的订单通过实时同步方式下载到ERP中。一旦订单被下载，系统会根据自动化匹配策略，选择最合适的仓库、快递和是否需要拆单，以确保最快履约和最低成本。超过90%的订单通常会自动进入下一步，通过智能策略进行处理，而其他订单则需要进行人工审核，通过客服与消费者的沟通来决定是否延迟发货或进入售后环节。如果消费者通过线上平台提交退款或退换货申请，订单会自动处理，无需人工介入。
3.2 仓储管理（WMS）
订单经过人工或自动化审核后，会进入万里牛智能仓储系统的作业环节。在这里，仓库工作人员会进行打单、分拣、打包、验货、称重和出库等全流程，以确保消费者能尽早收到自己心仪的宝贝。当然，系统也有多项智能策略来提高仓内作业效率。每一个商品都按照标准的库位号、货架号、层数等整齐地存放在货架上，拣货员可以使用播种拣货模式，自动带入任务，依序将订单放入对应的播种框中，按照PDA提示到达指定库位，扫描条码将商品放入指定的播种框中。使用PDA指导，仓储作业人员可以通过单次“S”型路径，走更少的步数拿更多的货，快速高效地完成该波次下所有订单的拣货任务，省时省力。
3.3 数据管理
基于万里牛ERP中庞大的商品、订单数据，搭配万里牛ERP里的几十张多维度报表和BI工具，轻松实现高效、全面的数据分析和决策支持。其中，多环节报表集合能够实现全场景数据的覆盖，让用户一目了然地掌握企业各个环节的数据情况。预设数据分析模板则为用户提供了量化业务环节的核心指标，帮助他们更加全面地分析和把握企业的运营情况。
零代码自定义搭建数据看板是另一个非常实用的功能，它能够让用户轻松抓取核心业务信息，无需编写代码或拥有专业技能，通过拖拉拽的形式让用户能够快速建立自己的数据看板，实现高效的数据分析和管理。此外，账号自定义权限设置能够保障用户数据安全，让企业内部数据不被泄露或滥用。最后，销量预测、库存预警等智能分析能够灵活配合市场决策，让企业的决策更加准确和高效。
万里牛ERP数据库采用典型的SaaS多租户架构，某个商家的慢SQL可能影响同数据库上其他商家系统卡和慢，同时订单管理作为ERP的核心，也是数据密集型应用，对数据写入和分析实时要求高，在多租户架构下，慢SQL雪崩效应可能进一步放大，因此，解决慢SQL能够有效提升客户体验和降低系统运行风险。
4. 增效：PolarDB IMCI提升访问体验
万里牛ERP最初使用MySQL作为核心数据库，在早期数据体量较小、业务模式相对简单的情况下，MySQL支撑了业务发展，但随着公司规模扩大、客户体量逐年增加，业务场景变得越来越复杂，日单超数十万的客户数量也在持续增加。随着直播等新的业态发展，原生MySQL已经无法完全满足各种复杂查询和承受突发的爆单压力。
为解决复杂查询的效率和技术问题，万里牛技术团队采用了PolarDB MySQL提供的In-Memory Column Index功能。
PolarDB一站式HTAP数据库产品解决方案
使用IMCI技术方案，万里牛ERP系统可以在无需额外技术研发投入和业务功能调整的前提下，快速解决众多数据库痛点。以下举例介绍万里牛ERP如何使用IMCI的。
4.1 灵活查询的高效响应
电商ERP面向各个商品类目客户群体，每个类目的业务细节和业务需求多样且差异较大，体现在ERP系统里，订单查询页面就需要实现各种查询项来满足用户使用，同时数据需要进行实时汇总查询，例如库存、快递成本。
审核页面查询项
以选择订单修改快递为例，快递公司会高频的调整快递费用计算规则，计算规则由包裹重量、最大单边长度、收件地区等因素决定，商家需要基于此类条件，快速查询出对应订单，调整快递申请电子面单，否则就会影响发货时效和成本。在使用PolarDB In-Memory Column Index之前，主要依赖于MySQL行存索引能力，但对于类似如下的复杂SQL，如果交易trade存量在1000万以上，查询延时会急剧增加，不能有效保证客户的页面响应时间。
SELECT a.* FROM TRADE a WHERE a.COMPANY = '~7A~' AND a.SHOP IN ('~2F2~', '~D41D4~', '~DB60~') AND a.STORAGE IN ('~6251FA7~', '~72EBD3~', '~47BA~', '~B5C9~') AND (a.MESSAGE LIKE CONCAT('%', '停发11.24', '%') OR a.MEMO LIKE CONCAT('%', '停发11.24', '%') OR a.REMARK LIKE CONCAT('%', '停发11.24', '%')) AND a.STATE = 0 AND STATUS = 0 AND a.weight >= 0 and a.weight <=0.18 AND a.sum >= 1 and a.sum <= 2 AND NOT EXISTS ( SELECT 1 FROM ORDER o WHERE a.UID = o.SUID AND (o.ITEM_ID IN ('~35CA~', '~0325~') OR o.SKU_ID IN ('~0EC46~','~903~', '~82AD~')) ) AND NOT EXISTS ( SELECT 1 FROM ORDER o LEFT JOIN trade t ON o.sys_trade = t.salercpt_uid LEFT JOIN INVENTORY pi ON pi.COMPANY = o.COMPANY AND pi.SKU_ID = o.SKU_ID AND pi.storage_id = t.STORAGE WHERE o.SUID = a.UID AND IFNULL(pi.P_QUANTITY, 0) <= IFNULL(pi.P_LOCK, 0) AND o.COMPANY = '~7A4F4~' AND o.order_status != x );
在引入PolarDB IMCI之前， 对应的订单管理系统SQL监控如下，会存在大量订单查询慢SQL：
使用MySQL慢查询监控
在引入使用PolarDB MySQL之后，我们在原有PolarDB集群上配置一个带列索引的节点，然后在复杂查询的表上创建了列存索引。之后将前述复杂的订单查询请求通过hint注解，直接打到IMCI节点。在trade单量超过1000万数记录条目的场景下，PolarDB IMCI能够大幅度提升查询速度，同时也极大降低了普通业务读写节点的压力。
如下图所示，在使用PolarDB IMCI之后，平均执行时间和最大执行时间都有了大幅降低。在一个8C的计算节点上最大执行时间也都能控制在10S以下，在大促时间通过Serverless弹升计算节点规格，查询时间还能进一步降低。
使用IMCI之后的SQL响应延时监控
4.2 一站式事务处理和实时数据分析
在使用PolarDB IMCI之前， 受限于MySQL的复杂查询效率限制，如果需要在处理日常OLTP业务的同时运行复杂查询和实时报表，通常无法满足报表查询的时延要求。此时，则需要引入其他专门的数仓或者检索系统并将数据同步过去，然后使用两套系统的组合方案，会遇到两个挑战：
数据一致性问题：通常，OLTP系统和下游数仓或者检索系统会通过Binlog进行数据复制， 这个数据同步延迟只能控制在秒级别，且偶尔会出现延迟抖动，导致用户在下游数仓系统查询的数据与ERP系统的OLTP数据中数据不一致性，极大地影响用户体验。 一个典型场景，当上下游数据延迟时， 商家在ERP系统中对某一批订单做发货处理之后，去刷新监控大屏页面查看当前订单的发货统计信息，会发现刚刚已经发货的那批订单还处于未发货状态。
数据冗余及维护： ERP系统本身非常复杂，涉及到非常多的系统组合，因此存在很多库和表。对于万里牛，还有数据量大的难题，引入多套存储系统就会产生重复数据和多套代码实现，不仅浪费开发资源，还会导致高昂的存储成本。
因此传统方案无法有效满足万里牛的需求，PolarDB HTAP是一站式的事务处理和数据分析解决方案，首先在现有PolarDB集群中通过添加列索引即可以让复杂查询提速百倍，免去了维护多套系统的麻烦；其次，PolarDB的列存分析节点通过Redo物理日志与写入节点进行实时数据同步，平时同步延时在亚毫秒且高峰期不超过5ms，再结合PolarDB Proxy的事务一致性读配置，可以实现强一致读写分离。万里牛ERP系统在切换到PolarDB后，借助PolarDB一体化的IMCI ，以很低的开发成本解决了对实时数据做复杂查询的效率问题，不再需要额外的数仓系统。在减少成本的同时，避免了开发资源的浪费，提高了用户体验。
万里牛ERP订单系统数据库实例拓扑
万里牛ERP从22年开始将订单和交易数据存储在PolarDB MySQL上，充分利用了其强大的HTAP能力，针对相关业务代码的调整，只需要在SQL中增加Hint注解即可实现，无额外新增开发成本投入。
在整体使用PolarDB IMCI之后，在单集群8C16G数据库配置，以OMS典型业务场景为例，每小时压测指标如下：
整体而言，大幅加快了ERP业务系统的处理速度，从商家侧来看，万里牛头部某服饰商家反馈说：“万里牛的ERP系统经过近期升级后，给我们感觉更快了，比如审单、发货、物流推送等相关业务流程提速明显，对我们商家来说，可以大幅提升经营效率！”
5. 降本：高压缩引擎X-Engine实现海量交易订单历史存储
作为国内头部的电商ERP SaaS系统开发商，万里牛所管理的数据具有两个特点：
- 数据体量大：考虑到交易订单按时间积累的特征，交易订单库单个表的行数往往达到千万甚至亿级别， 耗费大量的存储成本。
- 周期性明显： 交易数据通常在7天、30天和90天后出现明显的使用热度下降，但考虑到售后等因素，这些数据又不能完全冷归档，对于很多类目产品，如大家电类等售后有效期长的产品需要对历史数据进行修改。
万里牛在使用PolarDB期间，PolarDB研发团队针对历史交易记录/聊天记录等数据量大且访问周期性特征明显的数据存储问题，提出了在线/归档一体化的混合引擎架构， 即在PolarDB 标准版本集群中，除了InnoDB这一事务引擎之外，同时支持实现了X-Engine高压缩引擎。
通过X-Engine这一LSM-tree引擎冷热分层，压缩率高（一般业务在5倍左右）的特性来满足海量数据存储的降本诉求。而X-Engine的事务支持，SQL兼容性与InnoDB基本一致， 对业务开发没有适配成本。用户可以在同一个PolarDB集群中，根据不同表的数据量和访问特点，灵活地选择InnoDB引擎或者X-Engine引擎。并且可以使用DDL语句在这两种引擎之间自由转换。
通过将已发货完结订单存储到同一个Polardb实例的X-Engine高压缩引擎中，实现了数倍的存储成本压缩，而未发货订单继续使用InnoDB引擎。万里牛基于ERP系统不同请求的访问特点，使用了两种访问模式：一种是在页面交互开始时直接区分在线和历史订单查询，另一种是在代码中实现冷热订单的混合查询。最终在用户体验基本不变的情况下，如下图所示，我们调整后的存储总量减少了十几T，每个表的平均压缩比可达1/4，甚至有部分表可以压缩到1/10的大小，总体来看存储成本下降80%。
万里牛ERP部分表使用X-Engine压缩效果
为了进一步降低存储成本，PolarDB可以使用PSL4（PolarStore Level 4）的磁盘，PSL4采用采用阿里巴巴自研的硬件压缩盘（Smart-SSD）技术，在物理SSD磁盘层面压缩、解压缩存储的数据，在保持性能影响可控的情况下，使单位容量数据的存储价格更低。
6.后记
万里牛ERP在订单管理场景下使用PolarDB一站式的事务处理和数据分析解决方案，不仅提升了产品用户体验而且降低了数据层面的研发和维护成本，后续，将进一步推广到其他多数据密集型的ERP系统中，扩大PolarDB在SaaS领域中的使用范围。
近年来，国家政策的鼓励和扶持推动了中小企业、跨境电商、数字政府等领域的数字化转型需求，而企业管理和业务流程的标准化和复杂化，为SaaS企业提供了丰富的应用场景和市场。中国的SaaS服务开发商受益于云计算技术的成熟和普及，从诞生之日起便充分利用云计算平台提供的底层基础设施，以降低开发和运维成本。云原生数据库PolarDB的HTAP能力和高压缩引擎能力是两个典型适用于头部SaaS客户的功能，高压缩引擎能力致力于让客户以更低的成本存储更多的数据，并从数据中发现商机；HTAP能力让SaaS企业无需使用复杂架构即可提升对海量数据的查询分析效率，为客户提升更好的体验，助力提升SaaS企业商业化能力，进而帮助客户带来自身业绩的增长。
