oceanbase和mysql比_OceanBase和Aurora差异

一时失言乱红尘 2022-10-25 05:56 389阅读 0赞

转自：https://cloud.tencent.com/developer/news/106398cloud.tencent.com

在系统设计目标上，OceanBase和Aurora的差异很大：OceanBase的扩展性是针对所有模块的，SQL引擎、事务引擎和存储都可以线性扩展；但Aurora是有限扩展，本质上是一个存储可以扩展的单机数据库。

因为设计目标不一样，Aurora和Oceanbase的整体架构差别也很大，Aurora可以认为是shared disk的架构，OceanBase则是纯粹的shared nothing架构。

Aurora相比于OceanBase最大的优势是实现简单，并且能做到和MySQL完全兼容。毫无疑问，Aurora为了得到这些好处，相比于OceanBase也放弃了一些东西。全面地对比需要很多分析，比如Aurora对OLAP优化比较困难，这篇文章主要聚焦在日志这一块。

日志输出

这里的输出是指把数据库的日志输出给外部系统，可能用于分析，也可能同步到另一个异构的数据库，类似于Oracle GoldenGate做的事情。

Aurora本质是单机数据库，日志量有限，并且日志有全局的log id，因此可以对外输出一个单独的日志流，OceanBase没有全局的log id，无法对外输出成一个单独的日志流，并且输出成单日志流会引入扩展性问题，也是不合理的。

OceanBase通过liboblog解析日志，借助DRC通过多通道同步到各种下游系统。因为liboblog要分析事务之间的依赖关系，处理schema变更，同时还要考虑利用observer的日志物理存储特点来优化性能，它是OceanBase非常重要也非常复杂的一个模块。因为Aurora放弃了扩展性，所以在这一块省掉了很多工作。

日志流划分

OceanBase基于partition做数据分片，并且用户可以通过table group建议rootserver把多个相关的partition调度到同一个observer上，最终大部分事务不会跨observer。

但Aurora的共享存储是基于block划分的，每个protection group服务一部分block，事务执行的时候很容易跨多个protection group，进而跨多个storage node。Aurora的日志会更分散。

不管是OceanBase还是Aurora，事务提交都要等日志持久化成功，但是observer大部分情况下只需要给两个备机发送日志，Aurora则需要给多个storage node发送日志。

小结一下:

1. 在OceanBase的设计里，日志流和block存储没有强绑定关系，日志流根据用户的schema定义划分，而不是根据block存储来划分。

2. 基于block的共享存储不感知用户的schema信息，虽然实现简单，但是失去了很多性能优化的可能：不仅不方便SQL operator下压，也不方便日志的聚合。

日志回放

Aurora在master instance宕机的情况下不用回放日志，但是如果storage node不可用了，还是免不了要回放日志的，而回放日志的量取决于缓存大小，checkpoint频率，在这点上Aurora比传统数据库并不会有本质的差异。

OceanBase的checkpoint间隔时间会长一些，但是如果Aurora要减少写入放大，在内存够的情况下，也应该尽量推迟checkpoint。本质上checkpoint频率是一种选择，选择频繁做checkpoint会导致写入放大，推迟checkpoint则可以减少写入放大，适当推迟checkpoint对两者都是有性能好处的。

只读instance

Aurora很大的贡献是优化了MySQL的IO，包括数据和日志的IO，但是相比于OceanBase，它需要给只读instance多传一份日志。

解释一下两者的差别：

OceanBase的Paxos成员所在的机器本身也提供数据服务，Paxos同步日志的时候把日志复制到follower上，follower回放日志就可以提供读服务。

Aurora的protection group只能提供block IO，不能提供数据服务，client要通过只读instance提供读服务，只读instance的buffer cache要和master instance保持一致，所以master instance就需要给只读instance发送日志流。

只读instance如果不回放日志，那么它就无法知道本地缓存的block是否有修改，理论上本地的缓存都是无法利用的，每次读取都要远程访问，性能较差。

另外OceanBase的只读replica是没有数量上限的，当数量特别多的时候，一个Partition的所有副本会组织成树状结构级联同步日志。

分布式事务

两个系统对分布式事务的处理不一样，OceanBase是正统的2PC，当一部分partition没恢复时，只影响部分数据的访问。

Aurora执行事务很容易跨Protection Group，因此它需要对分布式事务做极端的优化，结果就是Aurora在恢复的时候必须要要求所有的Protection Group都在线, 任意一个protection group没恢复，所有的数据都无法访问。

在同样的规模下，Aurora的可用性不如OceanBase，当然因为Aurora的设计目标并不是无限的扩展性，在系统的规模不大的情况下，Aurora的分布式事务优化是很好的选择。

NRW有更多的假设

OceanBase使用Paxos协议实现日志复制，Aurora使用R+W>N的quorum协议实现日志复制。两者看起来很像，但是R+W>N协议本身无法实现single copy consistency。Aurora对quorum协议应该是有补充的，甚至有可能改动之后和Paxos协议等价，不过没有公开的文档。

解释一下为什么R+W>N和Paxos不等价，Paxos协议的两阶段可以类比成CPU的load\_link和store\_conditional两条指令，Paxos协议用这两条指令实现了write once register。实现这两条指令最关键的点是acceptor应答prepare请求后做的承诺：一旦我应答了一个prepare请求，我就保证不再应答proposal no更小的accept请求。R+W>N的方案没有对应的承诺，即使引入版本号，它和Paxos协议也不等价。

单独依赖R+W>N无法处理双主的问题。因为无法容忍双主，也就无法容忍网络上延后投递的消息，要解决这些问题就需要其它的手段作为R+W>N方案的补充。

另外一个问题是成员组变更，即Paxos Group的reconfiguration, Lamport写过一个文档讲Paxos Reconfiguration的方案，NRW协议目前还没有文档描述经过严格证明的成员变更方案。

总结

这篇文章对比了Aurora和Oceanbase在日志系统上的不同点，除了扩展性差别很大之外，OceanBase日志流聚合效果更好，读副本不需要额外同步一份日志，并且在分布式事务参与者不可用的情况下影响更小。