OceanBase助力大规模基因检测降本，实现基因测序惠民

1990年10月人类基因组计划启动, 与曼哈顿原子弹计划和阿波罗登月计划一起被称为二十世纪人类三大科学工程，花费38亿美元，历时13年，在2003年4月15日公布了人类基因组序列草图。

随着基因技术的不断发展，基因测序的速度已飞速提升。现在，一台测序仪1天可完成60个人的全基因组测序，而成本则降至不到600美元。未来的医疗技术，也将会从后端的疾病治疗，逐步走向前端的基因诊断和预防、精准医疗及个性化医疗。大规模基因检测的落地需取得检测复杂度和成本之间的进一步平衡。只有这样，基因检测的结果才能更精准更快，价格才能更亲民，真正实现基因科技人人可及、人人可享。

那么，如何使大规模基因检测的落地取得检测复杂度和成本间的平衡？数据库在其中的作用是什么？本文通过我们公司基于基因测序业务的数据库解决方案选型来揭晓答案。

基因检测业务对数据库的五大要求

出于历史原因，我们公司内部应用系统较多，使用的数据库类型、版本，以及数据库硬件服务器型号都没有统一的标准，这给数据库开发和运维增加了极大难度。随着业务的扩展，数据量日益增长，业务复杂度越来越高，对业务、数据库系统都提出了更高的要求。

业务给数据库系统带来的挑战是我们公司迫切需要解决的问题，具体而言，体现在以下五个方面。

第一，解决分库分表对应用侵入问题的同时实现存储降本。以基因测序业务为例，一台测序仪每天产生几TB的数据，如何经济、高效地存储数据，同时避免分库分表对应用的侵入。

第二，满足不同国家的数据安全合规高要求。此处的数据安全主要涉及人类遗传资源管理条例、医疗大数据和个人信息保护要求，需要从数据存储、数据访问、数据传输、事后审计等多角度保障数据安全。另外，各国数据监管要求不同，所应用的数据库产品需要同时满足国内和海外各国的合规要求。

第三，数据库产品授权合规。例如，过去一直在使用的MySQL被商业公司收购后存在停止维护和未知的合规风险，缺少相关数据库资质认证，希望使用技术可靠的软件。

第四，降低数据库运维复杂度。如今越来越多的数据库产品涌现，不同的技术堆栈带来了很大的运维复杂度，期望数据库产品强化以数据为中心的理念，做到数据池化、数据库服务化，使运维管理简单、高效。

第五，生态工具完善、便捷。使用MySQL分库分表方案缺少运维平台、管理工具等，且缺乏官方支持，需要投入人力进行开发和维护。此外，MySQL扩展性较差，无法匹配业务扩展速度。

四款数据库选型及对比数据

基于上述业务对数据库的要求及现有数据库的痛点，我们在调研新的数据库产品时主要考虑业务需求、安全合规、运维管理、开发效率等选型因素。

• 业务需求：业务快速扩张带来的业务复杂度、业务数据量的增长，需要新的数据库产品具备高可靠、高扩展，以及成本可控的特性。
• 安全合规：数据库产品自研、技术可靠，具有安全相关的设计资质。
• 运维管理：可采用平台管理完成日常数据库运维工作，统一监控协助应急处理，减少日常运维人力的消耗。
• 开发效率：统一数据库技术栈，并采用兼容的数据库类型，尽量减少迁移系统时的代码改动；基于引入的数据库统一开发规范，提升开发效率和系统稳定性。

按照上述选型因素，我们选择了四款较有代表性的数据库产品进行初步对比，考察项见下表。

经过初步筛选，我们认为OceanBase比较符合需求。首先，Oracle不是国产化数据库，且数据库水平扩展能力较低，SQL也只兼容Oracle自身。其次，达梦数据库非开源，资料相对较少。最后，OceanBase和TiDB作为国产开源分布式关系型数据库都符合选型要求，但TiDB无法兼容Oracle，难以将Oracle、MySQL统一技术栈迁移至TiDB中，因此选择OceanBase进行测试。

我们对OceanBase3.x版本一共进行了三轮测试，整体测试情况如下。

• 第一阶段（2020.6~2020.10）：基准测试。
•     MySQL5.6的兼容性测试，可兼容。
• 第二阶段（2020.10~2021.1）：分布式特性测试。
• OceanBase数据库100亿分片表测试。通过使用OceanBase的分布式特性，在未改变应用代码的前提下，将处理时长从原来超20秒缩短为10秒以内。
• MySQL中需要3TB（双副本）存储的数据，在OceanBase中压缩到1TB（三副本），压缩率约为70%。
• 第三阶段（2021.2~2021.10）：应用测试。
• 结合应用改造，将数据迁移至OceanBase后，利用OceanBase分区表和tablegroup的分布式处理能力，将原本约6小时的业务处理时间进一步缩短到10分钟以内。

通过整体的测试情况，可以看出：OceanBase兼容性好，可以在少量改动代码甚至业务无感知的情况下进行迁移；OceanBase分布式特性使业务的扩展性极大增强；OceanBase存储相同的数据可以实现约70%的成本节省，从性能提升、降低成本方面都带来了很大的收益。

OceanBase应用架构及配置

根据实际生产业务，我们制定了OceanBase落地的目标配置。在正式环境中，除了OceanBase集群外，为了方便运维管理和业务迁移，我们也搭建了运维管控平台OCP、数据迁移平台OMS，节省运维、业务迁移的人力成本。整体的部署架构如下图。

通过OCP部署OceanBase集群，以租户的形式提供给业务方使用，应用通过负载均衡这一层随机访问DBProxy层，转发对应的请求到OceanBaseServer节点执行。整体的配置策略如下。

OcanBase集群三节点配置（3.x版本）采用84C/512G/10TB，磁盘使用本地SSD，万兆网卡，具体存储配置可根据业务数据量调整。配置容量基线如下：

• 租户数量1~25个（按照每个租户最小2CPU计算）。
• 表分区数量小于3w（为推荐值，大于3w性能开始下降）。
• TPS容量（按照CPU跑满100%）sysbench读写混合场景，1.5w TPS，超30w QPS；TPC-C场景约1.3w TPS。

运维管控平台OCP采用32C/128G/2TB，磁盘使用SSD，万兆网卡，最少1台，单节点即具备全部功能，生产环境建议3节点部署。

数据迁移平台OMS采用32C/128G/2TB， 磁盘使用SSD，万兆网卡，生产建议最低两节点配置。根据迁移数据链路数量，可水平扩展多节点。

通过上述OceanBase三节点的基础配置，以租户的形式统一整合原有的数据库实例，集中资源，提高了整体的资源利用率。并且在业务运行过程中，可以通过动态调整的方式，灵活对租户、集群的级别扩缩容，匹配快速发展的业务量，解决了以往传统单点数据库扩缩容时对业务的影响问题，并且对业务的响应可以更加及时。

在整体的迁移过程中，OMS也发挥了极大的作用，全量加增量迁移的方式，无缝将MySQL的数据迁移至OceanBase集群中，通过主键做源数据和目标的校验，确保数据一致性。在可视化的迁移界面上，等到链路无延迟时，再做生产应用的切换，整体的切换过程较为平滑，对业务的影响降到最低。

我们更加看重的是OCP运维管理平台，以往运维MySQL数据库都是通过脚本及独立的监控平台告警，将业务迁移到OceanBase后，OCP上提供了全生命周期管理的能力，集群的创建、备份、监控、卸载等一系列的能力基本能够全覆盖DBA的工作，通过统一的界面管理，对于运维人员来说，可以更直观地看到集群的运行状态，白屏化的操作也大大降低了以往在服务器上直接操作的运维风险。

收益总结及未来规划

通过引入OceanBase分布式数据库，我们主要实现了以下四个目标。

第一，支撑未来业务。OceanBase分布式处理能力和原生高压缩比满足未来十年内的数据管理能力；在未改变应用代码的前提下大幅提升查询性能，如某些查询场景查询时长仅为MySQL的1/3，业务处理时间从约6小时提升至10分钟；不停服无限水平扩展能力支持未来业务数据进一步增长。

第二，统一数据库平台。基于OceanBase多租户能力搭建统一基础数据库云平台，业务即用即申请，交付速度快；资源管理方式从静态、固定供给方式，过渡到以动态、可调节的供给方式；实现数据库整合同时，进行统一管理，统一版本，降低运维成本。

第三，应用平滑迁移。OceanBase兼容 MySQL，应用程序平滑迁移至OceanBase，大幅减少应用改造成本；数据库可以按需逐步迁移至OceanBase；业务无需改动任何一行代码即可实现动态扩缩容，无需分库分表。

第四，满足安全合规。国产数据库中唯一实现100%自主研发的产品，不依赖任何开源产品，具备产品独立迭代的能力，全球可统一架构，无需担心合规风险。

目前，我们使用OceanBase已经超过两年了，接入的业务场景主要以查询为主，后期会计划接入更多类型的场景。2022年OceanBase 4.0版本发布后，我们也在持续关注，并且，已经测试并基于4.x的架构在实际生产业务中使用。期望在未来将所有MySQL上的业务迁移至OceanBase，将OceanBase作为统一的数据库方案。

通过替换数据库方案，在一定程度上可以提升大规模基因检测的性能，稳定支撑复杂的基因测序业务，同时，数据库的高压缩比从软件和硬件消耗层面实现了成本的节约，进一步平衡业务性能需求与成本，实现基因检测保证快速与精准的同时拥有更实惠的价格。