OceanBase 的特性分析

OceanBase 的特性

OceanBase的优势

分布式事务

OceanBase是通过对原有2PC的改良，来实现分布式事务

2PC的问题

1. 单点问题。过度依赖协调者，一旦协调者出现问题，系统将无法正常运转，会有可能造成数据不一致
2. 参与者在等待其他参与者响应的同时，无法进行任何操作，处于阻塞状态，一旦参与者出现故障，协调者只能通过自己的超时机制发现
3. 效率比较低，用户感知到的提交时延是4次写日志耗时以及2次 RPC 的往返耗时

OceanBase的改良

OceanBase通过多副本（Multi-Paxos）,解决了2PC单点，阻塞和数据不一致的问题

如上图所示，当分布式事务提交时，会选择其中的一个数据分片作为协调者在所有数据分片上执行两阶段提交协议。还记得前文提到过的协调者宕机问题么？在 OceanBase 中，由于所有数据分片都是通过 Paxos 复制日志实现多副本高可用的，当主副本发生宕机后，会由同一数据分片的备副本转换为新的主副本继续提供服务，所以可以认为在 OceanBase 中，参与者和协调者都是保证高可用不宕机的（多数派存活），绕开了协调者宕机的问题。

在参与者高可用的实现前提下，OceanBase 对协调者进行了“无状态”的优化。在标准的两阶段提交中，协调者要通过记录日志的方法持久化自己的状态，否则如果协调者和参与者同时宕机，协调者恢复后可能会导致事务提交状态不一致。但是如果我们认为参与者不会宕机，那么协调者并不需要写日志记录自己的状态。

OceanBase在第一阶段所有参与者都回复prepare完成以后，即反馈事务提交成功，提升了2PC的效率
由于存在多副本，只要保证在prepare阶段，验证事务执行没有错误，协调者发出commit指令后，就可以乐观的认为，事务执行成功并反馈给事务发起者。OceanBase相信commit消息会被多数副本收到，多数副本收到消息以后，剩下的就交给他们自己同步

在上图中（绿色部分表示写日志的动作），左侧为标准两阶段提交协议，用户感知到的提交时延是4次写日志耗时以及2次 RPC 的往返耗时；右侧图中 OceanBase 的两阶段提交实现，由于少了协调者的写日志耗时以及提前了应答客户端的时机，用户感知到的提交时延是1次写日志耗时以及1次 RPC 的往返耗时。

OceanBase的问题

复杂查询的效率问题

OceanBase数据库在分区以后，在处理一些复杂的查询，比如跨分区键的多表join，不包含的分区键的查询，这些查询需要分发到每一个分区，甚至产生笛卡尔乘积。
问题
OceanBase 有没有提供类似于Mysql Binlog监听的功能，这样可以把一些复杂查询，放到ES上去处理

对于数据结构设计的要求非常高

正如上面讨论的OceanBase在没有使用到分区键的时候，查询效率非常低，这也是目前分布式数据库普遍的问题。

设计难点：

1. 就是在设计上要结合业务，充分发挥分区键的作用
2. 跨库关联的处理：字段冗余，绑定表（以某一维度为索引的数据，都放在一张表里），全局表（变更不频繁的，数据量不大）
3. 分页： 为了在跨分区的分页查询中，扫描更少的行数，需要在分库中查询出来以后，进行二次组装，并且查询第二页以后时，需要带上前一页排序字段最后的值
4. 简单的关联查询，可以通过多维度分库来实现（比如订单表通过userId的hash值分片，如果需要以商户维度来查询某一个店家的订单详情，为了避免全分区扫描，就需要创建一个订单id和商户的索引映射表，该表通过商户id分片，查询时，先通过商户id查出映射表里对应的订单，最后去订单表里带出订单详情），效率有所降低
5. 将OceanBase定位于事务性数据库（OLTP），专注于事务流水操作，把复杂的查询放到ES上去做

总结

OceanBase 特别适合于写多读少，对事务有比较高要求，高并发，大数据量的业务场景（例如金融领域）