客户说 | 单实例100TB 客如云引入云原生数据库PolarDB支撑亿级存储

阿里云瑶池数据库 10-08 117

前言：

现时我们对“云数据库mysql引擎集群版实例所有版本都支持”大概比较着重，看官们都需要了解一些“云数据库mysql引擎集群版实例所有版本都支持”的相关内容。那么小编同时在网上搜集了一些关于“云数据库mysql引擎集群版实例所有版本都支持””的相关资讯，希望我们能喜欢，咱们一起来了解一下吧！

作者：客如云DBA 李国标

近日，国内头部餐饮SaaS服务提供商客如云使用阿里云瑶池旗下的云原生数据库PolarDB来支持其交易订单的存储和读写访问需求。通过将原始千亿行记录规模，大小超100TB的订单库存放到单个PolarDB MySQL高压缩引擎X-Engine实例中，最终实现了超过5倍的数据压缩率，节省了大量的存储成本。

客如云业务介绍

客如云，是一家面向餐饮、零售、美业等本地生活服务业商家的公司，提供软硬一体的SaaS整体解决方案，帮助商家实现数字化、智能化升级，最终实现 “店开天下，客如云来”的愿景。客如云坚持以工具，连接，数据的三层金字塔产品价值，通过软硬一体、云端结合的SaaS工具，连接餐饮上下游生态的开放平台和基于数据的丰富增值服务，帮助中国数以千万计的中小本地生活商家，实现全业务的数字化，使得经营管理效率更高，营销获客成本更低。客如云提供的服务包含如下三层：

第一层：SaaS软硬件工具层。以第二代迷你智能收银一体机 OnPOS mini 2C、智能收银一体机 OnPOS 2C、OnPOS mini 2、第二代智能收银一体机 OnPOS 2、迷你智能收银一体机 OnPOS mini、手持智能收银 OnPOS Handset等智能收银一体机；红云2、2F智能收银机；红云2W智能称重收银机和第二代立式自主收银一体机 OnKiosk Tower 2、立式自主收银一体机 OnKiosk Tower、桌面式自助收银OnKiosk Tablet智能自助设备等智能终端为载体，通过软硬一体的SaaS模式，搭载融合了点餐、收银、外卖、报表、排队等服务的On OS 10系统，为餐饮、零售、美业品牌提供简单易用的效率工具；第二层：KONNECT开放平台层。客如云开放平台通过连接“人、财、物、客”餐饮、零售、美业上下游资源，不仅为餐饮、零售、美业品牌轻松获客，还能为商家对接财务软件、人员管理、供应链管理等服务，帮助商家更加高效的管理门店；第三层：大数据及金融增值业务层。一手的大数据，为服务业商家提供云金融、云供应链、云营销、广告服务等大数据及金融增值服务，助力商家具备智能化运营能力，全面提升商家利润。海量订单存储的挑战

客如云成立至今已超过十年时间，随着用户规模扩大以及业务覆盖的场景增多，多年的持续运营积累了大量的业务数据，这其中最典型的是交易订单，当前存量的交易订单数据量已经超千亿量级，对如此海量的数据进行低成本的存储同时保证高效的读写访问是个不小的挑战, 海量订单存储的挑战主要如下几个方面：

1. 存储容量和成本挑战：随着订单数量的不断增加，需要存储大量数据，因此所选择的数据库产品必须需要支持足够高的存储容量上限，同时避免频繁的扩缩容需求，除此之外存储成本也是一个极大的挑战，目标数据库系统最好具有数据压缩能力，同时每GB存储成本必须具有竞争力。

2. 访问性能的挑战：由于系统的TPS/QPS与数据量正相关，海量数据通常也会对读写性能带来挑战，因此要求目标数据库系统具有极高的读写性能上限，同时餐饮SaaS行业的访问请求具有典型的潮汐特征，在低峰期必须能减少资源占用以降低成本。

3. 数据一致性访问的挑战：随着订单数据量的增加，订单数据可能需要在多个地方进行存储，如果采用多套不同的数据库系统，除了会导致业务系统开发的复杂度，不同系统之间的数据同步也可能会引入数据的一致性问题。

4. 数据备份和恢复挑战：如果采用传统拷贝物理或者逻辑的备份恢复方案，对于海量数据全量备份需要花费很长时间，甚至不能在一天的时间内顺利完成，因此需要有高效的全量和增量备份恢复技术。

交易订单归档方案选型

订单系统通常与用户信息表商品信息表等等共存在一起，唯一不同的是订单表数据的量级和增速通常远高于用户信息表。而在交互模式上，用户经常在查看个人信息页面的同时查看所有过往的历史订单信息。所以保持订单表和用户信息表在相同的数据库系统中（例如都用MySQL）是最优的方案，这样业务系统的访问接口最为统一。

对于客如云这样一个餐饮SaaS企业来讲，其全量历史订单数据量远超过用户信息表，记录条数差异在千倍以上，而另一方面，交易订单具有典型的流水特性，时间越久的订单被访问的概率越低。在这样的背景下，将历史交易订单与用户信息表商品信息表等分离存储在不同的实例中，能确保在线交易库的的灵活高效，是一个更合理的方案。

由于历史原因在线交易订单目前保存在一个MySQL InnoDB集群中。研发团队需要为百TB量级千亿行记录的历史订单库选择一个合适数据库, 综合考虑研发团队和运维团队的熟悉程度和使用成本，最终在PolarDB与某分布式数据库中做选型。在各种考量因素中，我们最为关注两个方面是SQL兼容性以及空间压缩率，前者与研发适配人力投入相关，后者与存储成本直接相关。

考虑到使用成本，餐饮收银业务变更的多样性及当前技术方案的可维护性，客如云研发团队最终选择了云原生数据库PolarDB，并启用高压缩引擎X-Engine作为历史订单归档方案，该方案的优势如下：

1. 成本足够低: PolarDB X-Engine对于客如云的历史订单具有超过5倍的压缩率，让原始100TB的数据量压缩后只有20TB，降低了5倍的存储费用。

2. 性能足够高：单节点最大规格可以到88C710G, 单写节点提供的写入能力远超归档的吞吐需求。而用户对历史订单的查询请求可以方便的通过多个只读节点来扩展。同时X-Engine引擎也支持使用Parallel Query对复杂分析查询进行加速，实现了归档和报表分析的统一。

3. 业务兼容性：完全的MySQL兼容性，让前端业务可以用一套相同代码访问在线库和历史库，降低了工程代码复杂度。

4. 备份恢复便利性：PolarDB MySQL使用了存储计算分离架构，做全量备份是只需要在存储层打一个快照即可，100TB数据秒级别即可完成，结合实时的秒级别增量redo备份。

PolarDB高压缩引擎

PolarDB高压缩引擎的底层实现是X-Engine，其是PolarDB中两个可插拔的事务存储引擎之一，在阿里集团内部被广泛使用，存储了数PB的数据量。

X-Engine采用LSM-tree分层结构设计，天然适合数据量大且访问请求存在冷热特征的数据，典型的如交易订单表历史记录，历史聊天消息记录等。PolarDB X-Engine依靠如下几个特性获得了极高的存储性价比：

1. 紧凑页格式：X-Engine使用Copy-on-write技术，避免原地更新数据页，新数据会写入到新数据页中。由于既有数据不可更新，因此X-Engine的 16K数据页是全满的，没有空洞。

2. 前缀编码：数据页中记录按大小顺序存放，同时内部默认每16行为一个前缀压缩的基本单位，每行数据不存放与前一行数据的公共前缀部分，以节省行数据的存储空间. 这个特性对于有序字符串类型索引非常有效。

3. 数据页压缩：记录在紧凑页中按前缀编码完成后，会进一步调用通用压缩算法snappy/lz4/zstd/等进行空间压缩，最后压缩到接近16KB的大小并对齐16KB存放。

4. 自动空间重整：一般存储引擎如InnoDB在运行一段时间之后，表空间中会存在空洞，需要通过手动optimiz进行回收。而X-Engine有自动化的空间回收机制，会在低峰期进行有效数据搬迁，并将无效空间truncate掉减少空间消耗。

通过以上技术手段，PolarDB X-Engine在通用数据集上的磁盘空间压缩达到了3~5倍，而在用有长字符串，前缀重复率较高的表结构上，压缩率可以高达8~10倍。

结语

客如云通过冷热数据架构的设计，缓解了热库的存储压力，同时单表查询性能明显提升。归档库的大存储及压缩特性可以满足业务日益增长的各类需求同时节约成本，长久保存业务数据的整个生命周期，可为各类数据分析提供数据支撑，更好的赋能业务快速发展。