共计 4580 个字符，预计需要花费 12 分钟才能阅读完成。
欢送拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
对于作者
陈小伟
OceanBase 生态产品技术专家
OceanBase Developer Center 项目组核心成员，负责 ODC 开发者工具的整体研发工作。曾做过 TSDB 存储引擎、SaaS 安全软件，对数据库协同、研发效率、数据安全、云原生架构等有浓厚兴趣。
最近和市场部的同学聊天，提了一个问题给我：OceanBase 为什么要做一个相似 Navicat 的数据库开发工具？ 这个问题很好，不仅是用户，其实作为一个产品的实现者，在晚期启动 ODC 的时候，相似的问题同样也是咱们的困惑。
比方，作为一个守业阶段的数据库团队，为什么咱们要投入这么多的老本去做一个数据库开发工具？为什么 ODC 桌面版须要做成 Web 架构？为什么 ODC Web 版本须要依赖 OceanBase 作为元数据库？本文会介绍 ODC 诞生的起因，答复 为什么 ODC 不是另一个 Navicat，同时也分享 OceanBase 对数据库工具生态的一些想法以及对 ODC 将来的思考。
为什么会有 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。 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 官网获取更多信息：https://www.oceanbase.com/