OceanBase 的介绍

OceanBase 的介绍

OceanBase 是蚂蚁集团（Ant Group）自主研发的一款高性能的分布式关系型数据库。它最早于 2010 年开始开发，最初的目标是为蚂蚁集团的金融业务提供强一致性、高可用性和高扩展性的分布式数据库解决方案。OceanBase 经过了蚂蚁金服多个核心业务场景的验证，特别是在 双十一 购物节的海量交易中，展示了极强的处理能力和稳定性。

OceanBase 在架构设计上采用了无共享（Shared-Nothing）架构，具有高可用性、强一致性、可扩展性和高性能的特点，广泛应用于金融、互联网、政府等高负载、高并发的场景。

OceanBase 的架构

OceanBase 的架构由多个功能模块构成，以下是其主要架构模块：

  1. SQL 引擎：负责解析 SQL 语句，生成执行计划并执行查询。OceanBase 的 SQL 引擎支持复杂查询、事务处理、索引优化等功能，具有强大的关系型数据库查询能力。
  2. 存储层：数据分布式存储在多个节点上，采用多副本机制保障数据的高可用性。数据被划分成若干个分区（Partition），每个分区可以独立进行负载均衡、扩展和备份。
  3. 事务管理：OceanBase 支持分布式事务，通过 两阶段提交（2PC） 和 Paxos 协议来确保在分布式环境下的事务强一致性。事务管理器负责对多节点的事务进行协调。
  4. 日志模块：OceanBase 采用 Redo 日志 和 Undo 日志 机制来保障数据的一致性和持久性。日志在多个节点之间同步，并通过事务日志确保系统即使在故障后仍然能够恢复到正确状态。
  5. 调度和负载均衡：OceanBase 提供智能调度和负载均衡功能，自动将数据和请求分配到多个节点上，以优化系统的资源利用率，提升查询和事务处理的性能。

OceanBase 的应用场景：

  1. 金融行业： OceanBase 最早在蚂蚁集团的金融业务中使用，处理了海量的交易请求。金融行业对于数据的一致性和安全性要求非常高，OceanBase 通过多副本机制和分布式事务处理能力，保障了金融数据的强一致性与高可用性。
  2. 互联网和电商： 在互联网和电商行业中，像双十一购物节这样的高并发场景对数据库系统的要求非常高。OceanBase 的分布式架构和横向扩展能力，使其能够在面对海量订单和支付请求时，保持高效的处理性能和低延迟。
  3. 政府与公共服务： 政府和公共服务系统通常需要高安全性、可扩展性和容灾能力。OceanBase 的容灾机制和扩展性可以确保这些关键业务系统在高负载情况下仍然保持稳定，并在灾难发生时快速恢复。

典型案例：

  1. 双十一购物节：OceanBase 在蚂蚁集团的双十一大促中，处理了数亿笔交易，展示了其极强的扩展性和稳定性。
  2. 支付宝：OceanBase 支撑着支付宝海量的交易处理需求，保障了用户支付的实时性和准确性。
  3. 其他金融机构：OceanBase 也被应用于其他银行和金融机构的核心业务系统中，帮助它们提升数据管理和处理能力。

Q：为啥双十一用Oceanbase呢？

关键在于 OceanBase 的以下优势：

  1. 原生分布式架构：OceanBase 采用无共享架构，具备高度的横向扩展能力，能够轻松应对双十一期间的流量暴增，而 MySQL 依赖于复杂的分库分表方案，扩展性有限且管理复杂。

    • 横向扩展是通过增加更多的服务器或节点来提升系统的整体性能和处理能力。

    • 纵向扩展是通过增加单个服务器的硬件资源（如 CPU、内存、存储空间等）来提升系统的处理能力。

  2. 高写入性能：OceanBase 通过内部读写分离和 LSM 树存储引擎，提升了写入性能，能够高效处理双十一的大量订单和支付请求。相比之下，MySQL 的 B+ 树结构在高并发写入时易产生性能瓶颈。

  3. 强一致性与高可用性：OceanBase 基于 Paxos 协议保证数据的强一致性，并具备城市级容灾能力，能够在极端情况下迅速恢复【Paxos 协议 保证了分布式系统中的数据一致性和快速故障切换】，确保 RPO=0，RTO（Recovery Time Objective） 小于 30 秒。而 MySQL 主要依赖主从复制，容灾和故障恢复能力较弱。

  4. 灵活分区机制：OceanBase 内置分区和二级分区功能，取代了 MySQL 复杂的分库分表方案，简化了管理并提升了性能，适合处理双十一的海量数据。

  5. 金融级可靠性：OceanBase 已在金融行业成熟应用，具备处理高并发和高一致性要求的能力，尤其适用于双十一这样对数据准确性和可靠性要求极高的场景。

比对MySQL

架构

OceanBase

  • 原生分布式架构：OceanBase采用无共享（Shared-Nothing）架构，即每个节点都是独立的，拥有自己的SQL引擎、存储引擎和事务引擎。这种设计确保了系统的高可扩展性和灵活性。
    • 无共享（Shared-Nothing）架构是一种分布式计算架构，它的特点是系统的各个节点之间完全独立工作，没有任何共享资源（如磁盘、内存、锁等）。
  • 完全对等节点：所有节点在功能和角色上是对等的，没有主从之分，任何节点都可以处理读写请求。这种对等性提高了系统的容错能力和负载均衡效果。
  • 分布式事务：支持分布式事务，保证跨节点的数据一致性，适用于需要高一致性的应用场景。

MySQL

  • 集中式架构：MySQL默认采用集中式架构，数据存储在单个服务器上。尽管可以通过分库分表（Sharding）等方式实现扩展，但这种扩展方式通常需要手动干预，增加了技术复杂性和运维成本。
    • 集中式架构，也叫做单体架构，就是指所有的功能和资源都集中在一个地方处理。
  • 主从复制：MySQL常通过主从复制（Master-Slave Replication）实现读写分离，但主从架构存在单点故障风险，且在主节点故障切换时可能导致短暂的服务中断。
  • 插件式存储引擎：MySQL支持多种存储引擎（如InnoDB、MyISAM），其中InnoDB是最常用的，提供事务支持和外键约束。

QA环节

Q：当我读到这句话时候，“架构：无共享架构，每个节点都可以处理读写请求”。产生小小的疑问，那既然每个节点没用保存所有数据，那么访问的这个节点没有想要的数据怎么操作？

A：

访问过程举例

假设一个读请求到达 Node 1，请求的数据存储在 Partition C 中，而 Partition C 实际上被存储在 Node 3 上。此时 OceanBase 会通过以下过程进行处理：

  1. 路由解析：Node 1 通过查询分区表，确定 Partition C 的主副本或可读副本所在的节点是 Node 3。
  2. 转发请求：Node 1 将这个读请求通过内部网络转发给 Node 3，该节点存储了所需的 Partition C，并可以处理这个请求。
  3. 返回结果：Node 3 处理读请求，将结果返回给 Node 1，再由 Node 1 返回给客户端。

这一过程对应用程序是透明的，用户无需关心数据实际存储在哪个节点，系统会自动完成请求路由和数据访问。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
+-----------------------------------+
|                                   |
|          Client (请求发出)          |
|                                   |
+----------------+------------------+
                 |
                 v
+----------------+------------------+
|        Node 1 (收到请求，但无数据) |
|        通过路由查找目标节点        |
+----------------+------------------+
                 |
                 v
+----------------+------------------+
|        Node 3 (持有数据)           |
|        处理请求并返回结果           |
+----------------+------------------+
                 |
                 v
+----------------+------------------+
|        Node 1 (收到结果并返回给客户端)|
+-----------------------------------+

Q：OceanBase采用无共享（Shared-Nothing）架构，即每个节点都是独立的，拥有自己的SQL引擎、存储引擎和事务引擎。难道mysql其他的节点没有自己的SQL引擎、存储引擎和事务引擎吗

A：

在 MySQL 的主从架构中，节点职责并不对等。主库负责所有的写操作，从库只能用来分担读取工作。在这种架构下，主库是写入的唯一入口，这使得写操作无法水平扩展。

从库的存储引擎、SQL 引擎、事务引擎 是以主库为基础同步的，它们不具有完全独立的写入能力。

可扩展性

OceanBase

  • 分区表与二级分区：OceanBase内部实现了分区表和二级分区功能，能够自动管理数据的分布和负载均衡，完全替代了传统的分库分表方案。
    • 解释：
      • 分区表：像是把订单按年份分类，每个年份的数据存在单独的分区里。这样当你查询某个年份的数据时，只需在对应的年份分区里找，而不是在整个大表中找。
      • 二级分区：在按年份分区的基础上，再根据用户的地区进行进一步细分。这样即便在某一年有很多订单，你也可以根据地区找到更精确的子分区，从而进一步提升查询效率。
  • 在线平滑扩容/缩容：可以在不影响业务运行的情况下，动态增加或减少节点，系统会自动重新分配数据，实现负载均衡，对应用透明。
  • 高扇出设计：通过高扇出（高分支因子）设计，减少了树的高度，提高了查询和插入操作的效率。
    • 扇出（或分支因子）指的是每个节点最多可以包含的子节点数。

MySQL

  • 分库分表扩展：MySQL的扩展性主要依赖于分库分表方案。这需要开发人员手动设计和实施分片逻辑，增加了系统复杂性和维护成本。
  • 水平扩展受限：由于MySQL的集中式架构，水平扩展（Scale-Out）较为困难，通常需要借助第三方中间件（如ProxySQL、Vitess）来实现，这进一步增加了系统复杂性。
  • 复制延迟：在主从复制架构下，主节点与从节点之间可能存在复制延迟，导致数据一致性问题，影响实时性要求高的应用。

性能

OceanBase

  • 读写分离架构：OceanBase采用读写分离，将读请求和写请求分离，提高了系统的并发处理能力。
  • 数据存储优化：
    • 基线数据与增量数据分离：将基线数据存储在SSD盘（SSTable），增量数据存储在内存中（MemTable），通过内存中的增量数据实现高效的DML操作。
    • LSM树存储引擎：采用Log-Structured Merge-Tree（LSM树）存储引擎，通过批量存储技术减少磁盘随机写入操作，大幅提升写性能。
  • 高并发处理：能够处理大规模的并发读写请求，适用于高流量、大数据量的应用场景。

MySQL

  • B树存储引擎：MySQL主要使用B树（B-Tree）作为索引结构，虽然B树在读操作中表现良好，但在高并发写操作时，由于需要频繁的索引和数据插入，会导致性能瓶颈。
  • 缓存机制：通过缓冲池（Buffer Pool）等缓存机制提升读性能，但在处理大量并发写操作时，性能提升有限。
  • 单节点性能限制：由于默认架构是集中式，单节点的CPU、内存和磁盘I/O资源限制了其整体性能，难以满足超高并发和大数据量的需求。

高可用性

OceanBase：

  • 无共享的多副本架构：OceanBase 采用无共享的多副本架构，所有节点都有自己的副本，没有单点故障问题。通过多副本机制，OceanBase 能够在某个节点发生故障时，自动从其他副本中恢复数据，确保服务的持续可用性。
  • 城市级容灾：OceanBase 支持“三地五中心”这样的城市级容灾部署，可以在不同城市的机房中同时部署多个数据中心，实现跨城市的容灾。其容灾能力非常强，能够做到 RPO=0（无数据丢失）和 RTO<30秒（恢复时间小于 30 秒），这使得 OceanBase 非常适合金融等高要求的场景。

MySQL：

  • 主从复制：MySQL 主要通过主从复制实现高可用性。主库负责处理读写请求，从库负责读请求和备份。如果主库出现故障，可以手动或自动切换到从库，恢复业务的可用性。
  • 恢复时间较长：MySQL 的故障切换通常需要一定的恢复时间，尤其是当复制延迟较大或从库没有同步最新数据时，恢复过程可能较为复杂。此外，MySQL 的高可用方案需要额外的集群管理工具（如 MHA、PXC），并且运维复杂度较高。

应用场景

一致性和可用性的话优先选择ob

OceanBase：

  • 金融行业：OceanBase 主要应用于金融行业，支持超高并发、强一致性和高可用性，是金融级应用的理想选择。它能够在高频交易、支付结算、银行核心系统等对数据一致性和可用性要求极高的场景中提供强大支持。
  • 大数据量、高并发业务：OceanBase 的分区和二级分区功能，结合其高性能的存储引擎和分布式架构，使得它在需要处理海量数据和高并发的互联网、电商、政府等行业中表现出色。

MySQL：

  • Web 应用：MySQL 作为经典的关系型数据库，广泛应用于中小型 Web 应用场景，比如博客系统、电商网站、企业管理系统等。MySQL 的集中式架构在数据量不大的情况下，性能足够应对日常业务需求。
  • 中小型企业系统：MySQL 在中小型企业系统中有广泛的应用，适用于数据量相对较小、并发量有限的业务场景，并且开发、部署和管理相对简单。

OceanBase与MySQL有何区别？