共计 4361 个字符，预计需要花费 11 分钟才能阅读完成。
武汉利楚商务服务有限公司（简称“利楚”）成立于 2011 年，是国内最早从事聚合领取技术研发和利用的高新技术企业之一，也是国内当先的商户数字化经营运营商。旗下领有聚合领取中台“扫呗”、商户轻 SaaS“赋佳”、全域营销中台“有域”3 大产品体系，此外，利楚还有多项业余资质，30 多项软件著作权，领有弱小的零碎研发和经营保障能力，是国内商户服务畛域的创新者和引领者。
本期，咱们特地邀请了利楚商服 CTO、副总裁、领取行业资深零碎架构师林喆，从分布式数据库倒退历史谈起，为大家讲述利楚与 OceanBase 相遇、相知的故事。
为什么抉择分布式数据库
在互联网时代，数据成为一家企业经营的命根子，利楚作为聚合领取的领军企业之一，2021 年受理交易金额 3500 亿，覆盖全国 600+ 城市，服务线下商户 110 万 + 家，日交易笔数 2300 万 +，合作伙伴 1000+。如此海量交易和领取场景下，数据对于利楚意味着服务质量，意味着企业经营的将来与活力。因而，对于数据的根基底座，数据库的稳定性高于一切，724365 稳固运行是根本需要，服务连续性是服务质量底线，高可用的数据库，防止单点故障、疾速容灾切换、数据无损是数据库技术大势所趋。
数据库技术倒退
从数据库技术倒退历史来看，经验了单体数据库、分库分表数据库、分布式数据库的倒退。同比咱们的业务利用和服务，很早就开始了微服务化、单元化架构降级，其本质也是服务分布式化，通过分布式一致性协定来协调各个利用和组件，从而达到服务高可用、高吞吐的能力。尽管捷足先登的分布式数据库技术，跟应用服务的技术架构差了半步，但从最终发展趋势来看，分布式数据库肯定会成为支流数据库。
单机数据库
自 1970 年 IBM 的研究员 E.F.Codd 博士提出关系模型以来，关系模型通过几十年失去了充沛的倒退，并成为数据库的支流模型。这几十年也造就了 Oracle、DB2、MySQL、PG 等出名单机数据库产品。
单机数据库使用方便，单个节点保护老本较低，保障 ACID 个性（ACID 是 Atomic 原子性，Consistency 一致性，Isolation 隔离性，Durability 持久性），但随着业务量增长，面对高并发读写、海量数据高效率解决显得力不从心，一直晋升单个节点的规格终究会遇到天花板，摩尔定律无奈赶上和业务增长规模。
对于计算机时代的史前产品，放一张黑白图片示例
分库分表
单机数据库无奈承载高并发和海量读写等工作时，分库分表计划开始斩露头角，到目前为止仍然方兴未艾，分库分表的计划解决了疾速业务增长所带来的高并发拜访问题，同时对于海量读写也通过分而治之的伎俩得以满足。典型代表中间件包含 TDDL、Sharding-JDBC、MyCat 等。
通过对目前支流的一些云数据库产品调研，咱们发现目前大多云上的分布式数据库，根本都是 MySQL、PG 为内核的二次开发的分库产品，搭配 ZooKeeper、etcd 等分布式组件，将多个数据库实例治理起来，达到形似分布式的数据库产品。实质上来讲，跟利用连贯多个数据库相似，只是下移元数据管理到独自组件，理论应用上就会发现 ACID 无奈保障，疾速业务倒退须要拆分实例数据迁徙等高投入运维工作。
分布式数据库
到了 21 世纪，分布式数据库的概念开始提出，相比拟传统数据库和非关系型数据库 NoSQL，新一代数据库成为 NewSQL 数据库，这类数据库承载了传统数据库和 NoSQL 数据库的性能和长处，将两者完满联合，既能保障 ACID 个性，又能解决分布式扩大能力，保障海量存储的同时也能达到高可用高效率的指标。
21 世纪晚期，分布式数据库曾经有了一些雏形，以 Shared Storage 为典型代表 Oracle 的 RAC，将计算节点分布式解决，能够看作是分布式数据库的一个尝试，毕竟高端存储硬件不是个别企业能累赘的起，而且存储层仍然无奈横向扩大。
2012 年 Google 公布 Spanner，因其代码闭源，只能通过论文一窥到底，Shared Nothing、Paxos、ACID、MVCC 等根本确立了分布式数据库的支流架构模型。
在泛滥分布式数据库选型中，TPCC 榜单的 OceanBase 进入了咱们眼帘，间断两年 TPCC 测试第一，超过 Oracle 性能 20 多倍着实亮眼。同时通过理解，OceanBase 数据库是齐全自主研发的分布式数据库，不是基于其余内核产品的包装品，这一点也是咱们筹备测试 OceanBase 的重要起因。
选型验证 OceanBase
基于数据库的发展趋势，利楚作为创新型互联网企业，始终紧跟技术倒退步调，一直迭代平台架构，能力一直晋升服务质量，应答持续增长的业务倒退。因而，基于对分布式数据库的钻研，咱们抉择 OceanBase 进行测试验证，基于咱们的业务进行测试，也是对分布式数据库产品的初探。
对于 OceanBase 其实并不生疏，在 2019 年曾经与 OceanBase 团队进行过交换，过后通过初步理解后，发现对于咱们的数据迁徙和运维治理提出了一些挑战，老本和危险让咱们临时搁置。时隔两年，再次见到 OceanBase 团队感觉很亲切，同时也心愿这两年的积淀，能够为咱们带来不一样的产品。
高兼容
利用切换数据库，不仅仅是换个数据库驱动这么简略，驱动只是解决利用与数据库的通信协议，数据库对于 SQL 的兼容水平，间接影响了咱们业务迁徙的革新老本，OceanBase 一套集群同时反对 Oracle 和 MySQL 两种模式，在咱们调研中的泛滥数据库中也是惟一的一款。
本次兼容性评估，OceanBase 提供了 OMA 迁徙评估工具，可能在数据迁徙前对数据库进行全面扫描，做到对症下药。通过 OMA 评估工具，咱们间接评估了测试库的构造和 SQL 的兼容度，同时还能够通过代码扫描来剖析利用中的 SQL，对于不兼容项能够通过评估报告提供具体阐明和改良倡议。
通过命令行模式的构造迁徙评估，很快生成了评估报告，依据评估报告的非兼容项，咱们还发现了两处非标语法，打消兼容性隐患。
OMA 还反对代码扫描评估，间接本地通过 OMA 工具进行代码扫描，防止将外围代码透露，兼容度剖析 100%，在理论利用接入测试中发现评估报告比拟精确，当然前提是确保 perfomance_schema 中的 SQL 笼罩了咱们业务的所有 SQL。
OMA 工具易用，评估精确，给 OceanBase 点个赞。
高压缩比
通过评估之后，咱们通过 OMS 迁徙工具梳理迁徙了多份数据进行测试比照，不得不提一下 OMS，几步配置操作即可拉取迁徙，整个操作流程非常简单易用。
在迁徙实现后，咱们特意比照了数据库存储差别，对于一个数据为外围业务的公司，数据的存储老本日益低落，OceanBase 存储压缩率的确让咱们感到意外，超高的压缩比能够极大地节约存储老本。下图中是一个 300GB+ 的宽表的存储比照，而对于整库的存储压缩率更是达到了 70% 以上。
业务库表的存储比照
OceanBase 的高压缩比不仅仅是传统的 zlib、lz4 等压缩算法，还有编码、差值算法等高级压缩，相比拟传统压缩算法又提供了更极致的压缩比，如此高的压缩比着实令人出其不意。
HTAP
OceanBase 数据库不仅仅是一个 TP 关系型数据库，其主打的 HTAP 也是咱们比拟看中的个性，对于利楚的领取场景，领取交易订单量微小，且业务规模快速增长，在进行联机交易的同时，咱们心愿可能有一些实时的统计分析，比方单干商家统计查问近期的交易汇总信息，对于查问时效也是服务体验的重要一环。
基于此目标，咱们具体比照了咱们现有数据库和 OceanBase 的 TP 和 AP 能力，验证在保障领取业务稳固的场景下，是否可能提供实时的统计查问能力。咱们通过一个 4.9 亿 + 条数据的宽表，通过不同场景的统计分析 SQL 进行比照，OceanBase 查问性能较为出众，TP 性能如 TPCC 榜首一样，高并发高性能的保障，同时 HTAP 混合引擎也提供了实时的数据分析能力。
4.9 亿 + 表的会员统计汇总剖析，执行工夫比照
通过实在业务 SQL 的执行比照，OceanBase 的体现再次超出预期。
业务初探 OceanBase
通过不同场景的测试验证，OceanBase 不仅满足咱们对分布式数据库的要求，其性能和高存储压缩比也出其不意。
咱们首先抉择了一个翻新业务“来合伙”进行迁徙割接。这个业务上线工夫不长，但业务增长迅猛，高速增长的业务对数据库也是极大挑战，不晓得哪一天呈现突发增长，对于传统 MySQL 即便分库分表都来不及拆表迁徙。
数据迁徙过程中再次施展了 OMS 的作用，不仅仅反对数据的全量迁徙，同时反对构造迁徙、全量校验、增量迁徙、反向同步等性能。全量校验对于领取场景对咱们十分有帮忙，节俭咱们开发校验程序的工作，同时还保障了数据迁徙的准确性。增量迁徙可能与源库放弃实时同步，为咱们业务验证提供了一个窗口期进行充沛验证，确保割接上线的稳固。
通过数据全量数据迁徙，其中一个逻辑库的存储压缩比照，“来合伙”业务根本压缩率在 26.4%，合乎之前的测试预期。
来合伙某个逻辑库迁徙前后比照，从 11.06GB 存储降到 2.92GB
在迁徙割接过程中，利用代码仅仅须要批改配置文件，切换数据源，OceanBase 对 MySQL 协定的兼容性齐全不须要更换驱动等。同时基于之前的 OMA 评估报告，对于利用的验证也十分顺利，OceanBase 对 MySQL 语法的兼容度也升高了数据库的切换门槛。
迁徙后，通过 OceanBase 的云服务平台，监控 CPU、TPS、QPS 等性能，同时还能够设置告警，保障服务 SLA，实时诊断性能更是给 DBA 提供了一套“利器”，慢 SQL 查问、TopSQL 查问，甚至还能够在不改变业务代码的同时，对慢 SQL 进行索引绑定等操作，极大进步了数据库运维效率。
在 OceanBase 生态工具的加持下，首个业务顺利完成迁徙，同时对线上继续监控，目前业务安稳运行，后续利楚会逐渐迁徙其余业务线迁徙割接到 OceanBase，拥抱分布式数据库时代，享受分布式数据库带来的技术红利！
后记（架构师感悟）
OceanBase 解决方案架构师周贵卿（花名：曜松）：
再会利楚近两载，尽管当年没有可能让利楚倾心，然而两年的工夫 OceanBase 各类生态产品获得了突破性停顿，各类周边配套产品从客户理论问题登程，解决评估、迁徙、运维等一系列问题，本次测试验证不管从数据库还是生态产品都失去了客户的认可，也是咱们“把简略留给客户，把简单留给本人”的践行。
针对利楚高流量高并发业务场景，在评估迁徙过程中，联合蚂蚁最佳实际，对外围数据库表构造进行了局部优化，实现了业务代码零革新的同时，提供了数据库扩大能力和性能的晋升。
利楚首个业务落地 OceanBase 仅仅是一个开始，对于其余业务，尤其领取的海量数据，咱们会与利楚一道共同努力，心愿通过 OceanBase 为客户带来迁徙一键式、运维一体化、HTAP 一套库的服务体验。