数据库技术生态应如何构建

[OceanBase开发者社区]

数据库已经有了 60 年的发展历史。从主流商业数据库到开源数据库，近年来国产数据库也开始加大了投入，开始逐渐进入到行业核心系统，例如金融和证券。虽然国内数据库技术相比国外产品仍有差距，但是目前来看并不是技术本身，而是数据库生态的建设。

一个成熟的数据库生态不仅包括功能完善、性能优秀、运行稳定的系统，还包括完整的文档与知识库、丰富多样的开发和运行维护工具链、典型的应用案例和评测报告，以及一批熟悉系统、经验丰富的开发者和用户。

《对话 ACE》第三期活动便围绕“数据库技术发展和生态建设”的背景，邀请到 OceanBase 合作伙伴和生态合作部总经理梁刘红和新炬网络首席架构师、OracleACE Director 梁铭图两位老师，共同探索“数据库技术生态如何构建“，以此推动国产数据库技术生态更好地发展。

 

以下为对话实录：

 

梁铭图

Q：从商业到开源再到云，如何看待数据库技术这几段变化？

A：从商业到开源再到云，我感觉首先是整个数据库的技术在不断向前演进。包括现在的主流数据库，从前开始都是Oracle，现在MySQL到上云。除了技术以外，还有其他一些因素在共同推动这个进程的发展。

特别在我们国内，第一个是国内信息化水平在飞速发展，在20年前，国内除了BAT等互联网企业外，普遍的企业信息化程度相对来说还是比较单一或者薄弱。国内信息化的建设主要集中在金融、电信等行业。当时应用或业务都没那么复杂。在这种状态下，很多客户会将所有的数据或者核心的业务数据放在一个数据库里面。对于企业核心的生产系统而言，必然是追求系统的稳定性和可靠性。在这种情况下，商业数据库由于经过了行业的反复验证，以及完善的工具体系，国内的开发，运维的人才相对比较多，所以无疑对于企业而言，是最好的选择。

信息化发展到一个阶段以后，整个业务会相对来说变得越来越复杂。特别是到了后期，甲方也意识到并非所有的应用都得用 Oracle 这么贵的数据库。于是更多的一些边缘应用，会选择使用一些开源数据库。在互联网行业选择使用比较频繁的情况下，再到后期云状态逐渐成熟以后，特别是云原生，包括微服务整个架构的思想牵引下很多企业开始慢慢的去拆系统里面的这种巨石（泛指大的应用）。将它进行业务的拆分解耦，使得原来很复杂的数据库业务逻辑开始慢慢变得简单。那数据库用开源或者更多的云化数据库的一个契机，也就慢慢的落地。所以我认为，现有状态下的这些变化有以下几种原因，一是整个信息化的发展程度，二是架构的思想变化，还有技术的演进，共同驱使整个数据库技术的变化。

 

梁刘红

Q：OceanBase 的生态建设上做了哪些？

A：要想成为一款真正好用的企业级数据库。除了产品自身的能力外，建立良性可持续发展的生态体系也至关重要。OceanBase 从商业化之初就非常重视生态体系的建设，我们的生态建设工作主要围绕四个方面展开，分别是产业生态建设，技术生态建设、人才生态建设以及商业生态建设四个维度。

首先是产业生态，经过过去两年的努力，OceanBase 已经与产业链上下游数百家的重量级的伙伴完成了产品适配认证工作，其中不仅包括了大家耳熟能详的如鲲鹏、海光、飞腾、统信、麒麟、金蝶天燕、东方通、普元这一类基础软硬件厂商，也包括了像神州信息、长亮科技、中电金信、宇信科技、易诚互动、恒生电子、太极华保、新大陆、东软、久远银海、用友这一类覆盖银行、证券、保险、运营商、政企、通用行业的头部应用厂商。

第二是技术生态，2021 年 6 月 OceanBase 正式开源，采用木兰公共协议，通过 Open Core 的模式开放了 300 万行核心代码，包含完整的数据库内核、分布式组件和接口驱动层。与企业版的差别仅在于少量的高级特性，如 Oracle 兼容模式、图形化管理工具、操作审计、安全加密、高可用扩展等。

这次开源，是充分考虑了技术和商业发展后做出的战略决定，是 OceanBase 最重要的技术战略之一。OceanBase 的此次开源也充分体现了 OceanBase 在加速支持技术生态建设上的决心与诚意。

截止到今年 3 月底，已有 136 名技术贡献者加入 OceanBase 开源社区，社区用户数超过 29000 名。超过 100 多家客户进行了深度实践，并围绕“OceanBase 社区版的使用及开发”输出了深度的解决方案、技术解读以及实践分享。

同时，OceanBase 也在加速推进与数据库周边生态工具厂商的合作，目前已经与 DSG、flink cdc、datax、otter、prometheus、k8s、派客动力、新炬网络、云和恩墨、英方、爱数、安华金和等 40 余家厂商完成产品适配，覆盖数据迁移、数据同步、数据清洗、数据安全、数据备份等多个领域。

OceanBase 是纯自研的数据库，与基于开源 MySQL 或 PostgreSQL 二次开发的数据库不一样，没有现成的生态可复用，因此 OceanBase 的开源起步注定是比较难的。但只要方向对了，就不怕路远。在开源方面，我们会坚持做好三件事情：

• 产品能力：认真打磨好每个版本，全面加强与MySQL的兼容性
• 加速提升易用性：不断完善技术文档，开放更多接口，完善各类生态工具
• 持续优化服务体验：长期投入，通过各种线上线下高质量的活动，孕育活跃的开源社区文化，与广大社区开发者携手，持续优化服务体验。

第三是人才生态，要想繁荣数据库生态圈，人才培养要先行。人才是技术和生态建设的根本。中国目前在基础软件方面的人才是极度匮乏的。在中国，每年软件技术专业的毕业生 90% 流向了上层应用开发，仅有不到 10% 的毕业生投身于基础软件方面。

OceanBase 会长期投入，通过建设人才联盟、结合人才标准、提升人才能力、传播人才价值等一系列措施，持续为行业培养和输送高质量的分布式数据库人才。

2020 年 9 月，OceanBase 推出了数据库人才培养体系和认证标准，根据人才能力画像的不同，认证分三个级别：

• OBCA （OceanBase数据库认证专员）：掌握OB的产品架构、核心功能。
• OBCP（OceanBase数据库认证专家）：熟练使用OB，能够制定有效的技术解决方案，熟练诊断常见问题，并给出相应的解决方案。
• OBCE（OceanBase数据库认证大师）：设计OB的整体架构，确保业务平稳、高性能运转，具备处理复杂业务场景的故障排查能力。

高等院校是人才培养的摇篮，过去两年，OceanBase 也积极联合了华东师范大学、武汉大学、浙江大学、东北大学、浙江理工大学、华中科技大学、复旦大学等多所高校持续推出丰富多彩的项目和活动，实现从教材、教案、教具、师资培训、人才培养基地、数据库大赛、人才认证全覆盖的人才培养模式，帮助更多高校数据库爱好者学以致用，促进国产数据库的人才发展。

最后是商业生态，OceanBase 对于自己的定位一直非常清晰，专注做好数据库，其他方面的事情全力支撑合作伙伴来完成。OceanBase一直致力构建开放、合作、共赢的生态体系，与伙伴携手持续为广大客户提供优质的服务。

当前，我们将伙伴主要分为四大类：

• 经销商伙伴：银牌、金牌、铂金
• 专业服务商伙伴：银牌、金牌、铂金
• 联合解决方案伙伴：精英、战略
• 培训认证伙伴：授权

针对每一种类型的每个级别，OceanBase 都有明确的要求 & 权益。这里想重点讲讲 OceanBase 今年在伙伴服务能力建设方面的一个重要举措。

OceanBase 今年发布了“OceanBase 技术精英训练营计划”，除了上面提到的各种人才培养手段以外，我们还特别增设了师傅带徒弟进入实战训练的环节，每一位进入训练营的技术人员都会被指派一名来自OceanBase 的资深技术专家作为师傅，带入实际项目中打磨实战能力。我们希望通过这一举措，快速提升伙伴的服务能力及行业竞争力，更好地服务于广大客户。

 

梁铭图

Q：如何建设一个新型数据库技术全栈？

A：关于这个问题，我今天以一个数据库的使用者或者需求者的角度谈谈企业该如何构建数据库技术全栈。

①在数据库产品选型过程中，首先会优先选择技术稳定的产品。

②关注研发持续的投入，有明确的发展路径。大客户比较看重这点的原因，主要是希望与数据库产品有一个长时间共建的过程，形成长期的合作关系。

③清晰的产品定位，适用于不同的场景。企业应用的场景有千万种，每种场景选择的数据库类型都有一定差别，而且一种数据库并不能解决所有场景的这些问题。

④对于甲方客户来说，完善的数据库售后也是非常关键的。甲方客户一般比较害怕的是问题没办法或者没人去帮助解决，所以会倾向选择有一个完善研发售后体系来做支撑。

⑤构建数据库技术全栈的关键因素是人，对于一个新的数据库而言，需要构建一整套学习和知识分享体系。无论是社区、技术图书、优质内容、认证培训等方式，都是可以为企业快速培养研发和运维的相关数据库人才。

⑥完整的工具体系能够很好地嵌入到企业现有的开发和运维体系内，减少对于数据库的运维压力。因为每增加一个数据库的技术占比，必然会增加现有运维团队的负担。学习总是有个曲线和过程。如果有丰富的工具体系，可以适当地去降低学习曲线。

⑦开发架构的兼容性。应用代码尤其核心系统的迁移并不简单，这种迁移的工作量往往数以千计人天，包括跨部门配合的工作量，是一个天文数字。如何去提高兼容性来减少对于应用的冲击，也是一个必要考量的。除此之外还可以选择一些工具去做评估。

 

梁刘红

Q：您是否认可未来将进入云数据库时代？

A：回答这个问题前，首先需要思考的一个问题就是未来是公有云的天下吗？我相信大家都认可未来企业在 IT 架构设计上，云架构是必选的一种 IT 战略。但至于要选用什么样的云架构，是私有云、还是公有云，还是混合云或者多云。其实不同的人有不同的看法。但认真思考一下，公有云主要解决的是敏捷、弹性的问题，私有云主要解决的是数据安全、可信赖的问题。而敏捷、弹性、数据安全、可信赖是大多数企业在做自身 IT 规划时希望同时具备的特点。

国际知名软件资产管理商 Flexera 在2021年发布的云状态报告显示，92% 的企业在 IT 架构上选择多云战略，在这 92% 的企业中有 82% 选择了混合云。融合了公有云、私有云优点的混合云架构已成为企业上云的最佳选择。

回答完这个问题，未来是否将进入云数据库时代的这个问题就迎刃而解了。云上、云下的融合是大势所趋，长期的行业趋势不是将所有的数据都转移到公有云，而是将云体验转移到数据上来，而这其中，非常关键的一个技术方向就是分布式数据库，换个说法就是分布式数据库是大势所趋。

 

梁铭图

Q：HTAP 会不会成为新一代的技术生态？

A：我认为肯定是毫无疑问的。去年我们在写中国数据库发展的白皮书。其中有写到说 HTAP 就是数据库未来重要演进的方向。这个概念也不是近期提出来的。以 Oracle 为例，很早就提出在其本身支持 AP 应用的一个特性。

所以 HTAP 这种模式其实对于企业而言，好处不言而喻了。在一个数据库引擎里面既可以做一些 TP 的应用，又可以做一些 AP 高效的查询。不用做很多的 ETL。原来做数据分析，要么用 CDC 传输，要么用 ETL 拉到数据仓库里面再去做分析。在这种情况下，客户就可以用一套数据，几乎实现实时统计了。

从根本上，就企业而言非常单纯以交易为主的 TP 应用，其实往往并不是非常常见的。在大型的企业中，应用模式基本上就是混合负载。比如运营商的营业厅每天做业务的操作后，每天会做数据核对出日报。日报本身就是一种实时统计,所以就非常适合 HTAP 混合负载这种场景。

那 HTAP 未来是否是唯一的选择呢？还不是。它只是其中一个趋势，适合哪种场景呢？第一种是大中型企业里面一些以 TP 为主的，但是可能有一些 AP 应用场景的混合式的应用场景。另一种相对来说中小型企业，本身数据量也不大，用一个数据库就解决所有的问题。为什么说 HTAP 不是一个万能钥匙呢？我个人认为对于海量数据的应用场景来说，需要汇聚各种各样的采取各方面的数据源的数据，要做汇聚整合，这类还是专业的数据仓库或者数据湖的解决方案更适合一点。

 

梁刘红

Q：开源生态建设方面，有什么好建议？

A：OceanBase 在开源生态建设方面是有一个专业的运营团队在负责。在社区治理方面，OceanBase 持续倾听社区用户反馈，围绕用户的行为准则、贡献者协议、组织结构、反馈机制、辅导机制等制度方面加强社区治理。

在社区运营方面，OceanBase 自行组织 18 场线上线下技术沙龙，并参与 12 场技术峰会进行布道，通过举办全国首个分布式数据库内核开发大赛，连接 2000 名高校数据库爱好者，共连接超 5000 名开发者。通过每月更新社区进展和聆听用户需求反馈，持续迭代高质量文档和提升社区活跃度。通过用户成长路线，做好社区支持和服务能力，给予用户更多的人文关怀和帮助用户专业及影响力发展。

梁铭图

Q：对于面对云为主的技术生态，您认为除了主流的公有云，其他云生态应如何构建？

A：我是混合云的坚定支持者。未来企业的基础架构肯定是向混合云演进的几率更大一些。一方面头部的金融、运营商这种企业，他们对内部的IT诉求足够大，可以支撑他们去独立构建自己的私有云设施。另一个方面就是对于公有云，国内企业关于数据安全这一点是有担心的。所以在这种情况下，国内企业一般会去建设私有云来支撑他们内部应用，特别是核心数据的应用。比如像运营商，就会建立多个私有云中心。

另外关于公有云，面对创新和互联网的应用，也更适合部署在公有云。因为弹性按需计费，不会耗费更多资源。另外还有一种是在公有云上做一些灾备。没问题的时候，在私有云上完成运行。一旦出了问题，可以快速地迁移到公有云上。这往往是一种混合的模式。在这种混合模式的生态下，云如何构建？对于数据库而言，其实是需要一个支撑多云的异构数据库云管平台。因为数据库涉及到可以在不同的云上进行，比如说管理分配资源，可以对接到不同的云上去做迁移。出现问题，马上切换公共云模式。另外像多云之间的运维，监控，包括性能的分析。还有就是数据库之间的同步，可能涉及到容灾以及数据应用。需要在不同数据库进行数据同步。从私有云同步到公有云，公有云同步回来，都是一个可见的问题。所以对于我们的企业而言，未来的应用和数据库会处于在公有云和私有云混合云的这种状态下。

梁刘红

Q：国内和海外的生态构建是否有区别？

A：就生态建设的大逻辑而言，国内海外没有什么大的区别。但就具体落地时的策略规划，关注重点来看，肯定是有很大不同的。这中间要考虑的点很多，包括政治文化的差异，商业氛围的差异，IT发展大环境的差异等等。其实，不用说国内国外生态建设的差异，就是在同一个国家内，同一个公司，在生态建设的不同阶段，生态建设所关注的重点也是不一样。

拿大家熟悉的云计算举例，从数据上来看，去年年底的时候，美国 SaaS 的占比已经超过七成。但是国内 SaaS 占比还不足三成。显然美国的 SaaS 产业生态已经处于成熟阶段较为稳定，而国内SaaS产业生态还不完整处于快速发展期，中美 SaaS 产业在生态环境、信息化程度、产业化阶段、客户群体结构以及用户习惯等方面都存在一定差异，因此在云端 SaaS 生态的布局上就一定存在差异性，要因地制宜，冷静客观。

 

梁铭图

Q：工具对于数据库的生态建设很重要，在工具生态的设计上，您怎么看？

A：首先数据库的工具生态能够覆盖整个数据库的生命周期。例如在运维管理阶段，最好能够做需求分配，可以配置出需要的数据库及云管平台。可以做监控和主备管理等。辅助开发工具，像一些 SQL Turning，SQL 审核，帮助做一些数据设计等等。这些工具可以辅助开发人员快速开发出所需要的代码。性能优化工具，针对一些性能做分析；同步数据工具，无论实时、异步的导出、传统的 ETL 工具，数据同步工具也是非常重要的；迁移应用工具，针对存量系统，能够快速去迁移到新的技术栈。新文件在数据库内帮助我们去评估系统代码是否符合现有规范。这几类工具会覆盖到数据库的各种阶段。

其次比较重要的是工具的开放性。为什么这么说呢？整个企业未来的 IT 和应用管理，将是一个数据化、智能化时代。需要数据进行一些联动。所以整个数据库的工具生态会嵌入到无论是能力开放、数据共享、还是集成，都会去整合到企业 IT 大环境里面去。

数据库是 IT 运维的一部分，如何整合到运维环境内，数据和工具都能够发挥一个更大的作用，用户使用起来也相对更放心。

 

Q&A 环节

Q：怎么评估国产库迁移的应用改造量?

梁刘红

当前的数据库的使用，还是一些主流数据库，譬如 Oracle、MySQL，OceanBase 针对这方面的兼容性，是有一整套专业的评估工具，在客户已有场景下，通过评估可以看到兼容性能够做到多少，包括语句兼容、性能调优。

梁铭图

关于数据库迁移的应用改造量有几个因素。第一是新的数据库迁移目标的数据库兼容性有多少，也涉及到代码改造量。第二是数据的迁移改造量有多少。有一些可评估的模型工具，是可以辅助做这方面的评估。

 

Q：国产数据库的成本是怎么衡量？

梁铭图

第一是商务的成本；第二是迁移成本，如果是存量系统的迁移。或是重新开发的开发成本；第三是运维成本。包括团队、工具体系、运维流程，都要做一定的调整。

梁刘红

其实对于国产数据库而言，早期企业不存在替换的问题。但是现阶段使用国产数据库就存在一个替换的过程。

在一开始起步阶段，使用国产数据库的成本确实有些大。但随着越来越多国产数据库被广泛使用，成本一定会降下来，工程师的学习成本降低了，运维服务成本降低了，应用改造的成本也会随着应用厂商逐步将国产数据库作为主流数据库去深度整合而逐步降低。当前我们正处在转型期，转型期的代价往往是比稳定期要大的，但只要渡过了这个阶段就一定会迎来更好的格局。

 

Q：OceanBase 在 Oracle 兼容性上能做到多少？

梁刘红

平均的统计数据上 OceanBase 的 Oracle 兼容性是超过 95% 的。但是有些客户用到的是深层次存储过程或者 Oracle 非常冷僻的语法。这个语法如果正好 OceanBase 现阶段没有去兼容，那 OceanBase 可以根据客户反馈及时增强兼容性。在不断的客户使用反馈中把兼容性和产品性能做好做强，需要越来越多的客户给予 OceanBase 在不同场景中打磨的机会。

Q：国产数据库在 OLTP 的表现如何？

梁铭图

可以肯定的说国产数据库在 OLTP 方面表现的还是很不错的。因为分布式在一些场景下，事务务必要控制，包括跨节点事务，毕竟是有一定消耗的。在设计场景的情况下，当做好分布式事务的回避后，国产数据库在 OLTP 的领域是没有问题的。

国产数据库在整体规划和设计好的条件下，OLTP 在某些层面上，并不比 Oracle 差，甚至可以超越。

通过两位老师的精彩分享，相信大家对数据库生态建设有了更全面的了解，也对数据库技术的未来发展有了更深刻更长远的期待。无论是 OceanBase 的生态建设还是还是各类云生态的构建发展，都离不开各位行业开发者的共同努力！

 

未来 OceanBase 将持续开展《对话 ACE》活动，敬请关注。