国产数据库技术创新，不仅突破了物理机规格瓶颈，做到了在云原生架构下的又稳又活，在开源技术生态构建方面，也已经走在行业前列。

　　2024年10月19日，腾讯云数据库城市行成都站成功举办，本次活动由腾讯云数据库、OpenTenBase及ITPUB联合呈现。来自数据管理领域的多位技术专家，围绕云原生架构演进、内核优化等热门话题，进行了深入探讨。

　　随着企业数智化进程的加速，数据管理成为推动行业发展与变革的重要驱动力。其中，数据库作为信息技术的核心能力，正扮演着“数字化基石”作用，为各行各业提供着可靠、高效、安全的数据支持。经过数十年的发展，国产数据库成品不仅在性能、稳定性和安全性方面实现跨越式发展，扛住了实际业务场景的考验，在底层架构和内核技术创新方面，也取得了显著成果。

　　云原生时代的关系型数据库变革

　　从数据库的基本可用，到实现高效易用，再到不断降低成本，让用户以更经济的价格去使用。国产数据库的发展历程，不仅见证了技术的持续进步与迭代，更是一部云原生数据库的创新史。

　　“云原生”并不是凭空出现，而是用户为应对流量洪峰而采取的有效路径。正如腾讯云数据库高级产品经理程昌明所言，云原生架构是从传统架构中演进而来。在过去存算一体架构下，尤其在业务量不大的情况下，优势显而易见，比如：本地磁盘IO极低、响应时间短，本地的资源可以做到无损的弹性，网络架构比较容易扩展。但随着企业业务规模的不断扩大，数据量的不断增加，遇到的各种挑战已经到了必须去解决的时刻。具体包括：1）备份恢复时长随数据量增长；2）磁盘规格受限；3）计算资源上限受代次限制；4）需要不可读备机提供可用性保障；5）物理机的底层内核特性更新缓慢。

　　最早，TencentDB for MySQL也是本地盘产品形态，是基于物理机的计算、存储一体化架构。经过物理机架构多年的运营，资源弹性能力遭遇挑战，扩容能力受限，扩容/回档时间变长，线上平均扩容需要5、6个小时。经过多方对比，集群版架构（云原生架构）凭借卓越的横、纵向扩容能力，成为解决资源弹性能力的最 佳选择。在新架构下，计算节点可以复用CVM高密度机型，最大核心数从90核提升至128核，存储容量突破单机上限，从12TB提升至32TB，最大吞吐IOPS从15万提升至百万级别。与此同时，异步拷贝数据，不管数据量多大，添加只读节点时间都小于1分钟。

　　虽然，集群版带来了诸多收益，在快速弹性、灵活规格和高吞吐方面，实现了跨越式发展，但依然有两座大山挡在前面。首先，延迟问题依然无法接受。在访问链路上引入CBS以后，整体链路多了一跳 TCP 网络延迟。IO延迟从SSD 70us 增长了91%至134us，在低并发场景下延迟愈发明显。其次，性能问题依然严峻。经过容器化之后，采用 SideCar 的部署模式为每个MySQL实例创建独立的Agent容器，侵占了实例本身的内存资源。尤其在小规格实例场景下，例如1GB内存的实例，Agent容器占用20%，造成MySQL容器内存不足而性能低下。

　　为了从根本上解决读写延迟和性能问题，技术团队从内核特性层面进行了优化和提升。其中，在原子写快照优化方面，把TR 转换为 sync TR 来解决文件元数据延迟更新的问题。另外，在跨CCD优化方面，实现了不同节点间的负载均衡优化。通过实际测试数据来看，基于整体的内核优化，腾讯云数据库MySQL整体性能提升了15%，而在读写混合场景下实现了30%-50%的性能提升。

　　开源技术演进之路

　　构建国产数据库生态，“去O”喊了很多年，但在掌管国计民生的金融场景中，做到完全去O并不是一件容易的事。在腾讯云专家工程师陈枝看来，开源数据库的推出，可以说是为国产数据库的繁荣发展，带来了可行性方案。

　　OpenTenBase是一款由腾讯自主研发的分布式国产数据库，其发展历程可追溯至2008年，最初以单机PostgreSQL提供服务。随着业务增长，单机模式无法满足需求，分布式数据库逐渐发展起来。2019年，TDSQL PG（即Tbase）正式开源，2023年升级为OpenTenBase，并捐赠给开放原子开源基金会。

　　OpenTenBase具备业界领先的HTAP能力，并积累了数百人的技术团队，服务于社交、娱乐、游戏、支付等多个场景。其关键特性包括成熟稳定、一站式OLAP/OLTP解决方案、自主可控和积极回馈开源社区。在架构上，OpenTenBase采用GTM（事务管理器）、CN（协调节点）和DN（数据节点）的设计，确保数据一致性和高可用性。在具体的应用场景方面，OpenTenBase适用于HTAP、高并发应用的核心系统以及国产化替代，基于当前开源版本丰富的特性可满足广泛的应用场景需求。

　　值得一提的是，Oracle兼容性是OpenTenBase的重要特性之一，目前兼容性已达到90%以上。OpenTenBase在数据类型、SQL语法和对象、PLSQL等方面进行了大量兼容，确保用户能够平滑迁移Oracle数据库，并享受OpenTenBase带来的性能提升。

　　在实际案例中，OpenTenBase成功应用于某证券反洗钱系统数据库替换和微信支付等场景。特别是在金融保险等传统行业，OpenTenBase以低代价实现了去O（Oracle）的目标，赢得了客户的信赖和认可。此外，OpenTenBase还服务于数字广东、第七次人口普查、易方达基金、东方证券、申万宏源、国信证券、太保、兴业银行等多家知名企业。

　　写在最后：

　　数据库作为企业存储与管理数据的基石，扮演着数据管理的关键角色。然而，在具体的业务实践中，关于数据管理的主导权归属问题引发了热议。数据应该由业务部门主导，还是技术部门引领？对于结构化与非结构化数据的规范化处理，其解决路径是在应用端落实，还是应由DBA层面来承担？此外，针对多源异构数据的存储挑战，分布式架构相较于集中式架构是否更具优越性？在圆桌互动环节，现场嘉宾展开了激烈的讨论，大家纷纷发表了自己的见解。

　　整体观点是，在数据管理的主导权划分上，没有统一标准。技术与业务之间其实并不是非此即彼，而是紧密合作关系，特别是在数据恢复和业务核对过程中，技术处理可能无法单独解决所有问题，业务部门的参与对于数据完整性和准确性至关重要。

　　针对结构化与非结构化数据问题，数据库应提供多元化的解决方案，以适应业务需求的复杂性。现场一位嘉宾强调了在数据库层面进行规范化处理的重要性，以及通过视图等方式映射非结构化数据的方法。由于缺乏规范化的数据管理，导致在处理结构化和非结构化数据时变得复杂，特别是在使用国产数据库时，需要制定详细的规范来解决兼容性问题。为了解决这些问题，DBA提出设立明确的规范和规章制度，以指导业务部门和开发部门的决策，确保数据处理的一致性和高效性。

　　至于，企业在面对多源异构数据处理的时，到底是选分布式架构，还是集中式架构？同样需要根据实际业务特性和管理复杂度来衡量！集中式系统因其性能优势在某些场景下更受欢迎，而分布式系统则因其可横向扩展的特性，在处理大规模业务活动时显得尤为有效。然而，分布式架构带来的运维复杂度和故障恢复时间较长的问题也被指出。此外，有人还提到了软件单点故障的普遍性及其对数据安全的影响，强调了快速故障恢复的重要性。综合而言，选择哪种存储系统应根据企业具体需求和业务特性来决定，且团队的技术能力和维护策略也需考虑在内。