作者：蔡飞志，OceanBase 技术部高级专家。负责 OceanBase 开源研发工作，毕业于北京大学，2014 年进入 OceanBase 团队后，先后从事 OceanBase 数据库代理、数据库驱动、分布式存储的研发，对数据库内核架构及业务场景有深入的了解和研究。
今年是我加入 OceanBase 开源团队的第三年，也是 OceanBase 正式开源的第三年，回望过去，不禁感叹时光飞逝。还记得我来到开源团队正式接手的第一个项目，就是 OceanBase 安装部署易用性的提升。三年过去了，我们依然走在打造一款真正好用的开源分布式数据库产品的道路上，努力前进着。
三年以来，我们收到很多关于 OceanBase 社区版各种各样的反馈，有不少称赞，但也不乏吐槽。其中我们最关注的，也是用户反馈最多的问题，是 OceanBase 社区版不够好用。
作为一款开源软件，如果易用性得不到用户的认可，即便这款软件能力或功能再强，用户也很难感知到它的价值，我们深刻认识到了这一点。于是，三年间，我们在提升产品易用性方面投入了大量的精力和思考。但是作为一个新生的团队，并不是所有人都有做开源的经验，也不可能一口气解决所有问题，所以我们选择用最“笨”的方法，认真倾听和思考每一条建议和吐槽，脚踏实地地解决用户真实的问题。
如今，OceanBaes 社区版还远远称不上是一款完全易用的产品。作为开源团队的一员，我有幸见证了 OceanBase 社区版每一点、每一滴的成长。今天，借三周年的机会，我想与大家分享一些我们和社区用户在易用性方面的思考和经验，也是开源三周年易用性的一个阶段性总结。
一、分布式数据库怎么上手
对于许多数据库用户来说，“分布式数据库”是一个令人望而却步的术语，因为它意味着复杂的架构和陡峭的学习曲线。一款产品即便有很好的性能、很强的功能，如果没人愿意学或者非常难以上手，那都是白搭。所以在思考如何提升易用性时，我们关注的第一个话题就是如何让入门用户更快地学习并上手使用 OceanBase。
坦白讲，在开源初期这方面我们做得并不好。在刚刚结束的 OceanBase 开发者大会上，我们的 CTO 杨传辉用“慢热型选手”来形容这款产品，这与 OceanBase 曾经“会者不难，难者不会”的形象有关。已经熟练使用的老手可以轻松体验 OceanBase 强大的功能和高效的运维能力，但是前提是你要成为一名 OceanBase 数据库专家。这并不简单。在开源之初，公共论坛上吐槽 OceanBase 对入门用户不友好的声音层出不穷。“你管这叫开源？issue、doc、tutorial 我去哪找？”“我在 GitHub 上点了几个文档地址发现都是打不开的外链”“最低配置就要 8 核 64GB，笔记本电脑跑不起来，需要额外花钱买机器我还用什么开源？”
这些问题的存在，与 OceanBase 过往没有为用户提供充足的配套工具和文档是分不开的。最开始引发我们关注易用性问题的是一封邮件，当时有一位充满热情的开源爱好者，想试用一下 OceanBase 社区版，但在经历了内存不足、磁盘空间不足、版本没对应等问题，整整花费了十几个小时才成功在自己的电脑上完成安装部署之后，他愤怒地发邮件给我们，吐槽这次痛苦的安装经历。这件事当时对我的触动很大，到现在我依旧非常感谢这位用户，因为这个契机，我们开始着手解决简易化安装部署的问题，在不久后的 2022 年云栖大会上，我们推出了 OceanBase 社区版 4.0，在 2C8G 资源上就可以部署（当然，这个资源配置我们建议用于测试环境），同时提供了一体化极简安装包和一键安装 OceanBase 集群服务，帮助用户在 2 分钟内完成快速部署，降低第一个部署门槛。
我们并没有止步于此，在接下来的时间中，团队进一步从降低部署成本、升级安装部署工具、提供更多文档的角度出发帮助新用户更快地学习和使用 OceanBase 社区版。
（一）部署成本
对用户来说，决定是否尝试一款数据库产品时，首先要考虑的问题是能否接受它所要求的部署成本。我们相信，一款适合真正易用的分布式数据库产品不应该依赖于高端的硬件和设备基础，所以我们在不断进行产品轻量化、小型化迭代。最初，社区版的最低配置要求为 32C64G。我们逐步将其降低到 2022 年的 2C8G，再到现在的 2C6G，我们在逐步降低产品对于 CPU 和内存的依赖。
这就足够了吗？曾经我们是这么以为的，但直到有一次我们和高校用户深入交流之后，才发现长久以来有一个关键的问题一直被忽略掉了：存储！我们之所以一直没有关注存储，是因为我们曾经“认为” 58G 这个存储配置要求相比 CPU 和内存来说太廉价了。但对于未走出校门的学生用户来说，他们使用的电脑多是 Windows 或 MacOS，而 OceanBase 目前只支持 Linux 系统，这也就意味着很多学生会选择从云厂商购买 Linux 服务器来安装使用 OceanBase。
于是，我们研究了目前主流云厂商提供的服务规格，结果却发现在所有满足 OceanBase 基础 CPU 和内存配置的套餐中，提供的磁盘容量都无法满足 OceanBase 磁盘容量最低 58GB 的需求。因此，要安装 OceanBase，就必须要额外增加存储成本，对学生来说这都是难以接受的负担。今年，OceanBase 社区版将最低 58GB 的存储配置要求优化为 20GB，且其中的 16GB 是真正数据存储，预留 4GB 日志存储，而这个磁盘容量在主流云厂商提供的满足 2C6G 配置要求的服务包中都基本可以达到。这也就意味着，需要购买云服务器安装体验 OceanBase 社区版的用户终于不用再付出大量额外成本了。
（二）安装部署工具
部署成本只是上手分布式数据库的第一道门槛，对于入门用户来说，是否有好用的工具能够帮助用户简单快速地把数据库部署起来是第二个考验，很多入门用户由于安装程序复杂，在这一步就已经放弃了。OceanBase 曾经只能通过黑屏的命令行进行安装部署，而且还有大量的生态工具，需要逐一学习、部署。对入门用户来说，非常耗时甚至有令人沮丧的体验。
为了帮助用户快速安装部署 OceanBase，我们推出了 OceanBase 社区版集群安装部署工具 OBD（OceanBase Deployer），OBD 提供了白屏部署的能力，同时将生态工具都整合到一个部署界面里，对于用户来说，只需要通过 OBD 就可以完成大量安装部署工作。此外，OceanBase 运维管理工具 OCP（OceanBase Control Platform）也提供了图形化的白屏部署功能，用户可以按照需求选择部署方式实现快速安装部署。
部署工具不少，但并不意味着这些工具真正满足了用户的需求。我们会定期邀请企业客户进行面对面的交流，也就是“企业行”活动，通过这些活动我们可以更加直观地收集用户的使用体验。在某次“企业行”活动中，一位用户分享了他们公司使用 OceanBase 开源部署工具的曲折经历。这家企业一开始用的是黑屏工具 OBD，但是因为 OBD 有许多功能缺陷，比如无法支持扩容，所以用起来不太顺利；后来有了图形化运维管理工具 OCP，他们立即换用 OCP 进行部署和运维，但是又发现 OCP 有一些 API 是缺失的，平台存在 bug，而且安装还依赖于特定的硬件。结果就是两个平台都没法百分百满足他们的需求。
为了解决这个问题，2024 年，我们把 OBD 与 OCP 两个工具的功能进一步融合，用户通过 OBD 进行安装，安装之后能够直接运行 OCP，并使用 OCP 完成各种运维管理操作，最终快速完成整个安装部署过程。
（三）产品文档
有了安装部署工具，接下来要考虑的就是当用户在产生问题时能否快速解决。产品文档是用户入门离不开的工具，当遇到问题时，多数用户第一反应一定是找相关的文档做参考。然而，产品文档一直是我们面向开源用户的老大难问题。虽然从 OceanBase 2.x 版本的 1972 篇文档，到 3.x 版本达到 2991 多篇，再到 4.x 版本 3931 篇，每个产品迭代都至少会新增 1000 多篇文档，但是总体来看，我们的文档相对于国外知名数据库文档的丰富度还有差距。
决定用户文档使用体验的不只是文档数量，我们在文档的体系、内容和使用等方面，根据用户的反馈都进行了一些改进。
- OceanBase 4.0 版本之前，社区版和企业版的文档是两套独立的体系，在进行维护和更新的时候难免会出现不同步，这就导致了用户有时没办法及时找到最新的内容。4.0 版本之后，我们对两套文档进行了合并，这也是得益于 4.0 版本以后开源和企业版的产品能力基本一致。我们的用户再也不会遇到文档不同步的问题了。
- 曾经 OceanBase 用户在遇到问题需要参阅文档的时候可能会觉得很麻烦，因为我们的文档只是对产品功能点进行了简单的罗列，解决一个问题的信息可能散落在不同地方，需要用户自行查找。为了解决这个问题，我们提炼了一些具体的使用场景，并针对各场景新增了一些场景化文档，用户只需要根据遇到的问题场景选择对应的文档，就可以一站式快速解决问题。
- 文档只是平面的信息，并不能让用户直接产生真实的使用体验。于是，我们进一步为文档提供了在线体验功能，文档里面涉及到每个操作都可以直接拷贝并在云环境里直接运行，让用户看到执行的效果。
- 在改进文档系统之外，我们还推出了“知识库”功能。当用户遇到问题时，无论是翻阅文档，还是求助问答社区，其实都无法实现真正的自助化。于是，我们整理了超过 1000 条来自 OceanBase 以及蚂蚁集团的 DBA 多年在客户场景里积累的产品使用和问题处理的实践案例，以及问答社区中广大用户的经验智慧，收录到知识库中，当用户遇到问题时，通常都能快速在知识库中找到适用的经验，从而自助解决问题。
总体来看，虽然 OceanBase 社区版在用户入门门槛和部署难度方面有了一些进步，但是我们仍有许多问题需要解决。比如，我们的文档目前还不够完善，有用户提到目前我们还缺少类似于 Oracle MAA 这样的最佳实践文档，以及在性能优化、故障诊断等方面的权威文档。
在安装部署方面，我们也正在积极推进 OceanBase 在 MacOS 和 Windows 上的适配工作，未来计划在 MacOS 上支持以安装一个 APP 的方式，即通过简单的拖拉拽操作，就可以安装 OceanBase，不需要用户了解数据库或者 OceanBase、甚至是 Linux 命令行。我们希望未来能够帮助更多人轻松入门分布式数据库。
二、分布式数据库怎样才能有更好的性能
OceanBase 作为一款原生分布式数据库，性能还是有目共睹的，但并不是所有人都了解如何最大化地发挥它的性能，于是如何帮助用户快速提升数据库性能就成为了我们在讨论产品易用性时关注的第二个话题。
我们曾经遇到过一次有趣的“乌龙事件”，有一次，一位做个人网站的同学联系到我们，说感觉被 OceanBase“欺骗”了，他安装了 OceanBase 社区版并进行了性能测试，结果发现 OceanBase 的性能比不过 MySQL。后来，我们团队和这位同学一起进行了分析，结果发现他是使用默认的安装模式安装了 OceanBase，而在他这种小规格的使用场景下，默认的配置并不合理，从而影响了性能。后来在开源团队协助下，他重新调整了配置，数据库性能也得到了大幅提升。受到这次事件的启发，在 2C8G 小规格场景下提升默认模式安装后的性能便成为了我们目前的一个工作方向，预计将在不久的将来与大家见面。
除了这一场景，为了在不同的使用场景下实现性能最大化，需要配置不同的参数，比如在 TP 或者 AP 的场景下需要对并行的线程数进行对应的调整，这对开发人员使用 OceanBase 的技能水平和熟悉度是一个考验。因此，我们还对 OceanBase 所支持的许多场景的参数进行了模板化，将这些参数模板提供给用户，从而帮助用户轻松快速地享受到较高水平的数据库性能。
三、分布式数据库怎样轻松完成诊断
许多用户在使用分布式数据库的时候最头疼的一点可能就是如何快速诊断和解决问题，轻则影响用户体验，重则造成业务不可用。这是因为分布式数据库涉及大量节点和组件，集群规模大，用户请求链路复杂，定位问题出现在什么环节、找到解决的方法往往涉及到机器环境、配置参数、运行负载等多种因素。特别是对于开源开发者来说，诊断工作还是相当繁琐的。在大部分场景下，OceanBase 的问题可以通过环境分析、日志分析、性能视图分析这三种方法去解决。OceanBase 运维管理工具 OCP 虽然已经开源，但处理的更多是运维监控工作，如何帮助用户在运维的基础之上完成诊断工作是开源团队面临的一项重点问题。
（一）怎样做一款 DBA 能快速看懂的日志？
OceanBase 的 debug 日志一直以来可谓饱受吐槽。例如，过去我们在与 vivo 交流的过程中，用户吐槽我们的日志“不是给 DBA 看的”，日志庞大又繁杂，DBA 根本看不懂，只能先将大量日志收集起来，再转交给研发工程师解决，过程极为耗时。
事实上，原先我们的日志真的不是给 DBA 看的。OceanBase 在开源之前，一直履行商业化的服务模式。我们在设计日志时，原定的问题解决路径是用户在遇到问题时直接把日志反馈给我们的工程师，我们再为用户提供一对一的服务，所以只要我们内部那一批工程师看得懂就足够了。但是作为一款开源软件，需要帮助用户构建自主解决问题的能力，此时这种天书一般的日志对于 DBA 来说就是一场噩梦了。
于是，在 OceanBase 最新版本中，我们将整个 OceanBase 运行过程中常见系统事件汇总到了一起，为用户提供了 alert.log 日志功能。通常一个开发者遇到的 80% 的问题只需要看 alert.log 就可以快速解决，不需要看更复杂的 observer.log，从而减轻 DBA 的工作负担。
（二）怎样诊断瞬时发生的异常？
通常，数据库性能报告提供的是小时级别的快照信息，帮助用户解决持续时间相对较长的问题。但是如果数据库遇到一些瞬时发生的异常、抖动，就很难直接从性能报告上得到详细的执行细节，需要为用户提供更加细粒度的诊断信息。于是，我们发布了能够提供会话级别诊断信息的工具 ASH（Active Session History），也可以理解为 OceanBase 数据库的性能 perf 工具，它可以记录数据库中所有活动会话的信息，为用户提供定位瞬时发生异常的分析报告，包括持续出现几分钟的瞬时性能问题，以及各种维度（例如时间、会话、模块、操作或 SQL 语句）的性能问题，从而帮助用户对数据库进行诊断和调优。
ASH 看起来简单，但是实际做起来非常有挑战。为了做好 ASH ，我们内部专门成立了一个由多位资深内核研发人员组成的性能诊断团队，整整花了一年多时间，专注于把 OceanBase 后台所有任务、锁、等待事件、进队列、出队列等时间做准确这一件事情，最终 ASH 才得以与用户见面。
（三）怎样帮助用户进行一键诊断？
无论是看日志、看性能报告，都还是需要用户耗费一定的时间和精力。能否有这样一款工具，让用户能够一键进行诊断？
在产生做这样一款一键诊断工具的想法的时候，我们的第一个反应就是，既然是帮助用户减轻诊断难度，那我们为什么不直接让用户来决定这个工具应该长什么样？过往，我们的研发模式更多的是内部对需求进行排期，然后按部就班地进行开发，这样做出来的产品或功能不一定是用户最终想要的。特别是对开源产品来说，闭门造车是不可行的。于是在开发这款敏捷诊断工具时，我们在功能设计阶段就让用户参与进来，做用户真正需要、真正喜欢的产品。
obdiag 就是这款旨在降低开源用户诊断难度的轻量化工具，它能够高效获取故障场景下分散在各个节点的信息，并挖掘出其中的关联性，从而帮助用户自助诊断问题。我们希望这款工具做到真正的简单易用、高度可扩展，可以支持用户一键部署安装，并用一条命令快速完成一键巡检、一键诊断信息收集、一键根因分析等功能。
2024 年 5 月，社区成立了 obdiag SIG 特别兴趣小组，公开召集开发者加入、建言献策。我们特别留意了下，在最近的一次 obdiag 设计评审会议中，共有 16 个人参加，其中 11 位都是外部真实的用户和开发者。我们也希望通过共建，社区用户和开发者可以根据自己在实际生产过程中积累的经验帮助产品升级迭代，同时将自己的产品使用经验贡献回社区，形成良性循环。
虽然 OceanBase 已经具备了多种诊断能力，但是仍有许多深层次的问题有待解决。例如有用户提到，数据库抖动、卡顿等性能问题的诊断工具需要升级；也有用户认为 OceanBase 的 debug 日志相对 Oracle 来讲易用性、可观测性仍然偏弱。我们也希望继续与开发者和用户协作，未来补齐更多 obdiag 的自动化能力，例如增加更多场景案例，让用户在遇到问题时无需参照以往事库，通过诊断工具便可以根据历史问题快速完成分析。另外，目前 obdiag 还不支持对 OMS 等生态工具进行诊断；未来，我们希望把更多生态工具的诊断功能逐步并入 obdiag，帮助用户完成一站式诊断。
四、怎样打造更丰富的数据库生态
OceanBase 是一款根自研的分布式数据库产品，与其他基于现有架构建立起的数据库相比，除了有更高的研发难度，还面临着如何与周边各种技术生态适配的问题。
在真实的生产环境中，用户需要的不仅是数据库本身，同样重要的还有建构在数据库能力之上的，满足更高层次需求的能力。基于现有架构的数据库能够相对比较平滑地接入各种技术生态中，但对于 OceanBase 来讲，打造一个开放的技术栈并非易事。
OceanBase 的生态开放主要涉及四个层面：
- 首先我们要解决的是基础设施的兼容和适配。例如，作为一款原生分布式数据库，OceanBase 为什么不能运行在 Kubernetes 上呢？于是我们与 Kubernetes 进行了适配与对接，支持以 k8s-operator 的方式部署 OceanBase，也给 k8s 生态的其他项目例如 KubeBlocks 提供 OceanBase 插件；此外在龙蜥、欧拉、统信、麒麟等操作系统上也完成了认证和深度适配，可以在这些操作系统的软件源直接安装 OceanBase。
- 在多种基础设施上把 OceanBase 部署起来之后，用户能有什么方式简单快速地把这些数据用起来？于是，我们对数据集成生态进行了对接。以大数据生态为例，目前 OceanBase 已经与 Flink、Canal、SeaTunnel 等大数据生态工具进行了适配，帮助用户更方便地把数据库中的信息利用起来。
- 落地到各种场景中，OceanBase 的用户是否可以方便地完成各种数据治理功能？我们希望将 OceanBase 与更多数据治理工具对接起来。以 BI 和报表为例，我们已经完成了与 Tableau、PowerBI、FineBI、Superset 等非常流行的商业和开源 BI 产品的适配，且仍在继续推进，实现更广泛的生态合作。
- 另外，我们也在进行应用集成层面的开放，计划在 ORM 框架、连接驱动、中间件等多个生态中实现开放连接。
OceanBase Landscape 技术生态
通过技术生态开放提升产品易用性对我们来说甚至可能比提升产品内核能力更加重要。2023 年，为提升 OceanBase 与 MySQL 兼容性，Binlog Service 项目成功落地，这一项目帮助 OceanBase 成功对接超过 20 多个下游生态，包括一些 MySQL 订阅工具以及基于 Binlog 云服务。当年，Binlog Service 项目甚至 pk 掉了代表产品核心能力提升的列式存储项目，获得了象征 OceanBase 产研团队每年最高成绩的“产研突破大奖”。
我们在做生态对接的时候希望能够深度合作，并不只是相互贴个 logo 而已。于是，今年我们面向应用开发者打造了 Developer Hub，汇集了应用开发使用 OceanBase 所需的示例程序、数据集成与开发工具，以及相关的文档和学习资源，就是为了在完成生态适配之后，让大家知道这些工具究竟能以什么方式切实地用起来，解决大家的问题。为了帮助开发者更快地把工具运行起来，除了文档之外，我们还为大家还提供了开源样例仓库，开发者能够在这里直接找到数据代码，直接下载运行。
*开源样例仓库：https://github.com/oceanbase/ob-samples
五、怎样让数据库从社区中来，到社区中去
OceanBase 开源社区建立时间并不算长，相比国际知名的开源社区仍有许多不完善之处。我们诚挚地希望有越来越多的开发者可以加入 OceanBase 的开源项目共建，有越来越多的用户可以加入 OceanBase 社区分享自己的宝贵经验。
1. 更多的用户声音
细心的用户可能已经发现了，OceanBase 开源社区最早的口号是“及时响应”，代表着我们希望社区可以成为我们第一时间解决用户问题的渠道；后来，我们的口号变成了“社区互动”，这是因为我们不仅希望为用户提供一个技术交流的空间，更希望能够连接广大开源开好者，帮助大家找到志同道合的朋友。我们也欣慰地看到如今有越来越多的成员在社区主动分享经验、为他人解决问题。
截至目前，有超过 118 位开发者开通社区博客，发布了超过 1000 篇技术文章，社区问答互动数超过 5.3 万条，超过 3000 位社区成员自发地解答他人的问题，社区内产品文档与知识库数量超过 8000 条。2023 年，OceanBase 用户组织 OUG 也步入正轨。我们和用户一起办了大量 “城市行”和“企业行”活动，走进用户、深入倾听用户的声音。
2. 更多的开发者贡献
对于一款开源产品来说，开发者是保持开源社区活力的源头。为了让想参与 OceanBase 开源贡献的开发者有更好的体验，我们在 GitHub 的搭建上进行了多轮优化。
- 首先是各类开发文档的补齐。有一次，一位开发者在我们的社区提交了一个 PR，我们看到以后非常开心，但是仔细一看，才发现他的命名风格不符合我们的代码规范，根本没办法直接采用。向这位开发者反馈之后，他很无语，因为当时没有办法从任何线上公开渠道去了解我们的代码规范，这不是难为人吗！曾经，OceanBase 并没有公开统一地发布诸如数据结构、编码风格等开发者需要的材料，开发者想为社区做贡献，需要从网上的各个角落搜集碎片化的信息，甚至需要直接联系到 OceanBase 的工作人员才能了解这些规范。为解决这一问题，我们整理了开发者需要的全链路文档，并全部上传至 GitHub，开发者可以直接获取文档，快速完成社区贡献。
- 其次是研发模式的优化。4.0 版本之前，OceanBase 企业版和社区版是两个不同的分支，开源分支并不能及时与主干分支进行同步，这就导致许多在开源分支上作出的贡献可能在主干分支已经实现了，对于想进行贡献的开发者来说，完全是浪费时间。4.0 版本后，社区版和企业版融合成一个主干代码的研发分支，产品最新的功能和迭代都能第一时间在 GitHub 上看到，帮助开发者更有效率地进行贡献。
- 另外我们对开发者的贡献体验也进行了提升。曾经，外部开发者做功能贡献的时候，需要联络 OceanBase 工作人员把 PR 拉到内部的平台上进行测试，开发者无法直接看到运行测试的结果。2024 年初，我们在 GitHub 上的 CI 测试程序上线，开发者可以直接在 GitHub 上自助完成测试验证工作。
三年中，有很多我们与开发者共建的项目真正落地到了 OceanBase 产品之中， 助力了产品功能升级，这让开源团队感到非常自豪。例如，在与携程用户的交流之中，我们得知他们在使用 OceanBase 社区版的时候遇到了一些问题，因为 OceanBase 缺乏类似 MySQL 的索引统计功能、详细的表级增删改查统计功能等，导致运维难度增加。于是，携程积极参与到了开源贡献中，和 OceanBase 共同完成了索引统计功能的合作开发，并在 4.3 版本中正式并入社区版源码。如今，用户可以很方便地在社区版产品上完成例如统计索引被引用的次数和频率、统计读写访问次数等对于数据库运维来说非常重要的功能。
截至目前，OceanBase 的 GitHub 仓库吸引了超过 300 位贡献者，其中有超过 5 万行代码是由来自社区开发者贡献的。虽然并不算令人惊艳的成绩，但这是一个好的开始。未来我们计划对 OceanBase 进行更多插件化的改造，帮助更多开发者更方便地参与到社区贡献之中。
六、打造一款真正好用的开源分布式数据库产品
回顾过去三年，我们和开发者共同努力，在提升 OceanBase 社区版易用性方面做出了许多改进，但我们知道，这只是一个开始。要打造一款真正好用的产品，我们还有很长的路要走。要帮助用户实现完全自助使用，还有不少的提升空间。未来，我们计划在以下几个方向进一步提升 OceanBase 社区版的易用性，帮助更多用户和开发者更好地使用这款分布式数据库产品：
- 工具补齐与丰富：目前我们已经开放了 ODC、OCP 等生态工具，但对很多深层次需求仍然需要不断丰富各种工具，解决用户的问题，比如数据库抖动、卡顿等性能问题的诊断工具开发等，并进一步开放相关工具的 API。
- 更开放的 OceanBase Landscape：作为一款根自研的分布式数据库，我们希望 OceanBase 能够进一步对接到更多更大的技术生态中去，例如大数据生态、数据开发生态、以及现在比较火的 AI 基础设施生态等，让我们的用户获得更多、更丰富的功能体验。
- 自助自动的用户答疑体验：虽然我们为用户提供了一些解决问题的材料和渠道，我们的问答社区也已经有许多社区开发者和用户进驻、交流和回答社区中的问题，但是问题得到解决的速度可能还无法满足所有用户的诉求。我们计划在未来支持利用大模型的能力，构建知识库机器人，让 OceanBase 的文档、知识库以及社区沉淀的问题能够更方便地被社区用户使用起来，获得更加自助化、自动化的答疑体验。
- 配套材料升级：易用性是一个全方位的话题，不光是产品内核上的改动，还包括文档、官网、社区等许多层面。未来，我们希望进一步丰富产品文档，提升文档搜索的准确度，提升官网文档版本切换的易用性，带给大家更好的使用体验。
回顾过去三年，参与并见证 OceanBase 社区版一路成长，仿佛经历了养育孩子的过程。如今，那个襁褓中的婴儿已经长大成为刚开始懂事的小学生，但这也仅仅是万里长征的开端。
三年只是一个开始，未来还有很长的路要走。在此，我们向提出反馈和建议的每一位用户表达衷心的感谢！你们的关注和支持，是推动我们不断前行的动力。最后，我们诚挚地邀请更多开发者参与到 OceanBase 开源社区中来，一起打造一款真正好用的开源分布式数据库。
打造更好用的开源分布式数据库，脚踏实地，一路同行！
