接上期
OceanBase 数据库的演进
在本节中我们将开始从OceanBase0.5到OceanBase4.0的演进过程。
2.1 OceanBase 0.5
OceanBase 自2010年开始研发下图中就是OceanBase0.5版本的整体架构图，此时的OB分为两层，存储层和计算层。上层是SQL层，无状态地提供SQL服务，下层是一个由两个服务器组成的存储集群：ChunkServer 和 UpdateServer。ChunkServer 的特点是具备自动分区和存储水平扩展的能力。UpdateServer 利用 Paxos 协议来实现强一致性和可用性。然而，UpdateServer 不具备分布式事务处理能力。这样的架构使 OceanBase 能够更好地支持类似淘宝收藏夹这样的业务。此外，它具有一定的可扩展性，尤其是读取方面的扩展性相对较强，并且 SQL 层是无状态的，可以自由扩展。
明显的缺陷也是有的，UpdateServer节点是单点的写，多节点读。在需要更高并发的情况下，难以进行扩展。此外，将存储层和SQL层分离会导致更高的查询延迟，网络的抖动难以控制，在对延迟抖动要求极高的情况下，控制延迟抖动是具有挑战性的。
2.2 OceanBase 1.0 至 3.0 为解决OceanBase在0.5中遇到的问题，OceanBase 放弃了先前的架构，开发了 1.0 至 3.0 版本，特点完全对等（P2P）结构。每个 OBServer 包含 SQL、存储和事务引擎。所有服务器除了能够同时存储数据外，还能够处理 SQL 和处理事务。垂直方向代表分布式可扩展层，而水平方向代表复制层。水平方向提供高可用性能力，而垂直方向通过不断添加机器来增强服务的整体可扩展性，这里采用了几种优化来实现低延迟。在独立模式下，本地执行计划、本地事务 API 以及消除读写操作中的网络开销实现低延迟。在分布式模式下，使用重复表并行执行引擎和多个分区索引，通过这些方法实现低延迟性能的关键因素。
从之前的版本到OceanBase 4.0 演进之前，原架构具有出色的可扩展性。在这种可扩展性下，使用 OceanBase 3.0 进行了 TPC - C 基准测试。OceanBase 是当时唯一通过 TPC - C 基准测试的分布式数据库。这也反映出 OceanBase 3.0 架构在水平可扩展性方面具有非凡的适应性。OB当时从3个节点扩展到1557个节点，OceanBase 的 tpmC 指数达到 7.07 亿排名，随着节点数量的增加，整个 tpmC 指标具有明显的线性可扩展性。在进行 TPC-C 评估时，OceanBase 使用了一个由 1557 台机器组成的大型集群，在八小时的压力测试中，它有能力每秒处理两千万笔交易。这一结果表明，先前的架构可以支持出色的可扩展性，而且这种可扩展性和并发处理能力几乎可以满足全球大多数当前在线服务系统的要求。此外，通过在分布式存储系统上采用单区域部署，OceanBase 在 2021年5月通过了 TPC-H 基准测试，在 30000GB 数据量下获得了超过 1500 万的QphH。
2.3 OceanBase 4.0 然而，随着业务需求的迭代，我们开发了 OceanBase 4.0 架构，OceanBase 4.0 具有以下特性：
更多分区：OceanBase 4.0 的架构降低了分区维护成本。此外，内存优化的作用不容小觑。在之前的版本中，每 2MB OB 维护一个元数据，元数据与数据的比例约为 1:1000。大表元数据的开销也会显著增加。
在迭代中，我们将存储内存开销设置为按需加载，从而仅在内存中保留根节点（非常小）。当用户需要访问元数据时，再加载叶子节点和数据节点。此方法减少了常驻内存的开销，优化了内存使用。
更多 DDL 支持：在 OceanBase 4.0 中，数据定义语言（DDL）允许用户轻松修改分区和更改主键。DDL 的实现相对简单。首先，创建一个隐藏表，并取得快照点前启动 DDL 的事务，然后锁定原始表的读写操作。
随后，使用数据操作语言（DML）语句补充隐藏表中的数据。最后，重命名原始表。该过程涉及三项关键技术， 1）表锁定，在进行修改时防止写操作；、
2）分区 DML（PDML），用于加速查询并简化代码；
3）直接插入，允许直接写入静态数据，从而避免内存过载并提供更快的速度，资源消耗更低：
在 OceanBase 4.0 中，生产规格从 16C/64G 降低到 4C/16G（CPU / 内存），从而提高了用户成本。
我们主要优化了以下方面，
1）线程栈优化，以减少线程局部变量，并使用 SmartVar 减少栈变量；
2）将元数据开销从按分区存储改进为按日志流存储，从而允许按需加载元数据；
3）通过默认激活输入限制提高稳定性，从而在 4C/16G 下实现更高的稳定性。
租户隔离：我们优化了租户耦合逻辑，主要体现在以下三个方面
1）租户级合并，默认合并行为由租户触发，而非整个集群；
2）租户级元数据，将元数据从系统租户调整到用户租户，并且 TableId 和 TenantId 解耦；
3）租户 I/O 隔离，将 Clog（提交日志）文件按租户拆分，SSTable 支持租户级 I/O 限制。
对于中小型企业，OceanBase 4.0 架构的核心变化是引入了动态日志流。最初，我们将事务扩展和存储扩展的粒度等同起来。然而，如果存储被划分为多个分片，事务处理和高可用能力也基于这些分片。在 OceanBase 4.0 中，我们将这两个概念解耦，因此多个存储分片将共享一个事务日志流以及与该日志流对应的高可用服务。
学习总结：
1 OceanBase 数据库的架构更新的非常快，且不断地更新迭代。
2 白皮书中明确了之前系统的问题，并说明的4.0改进的方法和具体的措施。
3 从日志流这个概念的提出和在4.0上实现，的确彻底的改变了OceanBase在原有扩展和性能之间的一些问题。
4 系统的能耗降低了，性价比提高了。
基于这部分的白皮书，说明4.0应该是上线OB首选的版本，且我需要研究什么是日志流，且日志流对于OB产生的好处和效益是什么,与事务的一致性。
今天就到这里，后面继续搞OB。
截止今天共发布
