前情回顾
前两天看到OceanBase4.0正是发布，不禁有点感慨，关注OceanBase已半年有余，第一次与OB相识是通过一次OceanBase的征文比赛，写了一篇《Hello OceanBase！开启OB二次开发》 的帖子，帖子最后对OB提了一些建议，今天回头看看，真心想给你点一个大大的赞，赞OB对用户体验的关注，赞国产数据库人砥砺前行，不负韶华的信念！
先回顾一下当初的建议：
OceanBase 4时代
让我们把时间拉回到2022年3月，针对上面的建议，看看当时的OceanBase3.1.2到如今的OceanBase4.0.0有了哪些变化。
部署
建议1：环境搭建相对比较复杂，毕竟是分布式部署，所以也可以理解，但是应该有一个像TiDB的playground这样一键搭建demo集群的小功能，可以方便用户快速上手；
当时使用TiDB的playground时，确实让人眼前一亮，说起来由于工作原因这一年接触国产数据也不下10种，能分分钟就部署好的数据库很少，尤其是分布式数据库往往会花费较长的时间，而且经常会遇到一些问题。对于一些小伙伴而言可能在这个阶段就已经放弃。对于成熟的产品而言已经不再是过去的“酒香不怕巷子深”了。尤其是现在国产数据库“卷”的程度，已经不容再让谁去穿街过巷的去寻找了！
OceanBase 4.0.0的部署改进：
- 步骤 1：下载并安装 all-in-one package
- 步骤 2：使用 obd demo 快速部署单机体验环境
评测&建议
评测：安装部署可以达到同类竞品的一流水准，得分：4.5分
建议：整体上使用obd demo可以达到快手上手的标准，实际上还可以做的更好，比如：
- 可以在单机上通过obd部署3节点的集群，每个observer使用不同的端口。
- 使用Docker Compose部署3节点的集群（这个功能我正在做）。
以上两点需要考虑的还是资源问题。虽然4.0是主打小资源，但是毕竟3节点是treble了资源。
资源
建议2：很吃资源，对于设备简陋的小伙伴想上手，门槛较高，经常遇到一些资源的问题导致部署失败，所以是否可以提供低配版配置；
资源是OceanBase 3时代的最大痛点，因此4.0主打的就是小资源。我个人习惯是在PC上通过docker或者WSL去搞一套环境，随手就可以玩一玩，但在3时代的时候显然会比较麻烦，经常遇到由于资源不足导致启动失败。但目前4.0时代，从实际运行看4C8G基本是可以正常使用的（目前主流的PC一般可以达到8C16G）。这很大程度上能让更多的喜欢OB的用户能随时随地随心所欲的去搞起来。
评测&建议
评测：OceanBase 4.0在资源上有了很大改进，这个毋庸置疑。但单机部署4C16实际上还是有优化空间的，想想mysql/postgres单机跑起来就百十兆的内存。因此，资源评测，得分：4.0分
建议：OceanBase 4.0 运行时资源使用的进步就不说了，这里提两个其他资源的建议：
- 作为一个开发人员来说，往往喜欢去撸撸源码，可能还会去提issue和PR，所以经常会对源码进行编译。而编译就不是4C8G可以解决的了，OB编译脚本中使用了并行编译
make -j$CPU_CORES)，每个clang编译进程最大使用内存约2G，按照我PC的配置12C16G进行编译的话（12*2=24G）内存使用会超出实际物理内存大小，经常会发生OOM，导致编译失败，不得不手动修改编译脚本，减少并行编译的进程数量。 - 编译时间过长，相信咱们OB内部开发的服务器配置一定很好，或者大部分编译是通过持续集成来做的，可能不一定会考虑编译时间过长的困惑，但对于开源的项目来说，一定是要面向社区用户的，所以一次完整编译好花费1~2小时（和编译boost库或linux内核的时间差不多）对用户说还是不太友好的。优化编译时间可以通过合理规划模块层级，避免重复引用头文件，另外目前看OB代码结构中头文件中引用了很多依赖头文件，是否可以通过“类前置声明”等手段，把依赖头文件尽量放在.cpp中。个人觉得编译时间的优化还是有很大的空间。
扩展性
建议3：就是上文提到的关于OB如何提供用户扩展接口？可能有人会觉得这是个鸡肋，但是往往可以解决一些企业级的应用的需求，在对标Oracle功能上也会加分。
这个问题目前看来还没有什么进展，该功能实际上是源于企业的真实业务需求，在金融行业和电信行业我都实际开发过这类扩展数据库的代码。无论是oracle数据库，还是现在很多国产数据库基本上都支持了这个功能，举几个例子，下面几篇文章是我早些时候写的，供参考：
尤其是PostgreSQL系的国产数据库，基本上都继承了PostgreSQL高度扩展的特性，给用户提供了更多的可能性。PostgreSQL的插件数以百计，是活跃社区的主要力量之一，通过插件，用户可以间接实现一些对oracle的兼容改造、可以实现数据库的监控工具、可以实现CDC工具、可以实现外部表的访问——FDW等等。
当然，对于开源数据库来说可以通过修改源码的方式增加用户定义的函数，就像《Hello OceanBase！开启OB二次开发》 这篇文章里面提到的方法，但是这种方式有三个比较明显的弊端：1. 没有标准化的接口，需要修改多处代码，工作量大，实现相对复杂；2. 修改是浸入式的，如果版本更新，需要重新合并用户自行修改的代码，升级成本高；3. 往往这种需求源于企业级应用，大多情况是使用企业版的OceanBase，企业版不开源，方案不可行；
注：这个需求我已经通过企业版对接的老师进行了反馈，同时也希望社区版支持这个功能。
接口/驱动
建议4：企业版中Oracle租户驱动接口可以再丰富一些。
在社区版中，mysql租户的驱动还是很丰富的，基本上兼容了mysql协议的所有接口。这里主要还是想说说企业版的一些问题，不知道放在这里是否合适。姑且先说一下吧。
在企业级应用中OceanBase 4.0提供了目前最主流的三种驱动，即Java、Python和C，其中Python是通过JDBC来实现的，并没有原生Python驱动。其实我之前的文章《MogDB企业应用 之 七种武器》论述过接口/驱动对企业应该的重要性。虽然，目前企业主流的开发语言还是Java和C/C++，但是只有这两种语言是无法满足企业需求的，像Golang、Rust、JavaScript等语言已经成为现代企业信息化建设开发语言的重要组成部分。
尾声
OceanBase 4.0 社区版充分的关注了用户的诉求，可以说是利用社区和生态的成功案例。不过作为开源项目，OB仍有需要改进的地方，比如，开源社区本身是要吸引更多的开发者加入，宣传产品的同时要让更多的用户，尤其是开发者自发的向社区做出贡献；同时可以设立更多的SIG组和用户组（比如用户需求的SIG组、金融行业的用户组等等），用户可以有针对性的向社区提出需求，有能力的用户（或组织）甚至可以提交自己实现的功能代码（如果插件功能提供了，用户也可以实现自己的插件来丰富OB的生态）。可能是我要求有些苛刻了，不过坦白讲，OceanBase 4.0确实给了我很多惊喜和对OB未来版本演进的期待。
最后，向国内包括OceanBase在内的所有砥砺前行的数据库厂商致敬！！！也向包括我在内的所有要求苛刻的国产数据库用户致敬！！！
，上面的一些建议其实有一部是针对企业版的想法。如果社区这边可以改进那就非常好了。总的来说还是希望社区能从技术演进上发挥其作用。而并不是以完全的宣传为主。可能有些我说的比较直接，也没有经过推敲。如果不对的地方请指正 
