发现一个Oceanbase的小秘密

前两天写了两天杂谈，周一上班就该回归技术了，实际上周末在家我也一直在看 OB 的文档。相对于其他国产数据库来说， OB 的文档还算是比较全的，不过这也仅仅是相对而已，对于要做一个 OB 的智能化运维工具来说还是十分不足的。幸好和 OB 的团队的交流还十分畅通，并且在开源社区上也可以提出一些需求。我想了解的内容应该会逐渐搞清楚的。

周末一直在梳理 OCEANBASE 的一些指标，所以对 OB 的一些细节做了比较认真的分析。通过这次分析，我们团队重新认识了一遍 OB 。以前我们仅仅是做 OB 和其他数据库之间的对比测试，重点还是在高可用，压测等应用层面为主的环节。这回需要构建 OB 的运维模型，因此关注的更为细致了。

通过这段时间恶补知识，我们的 OB 的理解也更深入了。通过学习发现 OB 的整体架构还是十分不错的。不过 OB 这样的分布式数据库，其逻辑结构，物理结构还是十分复杂的。 OB CLUSTER 、数据库、可用域、 OBSERVER 、资源管理、租户等等，这些概念有的是逻辑的有的是物理的，几条线穿插在一起相当复杂。

从物理结构这条线，一个 OB CLUSTER 可能会有多个物理节点组成，每个节点可以是一台物理机，也可以是虚拟机。每个 Node1 上可以运行一个或者多个 OBSERVER 。一组 OBSERVER 可以属于一个可用域（ zone ） ,zone 的目的是为了确保高可用，一个数据的多个分片副本，存储到不同的 zone 里，任何一个 zone 出问题，都不会丢失数据。数据库的用户通过 obproxy 可以连接到任何一个 OBSERVER 上来执行 SQL 语句， obproxy 会自动做负载均衡。

似乎这个架构还是十分清晰的，不过如果我们再深入一点，把 OB 的租户概念引入进来，那就复杂多了。租户是一个逻辑的概念，在一个 OB CLUSTER 上我们可以创建多个租户，对于用户来说，每个租户好像是一个独立的 OB CLUSTER 集群一样。

实际上我们的应用并不是直接连接到 OB CLUSTER 上的，而是连接到某个租户上，目前 OB 的租户有 MYSQL 租户和 Oracle 租户两种，通过连接租户的不同， obproxy 会自动转发连接。 OB CLUSTER 也会根据用户名的格式 user@tenant#database 来确定连接的租户。这种租户有点类似于 ORACLE 的 PDB ，不过差别还是很大的。 Oracle 的 PDB 在物理结构上有自己完全独立的数据文件，而 OB 的租户是完全逻辑的概念。通过资源单元， OB 可以限制每个租户可以使用的 CPU, 内存， IO 存储等资源，而实际上可能多个租户的资源都是共享的。所有租户的计算能力都是 observer 提供的。 OB 提供两种兼容性的租户，其逻辑架构又有所不同，也让整体架构变得更为复杂。在 MYSQL 租户中，有 database 的概念，而 Oracle 租户中只有 schema 。 Mysql 租户是完全和 Mysql 兼容的， Oracle 租户知识貌似 Oracle ，实际上和 Oracle 的客户端时不兼容的。在具体实现上，是在一个统一的架构上做了一层 Oracle 兼容性外壳。

OB 的资源管理做的十分严格，分配给每个租户的资源被严格的控制，一旦超出，则会产生报错。这种严格控制可以确保租户之间的强隔离，这对于一个企业构建一个广泛共享的 OB 集群提供了很好的保障。不过，这对于 OB 的运维来说提出了更高的要求，确保多租户的资源得到有效的利用和确保每个租户的资源在高峰期都不会出现不足，对于系统运维来说至关重要。

通过上面的简单介绍，我们可以看出 OB 是十分复杂的。因为其复杂，管理起来也就不那么简单了。我们的 D-SMART 要对接 OB 数据库，首先需要将其配置信息 CIB 和主要的监控指标都找出来。我们在分析的过程中发现了一个问题，那就是无论从 OB 的官方文档还是在数据库上，总是发现缺少一些能够找到 OB 集群的一些关键信息的视图或者系统表。

在 OB 的安装指南里，有一条查看系统资源的 SQL 语句，里面查找了一张系统视图 __all_virtual_server_stat 。不过我们无论是使用 show tables 命令还是在 __all_table 里，都查不到这些表的信息。

这些表都定义在什么地方呢？

在 OB 中除了 oceanbase 外，还有两个默认数据库， information_schema 和 Mysql 。 Information_schema 是 mysql 中访问数据库元数据的接口，并不是实际的物理数据库。

通过 show tables 命令看到面也有一个 TABLES 系统视图，按理说 Mysql 的 show tables 命令就是通过这个接口来查找信息的，我们来看看这个表里面有什么信息。

这些 __all_virtual_* 的系统表，所属的数据库是 oceanbase ，在 oceanbase 数据库里找不到任何踪迹，在这里居然都找到了， OB 把这些信息藏得够深的。

找到了这些表，我们就补齐了了解 OB 整个架构的所有信息了。这样我们就可以看到每个 OBSERVER 的磁盘使用情况了。在下面的 SQL 中，我们也可以看到 obproxy 的状态，了解每个 observer 的工作状态。

通过对 OB 的分析，我们既看到了国产数据库的巨大进步，也看到了其不足的地方。国产数据库除了提升自身的技术水平之外，知识生态，技术生态，服务生态的建设也十分重要。如果不能让大量的用户、第三方服务团队很好的了解国产数据库，那么国产数据库的应用还是会遇到巨大的阻力。来自未知的恐惧远甚于已知的害怕。