分布式数据库选型介绍

发表于 更新于 阅读次数： 评论数： 本文字数： 8.2k 阅读时长 ≈ 7 分钟

前言

容易混淆的数据库分片概念

  • 传统数据库的分片（分库分表）
    • 应用层或中间件负责，属于逻辑分片
    • 典型代表：
      • MyCat
      • ShardingSphere
    • 特点：
      • 用户要自己定义路由规则
      • SQL 有限制
      • 跨分片 Join / 事务复杂
  • 原生分布式数据库的分片
    • 数据库内核自动完成分片，属于物理分片（透明分片）
    • 对用户：
      • 看起来像一张普通表
    • 实际上：
      • 数据自动拆分
      • 自动副本
      • 自动迁移

OldSQL、NewSQL、NoSQL

  • OldSQL：

    • 单机时代的关系数据库王者，强一致事务，但难以扩展
    • 典型产品：MySQL、PostgreSQL、Oracle、OpenGauss

  • NewSQL：

    • 在分布式时代，重新把 SQL 与 ACID 事务带回来
    • 典型产品：TiDB、OceanBase、CockroachDB

  • NoSQL：

    • 为扩展而生，牺牲关系模型与强一致事务，追求极致性能
    • 典型产品：MongoDB、HBase、Cassandra、InfluxDB、Elasticsearch
能力 OldSQLNewSQLNoSQL
关系模型支持✅✅❌
SQL 完整支持✅✅❌
ACID 事务支持✅✅❌
水平扩展支持❌✅✅
分布式支持❌✅✅

OldSQL 的概念

OldSQL 通常指传统的单机或以主从为主的关系型数据库（比如 MySQL、PostgreSQL 等），是关系数据库理论最完整、最成熟的一类。简而言之，OldSQL 是指传统的关系型数据库。

  • 核心特征：

    • 单机性能强
    • 采用严格的关系模型（表、行、列）
    • 支持完整 SQL 语义
    • 支持强 ACID 事务
    • 拥有成熟的优化器与索引体系

  • 架构特点：

    • 以单机架构为核心
    • 高可用实现方式：
      • 主从复制
      • 读写分离
    • 扩展方式主要是：
      • 纵向扩展（Scale Up）
      • 或业务层分库分表

  • 代表产品：

    • MySQL
    • PostgreSQL
    • Oracle
    • SQL Server

  • 适用场景：

    • 中小规模业务系统
    • 单机可承载的 OLTP 系统
    • 对事务一致性要求极高、但数据规模可控的场景

  • 使用局限性：

    • OldSQL 在单机能力上非常强，但天然不擅长水平扩展（横向扩展）
    • 一旦数据与并发规模上来，往往需要引入复杂的分库分表方案

NewSQL 的概念

NewSQL 是对 OldSQL 与 NoSQL 的一次 “融合式进化”，在不牺牲关系模型、SQL 完整、强一致事务的前提下，用分布式架构解决传统数据库的扩展性问题。简而言之，NewSQL 是原生分布式关系型数据库。

  • 核心特征：

    • 采用关系模型（表、行、列）
    • 支持完整 SQL
    • 支持强一致事务
    • 支持原生分布式架构
    • 支持自动分片
    • 支持在线扩缩容
    • 支持高可用、多副本

  • 架构特点：

    • 计算与存储解耦（常见）
    • 底层多为分布式 KV
    • 采用共识协议（Raft / Paxos）
    • 支持全局事务协调（2PC + TSO）

  • 代表产品

    • TiDB
    • OceanBase
    • CockroachDB
    • Google Spanner

  • 适用场景

    • 大规模 OLTP 系统
    • 金融、订单、交易系统
    • 希望 “像用单机数据库一样使用分布式数据库” 的业务

NoSQL 的概念

NoSQL 并不是 “不需要 SQL”，而是不再坚持关系模型与强一致事务，以换取极致的扩展性和性能。简而言之，NoSQL 是指非关系型数据库。

  • 核心特征：

    • 多采用最终一致性
    • 通常不支持复杂 Join
    • Schema 弱或无 Schema
    • 采用非关系模型（NoSQL），存储类型包括：
      • 键值（Key-Value）
        • Redis
        • Memcached
      • 文档（Document）
        • MongoDB
        • CouchDB
      • 列族 / 宽列（Column-Family / Wide-Column）
        • HBase
        • Cassandra
      • 时序（Time-Series）
        • InfluxDB
        • Prometheus TSDB
      • 图（Graph）
        • Neo4j
        • JanusGraph
      • 对象（Object）
        • Ceph
      • 搜索 / 倒排索引（Search / Inverted Index）
        • Elasticsearch
        • OpenSearch

  • 架构特点：

    • 天生分布式
    • 水平扩展简单
    • 高吞吐、高并发
    • 数据模型贴近存储

  • 适用场景：

    • 缓存系统
    • 会话存储
    • 日志、时序数据
    • 海量数据写入、简单查询场景

  • 使用局限性：

    • 弱事务 / 最终一致性
    • SQL 支持不完整
    • Join 基本不可用

开源关系型数据库（OldSQL）

OpenGauss

OpenGauss 是一款 以 PostgreSQL 为基础开发的传统关系型数据库（基于 C++ 开发），属于 OldSQL；由华为主导开源，主要定位于单机 / 主备高可用场景。特别注意的是：OpenGauss 本身并非原生分布式关系型数据库，其分布式能力依赖特定形态，必须加以区分。

发展历史

  • 2019 年
    • 华为在 PostgreSQL 基础上启动 OpenGauss 项目
  • 2020 年
    • OpenGauss 正式开源
  • 2021 年
    • OpenGauss 社区独立运作
  • 2022 ~ 至今
    • 在政企、国产化数据库替代场景中广泛应用
    • 重点发展方向仍以 “单机性能 + 高可用” 为主

形态划分

OpenGauss 必须区分两种形态，否则很容易产生误解。

  • OpenGauss 单机 / 主备形态
    • 这是 OpenGauss 的主流、官方推荐使用形态
    • 架构特征：
      • 单机数据库
      • 支持主备复制
      • 支持读写分离（有限支持）
    • 能力特点：
      • 标准关系模型
      • 完整 SQL
      • 强 ACID 事务
      • 不支持自动分片
      • 不支持原生水平扩展
    • 本质上：OpenGauss（单机版）≈ PostgreSQL + 企业级增强
  • OpenGauss 分布式组合形态
    • OpenGauss 可以通过 “外部组件” 实现分布式能力
    • 常见组合方式：
      • OpenGauss + ShardingSphere
      • OpenGauss + DCF（分布式一致性框架）
    • 分片方式：
      • 逻辑分片
      • 显式路由规则
      • 由中间层或协调层完成
    • 特点总结：
      • 业务需要理解分片规则
      • SQL 能力受限于中间件
      • 跨分片事务复杂
    • 本质上更接近：” 分库分表中间件 + SQL 引擎” 方案
    • OpenGauss 与 OceanBase / TiDB 的关键区别在于：分片不是数据库内核能力，而是外置实现

设计理念

  • 核心设计理念（单机 / 主备形态）：

    • 强调：
      • 单机性能
      • 企业级稳定性
      • 国产化替代
    • 数据模型：
      1
      SELECT * FROM order WHERE order_id = 1;
      • 查询的是一张物理表
      • 不涉及自动分片或跨节点路由

  • 核心设计理念（分布式组合形态）：

    • 分布式能力并非对业务透明
    • 由外部组件实现分布式能力：
      • ShardingSphere
      • 或其他中间件
    • 分片规则：
      • 显式分片
      • 显式路由
      • 显式架构设计
    • OpenGauss 的分布式能力主要依赖外部组合方案，并非数据库内核原生实现，这与 OceanBase / TiDB 原生分布式关系型数据库有本质区别
    • 从架构理念上看，OpenGauss 更接近 MySQL + ShardingSphere 这类 “分库分表中间件 + SQL 引擎” 模式，与 OceanBase / TiDB 的原生分布式 NewSQL 并不在同一技术层级

核心特性

  • 核心特性（以单机形态为主）：

    • 架构层面
      • 单机 / 主备架构
      • 非原生分布式
    • 数据与事务
      • 强一致事务
      • 行级锁 + MVCC
    • SQL 与兼容性
      • PostgreSQL 语法体系
      • 丰富的企业级 SQL 特性
    • 运维能力
      • 主备切换
      • 高可用部署
      • 运维模型成熟
    • 分布式能力（组合式方案）：
      • 依赖外部组件
      • 非数据库内核原生能力
      • 复杂度与侵入性较高

  • 事务能力

    • 单机 / 主备形态：

      • 标准 ACID 事务
      • 本地事务
      • 成熟稳定

    • 分布式组合形态：

      • 跨分片事务依赖中间件

      • 一致性与性能受限于：

        • 路由策略
        • 两阶段提交
        • 中间件实现

    • 对比说明：OpenGauss 的事务优势在单机强一致性，而非分布式事务能力

  • 对比「原生分布式数据库」

    对比项 OpenGauss（单机 / 组合式）OceanBase
    分布式形态外置 / 组合原生内核实现
    分片规则显式定义系统自动
    SQL 能力完整 SQL / 有限制（受中间件影响）完整 SQL
    分布式事务依赖中间件原生支持
    业务侵入中 / 高低

适用场景

  • 非常适合：

    • 国产化数据库替代
    • 政企系统
    • 单机或中等规模 OLTP 系统
    • 对 PostgreSQL 生态依赖较强的系统

  • 不太适合：

    • 超大规模水平扩展系统
    • 希望 “完全不感知分布式” 的业务
    • 金融级分布式核心账务系统

开源生态

  • GitHub 开源项目：

  • 开源社区生态：

    • OpenGauss 社区版（免费）
    • 政企国产化生态完善

开源分布式数据库（NewSQL）

TiDB

TiDB 是一款分布式关系型数据库（基于 Go、Rust 开发），属于 NewSQL，兼容 MySQL 协议，支持水平扩展与强一致分布式事务。对外提供完整 SQL 和事务能力，对内采用分布式 KV 架构实现水平扩展。它对分片整体透明，但明确暴露 Region（分片）这一核心概念，是目前分片模型最清晰的分布式数据库之一。

发展历史

  • 2015 年
    • PingCAP 团队启动 TiDB 项目
  • 2016 年
    • TiDB 正式开源
  • 2018 年
    • 在国内互联网公司开始规模化落地
  • 2020 年
    • 金融、运营商、政企开始使用 TiDB
  • 2022 ~ 至今
    • 成为国内最活跃的开源 NewSQL 数据库之一
    • 社区活跃度与生态成熟度持续提升

设计理念

  • 核心设计理念：

    • 对业务层面基本透明，但分片概念清晰可感知
    • 业务看到的是逻辑表：
      1
      SELECT * FROM order WHERE order_id = 1;
    • 实际底层：
      • 表数据被拆分为多个 Region
      • Region 分布在不同 TiKV 节点
      • 多副本存储
      • 由调度系统自动均衡

  • 核心数据模型：

    • Region（分片）：
      • TiDB 的最小数据分片单位
      • Region 的默认大小：
        • 约 96MB（可动态调整）
      • Region 的职责：
        • 数据分布的基本单位
        • 副本复制与调度的基本单位
      • Region 自动管理机制：
        • Region Split
          • 数据增长后自动拆分
        • Region Merge
          • 数据减少后自动合并
        • 自动调度到不同节点（TiKV）
      • 用户可感知但不强制参与分片：
        • 用户默认可以完全不关心 Region
        • 也可以：
          • 通过 SQL Hint
          • 通过表结构设计
          • 间接影响 Region 分布

  • 核心架构组成

    • TiDB Server
      • SQL 解析与优化
      • 无状态，可水平扩展
    • TiKV
      • 分布式 KV 存储
      • 承载 Region 数据
    • PD（Placement Driver）
      • 元数据管理
      • Region 调度
      • 副本管理
      • 负载均衡
    • TiDB 是典型的计算与存储分离架构

核心特性

  • 核心特性：

    • 架构层面
      • 原生分布式
      • 计算与存储分离
      • Shared-Nothing 架构
      • 高可用、多副本
    • 数据与事务
      • 基于 Region 的自动分片
      • 支持强一致分布式事务
      • 支持 MVCC + 行级锁
    • SQL 与兼容性
      • MySQL 协议兼容
      • 大部分 MySQL 语法与生态可用
    • 调度与运维
      • 自动 Region 调度
      • 在线扩缩容
      • 自动副本补齐与迁移

  • 事务特性：

    • 支持分布式事务
      • 跨 Region 事务
      • 跨 Region Join
      • 默认提供快照隔离（SI）
      • 在特定配置下支持更强一致级别
    • 实现方式（简化理解）：
      • Percolator 事务模型
      • 两阶段提交（2PC）
      • PD 提供全局时间戳（TSO）
      • Raft 协议保证副本一致性
    • 对比说明：
      • TiDB 的事务模型在一致性与性能之间做了工程化平衡，更适用于互联网高并发 OLTP 场景

  • 对比「分库分表 + 中间件」

    对比项 TiDB 分库分表 + 中间件（如 MyCat、ShardingSphere）
    分片模型 Region（系统自动）业务自定义分片规则
    分片可见性可感知但非强制强制感知
    SQL 能力高（接近 MySQL）有限制
    事务分布式事务跨库事务复杂
    扩缩容在线风险高
    业务侵入低高

适用场景

  • 非常适合：

    • 互联网 OLTP 系统
    • 订单 / 用户 / 业务系统
    • 对 MySQL 生态依赖较重的系统
    • 需要水平扩展、但可接受一定分布式语义的场景

  • 不一定适合：

    • 极端金融强一致核心业务
    • 希望完全 “忘记分布式” 的业务
    • 对单条事务延迟极其敏感的场景

开源生态

  • GitHub 开源项目：

  • 开源生态组件：

    • TiDB
    • TiKV
    • PD
    • TiCDC
    • TiFlash（HTAP）

OceanBase

OceanBase 是一款原生分布式、强一致、高可用的关系型数据库（基于 C++ 开发），属于 NewSQL，兼容 MySQL 和 Oracle 协议。对用户隐藏分片细节，提供与单机数据库几乎一致的使用体验。

发展历史

  • 2010 年左右
    • 蚂蚁金服内部启动 OceanBase 项目
  • 2014 年
    • 支撑支付宝核心交易系统
  • 2019 年
    • 蚂蚁宣布 OceanBase 对外商业化
  • 2021 年
    • 正式开源 OceanBase 社区版
  • 2023 ~ 至今
    • 广泛应用于金融、政企、运营商、大型互联网
    • 少有的：先在金融核心系统跑十几年，再开源的数据库

设计理念

  • 核心设计理念：

    • 对业务完全透明，业务看到的是一张逻辑表
      1
      SELECT * FROM order WHERE order_id = 1;
    • 实际底层：
      • 数据已被自动拆分
      • 分布在多个节点
      • 有多个副本
      • 自动迁移与负载均衡
    • 但这些对业务完全不可见，这与很多「分库分表 + 中间件」方案（如 MyCat、ShardingSphere）有本质区别

  • 核心数据模型：

    • Tablet / Partition（自动分片）：
      • OceanBase 会将表数据 自动拆分成多个 Tablet（分区）
      • Tablet 是：
        • 数据调度的最小单元
        • 副本复制、迁移、均衡的基本单位
      • Tablet 不是业务定义的分片规则，而是系统自动完成
    • 多副本 + Paxos：
      • 每个 Tablet 默认有 3 个副本
      • 基于 Paxos / Multi-Paxos 协议：
        • 强一致性
        • 线性一致读写
        • 自动 Leader 选举、自动故障切换

核心特性

  • 核心特性：

    • 架构层面
      • 原生分布式（非单机改造）
      • Shared-Nothing 架构
      • 多副本、高可用、自愈
    • 数据与事务
      • 自动分区（Tablet）
      • 强一致分布式事务
      • 行级锁 + MVCC
    • SQL 与兼容性
      • 高度兼容 MySQL
      • 高度兼容 Oracle
      • 大量企业级 SQL 特性
    • 运维能力
      • 在线扩缩容（水平扩展）
      • 自动负载均衡
      • 自动副本修复
      • 支持超大规模集群

  • 事务能力：

    • 真正的强一致分布式事务，这是 OceanBase 最大的技术护城河之一。
    • 事务特性：
      • 全局 ACID 事务
      • 跨节点、跨分区事务
      • 单 SQL、跨 SQL 都支持
    • 实现方式（简化理解）：
      • 全局时间戳服务（TSO）
      • 两阶段提交（2PC）
      • Paxos 保证日志一致性
    • 对比很多 NewSQL / 分布式数据库：
      • OceanBase 的事务能力更接近「分布式 Oracle」

  • 对比 「分库分表 + 中间件」

    对比项 OceanBase 分库分表 + 中间件（如 MyCat、ShardingSphere）
    分片规则系统自动业务自己设计
    SQL 能力完整 SQL 有限制
    事务强一致分布式事务跨库事务实现复杂
    运维复杂度低高
    扩缩容在线透明高风险
    业务侵入无很重

适用场景

  • 非常适合

    • 金融核心系统
    • 订单 / 账务 / 交易系统
    • 超大规模 OLTP
    • 需要强一致 + 高可用的系统

  • 不一定适合

    • 极端简单的小系统
    • 只做 KV 存储
    • 强依赖 NoSQL 特性的场景

开源生态

  • GitHub 开源项目:

  • 开源生态组件：

    • OceanBase CE（社区版，免费）
    • OCP 运维平台（社区版，免费）
    • OBProxy（官方专用的代理服务器）
    • 兼容 MySQL / Oracle 的工具链
    • 更多组件详见 官方文档 - OceanBase 生态工具介绍

CockroachDB

CockroachDB 是一款原生分布式、强一致、高可用的关系型数据库（基于 Go 开发），属于 NewSQL，兼容 PostgreSQL 协议。对用户隐藏分片与副本细节，提供接近单机 PostgreSQL 的使用体验，目标是 “实现像单机数据库一样使用的全球一致分布式数据库”。

提示

OceanBase 更像 "分布式的 MySQL / Oracle"，而 CockroachDB 更像 "开源版的 Spanner（Google） + PostgreSQL 体验"。

发展历史

  • 2014 年
    • 前 Google 工程师在美国创立 Cockroach Labs
    • 设计目标：借鉴 Spanner / Bigtable 思想，构建开源的全球一致数据库
  • 2015 年
    • CockroachDB 项目在 GitHub 开源
  • 2017 ~ 2018 年
    • 分布式事务、Raft、多副本架构逐步成熟
    • 社区与企业用户快速增长
  • 2019 年
    • 许可证由 Apache 2.0 调整为 BSL（Business Source License）
  • 2021 ~ 至今
    • 广泛应用于金融科技、SaaS、多活系统
    • 典型用户包括 Stripe、DoorDash、Bose 等

设计理念

  • 核心设计理念：

    • 对业务隐藏分布式复杂性，业务看到的是一张逻辑表
      1
      SELECT * FROM orders WHERE order_id = 1;
    • 实际底层：
      • 数据自动切分
      • 分布在多个节点
      • 多副本强一致
      • 自动迁移与负载均衡
    • 应用层无需关心分片规则、路由逻辑

  • 核心数据模型：

    • Range（自动分片）：
      • 表数据会被自动切分成多个 Range
      • Range 是：
        • 数据复制的最小单位
        • 调度、迁移、负载均衡的基本单位
      • Range 由系统自动拆分 / 合并，非业务定义
    • 多副本 + Raft：
      • 每个 Range 默认 3 个副本（可配置）
      • 基于 Raft 协议：
        • 强一致性
        • 线性一致读写
        • 自动 Leader 选举与故障切换

核心特性

  • 核心特性：

    • 架构层面
      • 原生分布式
      • Shared-Nothing 架构
      • 多副本、高可用、自愈
    • 数据与事务
      • 自动分片（Range）
      • 强一致分布式事务
      • MVCC + 行级锁
    • SQL 与兼容性
      • PostgreSQL 协议兼容
      • 兼容大部分常用 PostgreSQL SQL 特性
    • 运维能力
      • 在线扩缩容
      • 自动副本均衡
      • 节点自动加入 / 移除
      • 原生支持跨地域部署

  • 事务能力：

    • CockroachDB 以 “全球强一致分布式事务” 作为核心亮点
    • 事务特性：
      • 全局 ACID 事务
      • 跨节点、跨 Range 事务
      • 单 SQL、跨 SQL 事务
    • 实现方式（简化理解）：
      • HLC（Hybrid Logical Clock）
      • 两阶段提交（2PC）
      • Raft 日志保证一致性
    • 特点：
      • 不依赖外部全局时钟（如 Google Spanner 的 TrueTime）
      • 在普通云环境即可实现强一致分布式事务

  • 对比 「分库分表 + 中间件」：

    对比项 CockroachDB 分库分表 + 中间件（如 MyCat、ShardingSphere）
    分片规则系统自动业务自己设计
    SQL 能力接近完整 SQL 有限制
    事务强一致分布式事务跨库事务复杂
    运维复杂度低高
    扩缩容在线透明高风险
    业务侵入无很重

商业限制

  • CockroachDB 属于代码开源 / 商业使用有限制的原生分布式数据库
    • CockroachDB 采用 BSL（Business Source License）授权
      • BSL 并不禁止商业使用，它主要禁止的是：将 CockroachDB 本身作为一个对外收费的数据库服务（DBaaS）提供给用户
    • BSL 的授权特点：
      • 源码可见、可学习、可修改
      • 生产环境商业使用有约束
      • 若干年后转为 Apache 2.0 开源协议
      • 这和 Apache / MIT 那种 “完全自由开源” 不一样
    • 商业使用举例：
      • 公司内部的项目使用 CockroachDB 开发一款收费的聊天 APP，一般不需要购买商业许可证
      • 这是因为聊天 APP 属于业务应用（Application），而 CockroachDB 是内部基础设施组件，这是 BSL 明确允许的使用方式
        • 公司部署 CockroachDB 集群
        • CockroachDB 只是聊天 APP 的底层数据库
        • 对外收费的是聊天 APP 本身，而不是 “数据库服务”
        • 不向第三方单独提供 “CockroachDB 托管数据库服务（DBaaS）”
          行为是否需要购买商业许可证
          用 CockroachDB 开发聊天 APP 并收费❌ 不需要
          SaaS 产品内部使用 CockroachDB❌ 不需要
          企业内部系统使用 CockroachDB❌ 不需要
          将 CockroachDB 做成 “托管数据库服务” 对外销售✅ 需要
          类似 AWS RDS / 云数据库 CockroachDB✅ 需要

适用场景

  • 非常适合：

    • 金融级事务系统
    • 多活 / 跨地域部署
    • SaaS 核心数据库
    • 强一致 OLTP 场景
    • 希望减少分库分表复杂度的系统

  • 不一定适合：

    • 单机即可满足的小规模系统
    • 极端写放大、低延迟 KV 存储场景
    • 对 PostgreSQL 特性高度依赖（如部分扩展）

开源生态

  • GitHub 开源项目:

  • 开源生态组件：

    • CockroachDB Core
      • 核心数据库源码（源码可见，BSL 许可，旧版本会转为 Apache 2.0）
      • 支持分布式 SQL、强一致性（Raft）、自动分片与负载均衡
    • CockroachDB Community / Free 功能集（免费）
      • 基础 SQL 能力、事务、自动容错
      • 可用于自建集群与内部商业使用
    • CockroachDB Enterprise Features（需商业许可证）
      • 备份 / 恢复（增量、加密）
      • 多区域部署（Multi-Region）、Follower Reads
      • 行级 / 列级访问控制、审计日志等
    • CockroachDB Cloud（官方托管服务）
      • Cockroach Labs 提供的 DBaaS（闭源）
    • 生态与工具链
      • SQL 客户端（cockroach sql）
      • 监控与可观测性（Prometheus / Grafana 集成）
      • Kubernetes 部署（Helm Charts、Operator）
      • PostgreSQL 协议兼容（客户端与驱动）

商业分布式数据库（NewSQL）

Google Spanner

Google Spanner 是一款闭源的、云原生的分布式关系型数据库服务（属于 NewSQL），它是 NewSQL 架构思想的重要奠基者。

  • Google Spanner 是：

    • Google 内部数据库
    • GCP 托管服务

  • 用户只能：

    • 使用 Google Spanner 的云服务
    • 不能部署、不能阅读 Google Spanner 的源码

参考资料