最近和市场部的同学聊天，提了一个问题给我： OceanBase 为什么要做一个类似 Navicat 的数据库开发工具？这个问题很好，不仅是用户，其实作为一个产品的实现者，在早期启动 ODC 的时候，类似的问题同样也是我们的困惑。
比如，作为一个创业阶段的数据库团队，为什么我们要投入这么多的成本去做一个数据库开发工具？为什么 ODC 桌面版需要做成 Web 架构？为什么 ODC Web 版本需要依赖 OceanBase 作为元数据库？本文会介绍 ODC 诞生的原因，回答为什么 ODC 不是另一个 Navicat，同时也分享 OceanBase 对数据库工具生态的一些想法以及对 ODC 未来的思考。
数据库厂商自研开发工具可能并不是一个最佳选择，很多做 MySQL 兼容数据库厂商并没有选择去自研一个图形化客户端，比如 AWS Aurora 推荐使用 MySQL Workbench，TDSQL 推荐使用 SQLyog、Workbench，NewSQL 数据库推荐 DBeaver、Navicat、Workbench。
为什么这么多做 MySQL 兼容的数据库厂商都没有自研数据库开发工具？基于 MySQL/PostgreSQL 内核做深度自研的数据库，可以天然的兼容 MySQL/PG 相关的生态工具，帮助用户通过更加熟悉的工具换到新的数据库环境，在为用户提供平滑切换易用性的同时，也减少了数据库团队自身的研发投入，这个可能是最有性价比的路线选择。
ODC 诞生于一个非常朴素的想法，OceanBase 在开始的第一天就坚定选择全自研路线，这个路线决定早期阶段 MySQL/PostgreSQL等大家熟知的第三方客户端工具，无法“天然”的支持 OceanBase，所以，在研发数据库的同时，我们决定要为用户提供一款简单、好用、易用的开发者工具。
很多用户知道，OceanBase 提供了两种兼容模式。OceanBase 的多租户架构，创建租户时候支持 MySQL 兼容模式和 Oracle 兼容模式，第三方客户端在早期很难做到 OceanBase 的全面兼容。比如 OceanBase MySQL 兼容模式，可以做到网络协议的兼容，这意味着用户可以通过 MySQL 兼容的客户端连接。但受限于系统视图的特殊性，无法满足 OceanBase 用户全功能管理诉求。
对于 Oracle 兼容模式来说，在 OceanBase 产品早期阶段，缺少第三方图形化客户端工具来帮助用户连接 OceanBase Oracle 模式。本质原因是 Oracle 兼容模式是语法和字典表兼容而不是网络协议兼容，需要使用 OceanBase 客户端驱动（比如 Java 使用 JDBC）才可以连接 Oracle 模式。所以大家熟知的 Oracle 客户端，比如 PL/SQL Developer，没有办法连接 OceanBase Oracle 租户。
从功能层面来说，Oracle 兼容的复杂度比 MySQL 兼容要高很多，不仅仅是数据库内核需要更多研发投入，配套的工具产品也是一样。比如 PL/SQL Developer，Oracle 有丰富的内置程序包，支持自定义类型、PL 支持编译、调试等大量功能都需要有开发工具来配套，这些功能对第三方生态工具适配带来了非常高的挑战。需要数据库内核团队和生态工具团队更加紧密的协同完成研发，比如 PL 调试，没有 GUI 客户端这个功能的生命周期就不完整。
在这样的情况下，OceanBase Developer Center （ODC 开发者工具）诞生了。
先给出结论，ODC 并不是另一个 Navicat。ODC 提供了很多和 Navicat 、PL/SQL Developer 类似的功能，比如高效的 SQL 编写、查询结果的编辑处理、数据导入导出、可视化创建表、视图、PL 等对象、查看数据库状态、生成测试数据、PL 编译和调试 等等。作为一个数据库图形化客户端，ODC 已经能够满足大多数 OceanBase 开发者的需求。从这些功能来看，ODC 就是另一个功能范围更小的 Navicat，支持更少的数据库类型，支持更少的功能，准确的说目前 ODC 只支持 OceanBase 数据库以及 ODP Sharding 逻辑库中间件，作为数据库图形化客户端 ODC 支持的功能数量大约是 Navicat 和 PL/SQL Developer 的 30%~40% 。
但是上述功能只是 ODC 的一部分，ODC 并不仅仅是一个数据库图形化客户端，从 ODC 的完整功能来看，图形化客户端功能只占了大约三分之一。我们认为 ODC 不是另一个 Navicat 的最主要原因是产品的理念和要解决主要问题的差异。
回到本文开头我的一个困惑是 ODC 为什么是 Web 架构的？这其实是源于 ODC 产生诞生的背景，最初是在蚂蚁集团内部使用的一个平台，并不是一个客户端工具，这个点其实大家也能更容易理解为什么 OceanBase Developer Center 这样的产品名称会用于一个数据库开发工具。
蚂蚁集团经过十几年的技术演进，在数据库开发这个方向已经有一套非常成熟的协同模式，DBA 和 Developer 的占比大概是 1:600，大约 20 个 DBA 支撑着全站 10000 量级的线下线上应用，其中的核心应用覆盖 10 亿量级的用户规模。在这样的应用场景下，数据库的安全稳定运行至关重要，而如何实现数据库的安全稳定运行依托于研发规范和风险控制的系统化，而实现这一切的核心平台就是 ODC 。
OceanBase 商业化之后， ODC 也给到更多行业的客户使用，我们发现蚂蚁集团遇到过的问题在客户场景也同样存在，积累的经验也能够帮助客户解决问题。
回顾起来我们认为其实是身处这个数据快速增长的时代，很多问题都是共性的，蚂蚁集团的场景可以认为是近十几年来数据规模快速增长的一个典型示例。数量规模的快速增长，实际的构成是数据库实例数量和单库数据库容量的快速增长，这带来了数据库稳定性的风险，“烂” SQL造成的危害更严重了，冷热数据分离也变成数据存储架构的必选项。
伴随着数量规模的快速增长，行业的从业人员也在快速增长，但是不同角色并不是等比例去增长。在十几年前，一个 Oracle DBA 管理的数据库实例规模在 25 个左右，总数据规模在 5TB 左右。那么到现在的数据规模，你会发现如果按照之前的模式，DBA 数量是远远不够的，这对数据库开发协同带来了新的挑战。再有随着数据不断增长，数据违规使用、泄露带来的问题也逐渐被重视，近几年政府和行业逐渐完善相关法律法规，蚂蚁集团身处被严格监管的行业，在数据合规方面也积累了大量的经验。
上述问题和挑战总结起来包含以下三大类：系统稳定：数据量不断增长，对数据库稳定性带来风险，“烂” SQL 的代价比以往更大、数据备份恢复压力凸显；协同效率：数据库数量不断增长，DBA 工作负担越来越重，权限配置和 SQL 审核效率亟需提升；数据安全合规：政府和行业监管对数据安全合规越来越严格，企业本身对隐私数据保护也越来越重视，缺少有效的数据安全防护机制，合规风险之雷必须尽快排查。
ODC 并没有直接照搬内部系统，而是以蚂蚁集团经验为基础，并结合各行业客户的场景把已有的技术和经验转化为产品化方案。之所以这么做一方面是技术层面的原因，作为内部系统可以依赖大量中台基础设施，而支持私有化部署的商业产品则首先要去除中台依赖，另一方面是产品层面，从一个内部系统到商业化产品有一个重要的过程是做易用性提升。目前，ODC 已经解决的最主要痛点是权限管控效率、数据库变更风险控制以及数据安全合规方面的问题。并且随着这些年 OceanBase 在各个行业客户数量的增长，在金融、运营商、电商、政务、能源等很多行业的大型客户得到了验证。
下图是 ODC 产品架构，可以看出 ODC 的重点功能是在于如何安全、高效的协同开发，并且更加专注于针对 OceanBase 的适配。产品功能不仅支持私有云场景，同时也在 OceanBase Cloud 提供服务，满足不同场景客户对数据库开发效率和变更风险管控的需求。从用户视角看，ODC 作为数据库图形化客户端提供了一个 SQL 开发效率工具，作为数据库开发协同平台还帮助提升 DBA 和开发者的协同效率，保障数据库稳定运行，符合监管合规要求。
一个成熟好用的数据库应该有怎样的数据库工具和应用生态？简单来说各种各样的支持数据库的生态工具越多越好，越易用越好，包括商业的开源的，包括 数据研发、报表、应用开发 等通用工具，包括 ERP、OA 等通用应用，包括各行各业的解决方案等等。换位思考，站在 ISV、有自研能力的客户角度，需要的也不仅仅是成熟完整的产品，同样也需要有丰富的基础类库和 API，能够以较低的成本把一些数据库厂商才掌握的使用方式集成到 ISV/客户自己的产品/解决方案中去。
如何做好数据库开发工具生态，作为数据库厂商我们需要回答一个问题 “原厂做大一统还是让第三方产品更好用” ，显然让其他产品更好用是更加有效的一种方式。
现阶段第三方生态工具支持 OceanBase 的产品从数量和支持的功能范围来说还不能满足 OceanBase 客户的需求，我们在很多基础功能方面仍然只能选择自研工具产品来支持。当然也不是说未来 OceanBase 自己就不做 ODC 了，Oracle 的 SQL Developer、微软的 SSMS 都提供了完整的数据库开发运维功能，原厂提供基本的工具能力是必须的，这也是给开发者、ISV 和客户对 OceanBase 数据库的产品能力做一个示范。
我们也看到，除了原厂产品，还有比如 PL/SQL Deverloper 事实上成为了国内 Oracle 客户的首选，Redgate 为 SQL Server 提供了一系列企业级数据库监控、数据安全等功能，在 MySQL 已有数十种开源免费客户端广受欢迎的同时，商业化的 Navicat、DataGrip 也受到了大量开发者的关注和喜爱。
实际上我们也在不断投入开发者生态，比如通过给 DBeaver 社区贡献代码来支持 OceanBase 达到了基本能用的程度，类似的还有 Flyway、Canal、Chunjun 等等。除了开源软件也有更多商业软件支持 OceanBase，比如 Navicat 去年开始支持 OceanBase MySQL 模式，2023年3月1日发布的 Navicat 16.1.9 开始支持 OceanBase Oracle 模式，Navicat 的用户连接 OceanBase 有了另一个选择，这里也表达对 Navicat 感谢，我们后续也会更紧密的合作。适配一款新的数据库过程中其实遇到的问题还挺多的，接下来我们会投入资源来让适配 OceanBase 的过程更加简单，期待越来越多的生态工具能够适配 OceanBase，并且是深度适配，支持尽可能多的功能。
总的来说 OceanBase 在工具生态领域想做的一些事情，就是让开发者使用 OceanBase 更简单，也让相关生态工具适配 OceanBase 的过程更加简单。
OceanBase 开发者大会将会于 3 月 25 日在北京召开，在下午的「数据管理与服务技术专场」，我将分享的主题为《数据库协同开发的现状和发展趋势》，聊聊 ODC 的未来和思考，期待在现场和大家面对面的交流。如果您对此感兴趣，欢迎扫描下方二维码或点击文末“阅读原文”报名 OceanBase DevCon 2023。
