Q:**什么是 OceanBase 数据库?**
A:OceanBase 数据库是阿里巴巴和蚂蚁金服不基于任何开源产品,完全自研的原生分布式关系数据库软件,在普通硬件上实现金融级高可用,首创“三地五中心”城市级故障自动无损容灾新标准,具备卓越的水平扩展能力,全球首家通过 TPC-C 标准测试的分布式数据库,单集群规模超过 1500 节点。 产品具有云原生、强一致性、高度兼容 Oracle/MySQL 等特性, 承担支付宝 100% 核心链路,在国内几十家银行、保险公司等金融客户的核心系统中稳定运行。
Q**:OceanBase 数据库有哪些优势?**
A:OceanBase 数据库拥有以下核心优势:
分布式事务引擎
OceanBase 数据库的分布式事务引擎严格支持事务的 ACID 属性,并且在整个集群内严格支持数据强一致性,是全球唯一一家通过了标准 TPC-C 测试的原生分布式关系型数据库产品。
OceanBase 数据库通过 Paxos 协议将事务日志复制到多个数据副本来保证事务的可用性和持久性。
透明可扩展
OceanBase 数据库独创的总控服务和分区级负载均衡能力使系统具有极强的可扩展性,可以在线进行平滑扩容/缩容,并且在扩容后自动实现系统负载均衡,对应用透明,确保系统的持续运行。
此外,OceanBase 数据库支持超大规模集群(节点超过 1500 台,最大单集群数据量超过 3PB,单表数量达到万亿行级别)动态扩展,在 TPC-C 场景中,系统扩展比可以达到 1:0.9,使用户投资的硬件成本被最大化的利用。
极致高可用
OceanBase 数据库采用基于无共享(Shared-Nothing)的多副本架构,让整个系统没有任何单点故障,保证系统的持续可用。支持单机、机房、城市级别的高可用和容灾,可以进行单机房、双机房、两地三中心、三地五中心部署。经过实际测试,可以做到城市级故障 RPO=0,RTO<30 秒,达到国标灾难恢复能力最高级别 6 级。并且提供类似于传统数据库主备模式,基于事务日志复制的容灾特性。
混合事务和分析处理**(Hybrid Transaction and Analytical Process,HTAP)**
OceanBase 数据库独创的分布式计算引擎,能够让系统中多个计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用,让数据库利用率最大化的同时利用多个节点的计算能力,完成对 OLTP 和 OLAP 应用的支持。
OceanBase 数据库真正实现了用一套计算引擎同时支持混合负载的能力,让用户通过一套系统解决 80% 的问题。相对于国内很多分布式数据库采用的通过两种不同的计算引擎,甚至两套数据库系统去分别支持 OLTP 和 OLAP 的方式具有巨大优势。
云原生
OceanBase 数据库采用了单集群多租户设计,天然支持云数据库架构,支持公有云、私有云、混合云等多种部署形式。
OceanBase 是数据库通过租户实现资源隔离,让每个数据库服务的实例不感知其他实例的存在,并通过权限控制确保不同租户数据的安全性,配合 OceanBase 数据库强大的可扩展性,能够提供安全、灵活的 DBaaS 服务。
高兼容性
OceanBase 数据库针对 Oracle、MySQL 这两种应用最为广泛的数据库生态都给予了很好的支持。
对于 MySQL 数据库,OceanBase 数据库支持 MySQL 5.6 版本全部语法,可以做到 MySQL 业务无缝切换。
对于 Oracle 数据库,OceanBase 能够支持 95% 以上的 Oracle 语法和过程性语言功能,可以做到大部分的 Oracle 业务进行少量修改后自动迁移。在多家金融行业客户和阿里巴巴内部已有多次迁移至 OceanBase 数据库的成功案例。
完整自主知识产权
OceanBase 数据库由蚂蚁金服完全自主研发,不基于 MySQL 或者 PostgreSQL 等开源数据库,能够做到完全自主可控,不会存在基于开源数据库产品的技术限制问题。
高性能
OceanBase 数据库作为准内存数据库,通常只需要操作内存中的数据,并且采用了独创的基于 LSM-Tree 结构的存储引擎,对于硬件更加友好,读写性能均远超传统关系型数据库。
安全性
OceanBase 数据库在调研了大量企业对于数据库软件的安全需求,并参考了各种安全标准之后,实现了企业需要的绝大部分安全功能,支持完备的权限与角色体系,支持 SSL、数据透明加密、审计、Label security、IP 白名单等功能,并通过了等保三标准测试。
国产化适配
随着国产化硬件和操作系统的不断发展,OceanBase 数据库已完成了与海光、海思(鲲鹏920)、飞腾硬件平台的适配,并且支持中标麒麟、银河麒麟国产操作系统。
Q:**OceanBase 有哪些产品?**
A:OceanBase 除了提供 100% 自主研发的企业级分布式关系数据库之外,还提供了丰富的数据库管理和开发产品,辅助用户更好的使用 OceanBase 数据库。
OceanBase 数据库
完全自研的原生分布式关系数据库软件,在普通硬件上实现金融级高可用,首创“三地五中心”城市级故障自动无损容灾新标准,具备卓越的水平扩展能力,全球首家通过 TPC-C 标准测试的分布式数据库,单集群规模超过 1500 节点。
OceanBase 云平台
以 OceanBase 为核心的企业级数据库管理平台,提供专业的 OceanBase 集群、租户、数据库等相关组件的全生命周期管理,同时也可以对 OceanBase 相关的其他组件提供管理功能。
OceanBase 开发者中心
为 OceanBase 数据库量身打造的企业级数据库开发平台。ODC 支持连接 OceanBase 中 MySQL 和 Oracle 模式下的数据库,同时为数据库开发者提供了数据库日常开发操作、WebSQL、SQL 诊断、会话管理和数据导入导出等功能。
OceanBase 迁移服务
OceanBase 提供的一种支持同构或异构 RDBMS 与 OceanBase 之间进行数据交互的服务,它提供了数据的在线迁移和实时增量同步的数据复制能力。
有关产品的更多详细介绍,参见 OceanBase 产品体系。
Q:安装 OceanBase 服务器对系统有什么要求吗?
A:服务器应满足的最低配置要求如下表所示。
服务器类型 | 数量 | 功能最低配置 | 性能最低配置 |
---|---|---|---|
OCP 管控服务器 | 1台 | 32C,128G,1.5TB 存储 | 32C,128G,1.5TB SSD 存储,万兆网卡 |
OceanBase 计算服务器 | 3台 | 32C,128G,1.2TB 存储 | 32C,256G,2TB SSD 存储,万兆网卡 |
如果需要 OCP 管控服务提供高可用能力,则需要 3 台管控服务器,并提供负载均衡软件或者硬件,例如 F5、阿里云 SLB,或者使用 OceanBase 提供的 ob_dns 软负载组件,进行三节点部署。
支持在下表所示的 Linux 操作系统中安装 OceanBase 数据库。
Linux操作系统 | 版本 | 服务器架构 |
---|---|---|
AliOS | 7.2 及以上 | x86_64(包括海光),ARM_64(仅支持鲲鹏、飞腾) |
CentOS / Red Hat Enterprise Linux | 7.2 及以上 | x86_64(包括海光),ARM_64(仅支持鲲鹏、飞腾) |
SUSE Enterprise Linux | 12SP3 及以上 | x86_64(包括海光),ARM_64(仅支持鲲鹏、飞腾) |
Debian / Ubuntu | 8.3 及以上 | x86_64(包括海光),ARM_64(仅支持鲲鹏、飞腾) |
Q:**OceanBase 数据库的存储引擎和传统数据库有什么不一样的地方?**
A:OceanBase 数据库采用了一种读写分离的架构,把数据分为基线数据和增量数据。其中增量数据放在内存里(MemTable),基线数据放在 SSD 盘(SSTable)。对数据的修改都是增量数据,只写内存。所以 DML 是完全的内存操作,性能非常高。读的时候,数据可能会在内存里有更新过的版本,在持久化存储里有基线版本,需要把两个版本进行合并,获得一个最新版本。同时在内存实现了 Block Cache 和 Row Cache,来避免对基线数据的随机读。当内存的增量数据达到一定规模的时候,会触发增量数据和基线数据的合并,把增量数据落盘。同时每天晚上的空闲时刻,系统也会自动每日合并。
Q:**数据在 OceanBase 数据库中是如何存储的?**
A:OceanBase 数据库的数据文件以宏块(Macro Block)为单位组织数据,每个宏块大小为 2MB。宏块内部又划分出很多个16K(压缩前的大小)大小的微块(Micro Block),而每个微块里面包含多个行(Row)。OceanBase 数据库内部 IO 的最小单位是微块。
Q:**OceanBase 数据库是如何做到比传统数据库更省空间的?**
A:OceanBase 数据库通过数据编码压缩技术实现高压缩。数据编码是基于数据库关系表中不同字段的值域和类型信息,所产生的一系列的编码方式,它比通用的压缩算法更懂数据,从而能够实现更高的压缩效率。
Q:用户如何使用 OceanBase 数据库?
A:和传统数据库一样,OceanBase 数据库提供了 SQL 接口,用户可以通过 SQL 语言访问、操作数据库。
Q:从前运行在 MySQL 上的业务,迁移到 OceanBase 数据库上的成本如何?
A:OceanBase 数据库兼容常用 MySQL 功能及 MySQL 前后台协议,业务零修改或少量修改即可从 MySQL 迁移至 OceanBase 数据库。
Q:OceanBase 数据库作为一款分布式数据库,在编写 SQL 语句上和传统数据库有什么不一样的地方?
A:首先,OceanBase 数据库兼容常用 MySQL 功能,所以您可以和使用传统数据库一样通过 SQL 对 OceanBase 数据库进行访问。同时,OceanBase 数据库作为一款分布式数据库,无论是查询优化引擎还是 SQL 执行引擎都和传统数据库有很大的区别,为了让您写出尽可能高效的 SQL 语句,我们提供了《OceanBase 数据库 SQL 调优指南》供您参考。
Q:Ocea**nBase 数据库是如何实现高可**用的?
A:不同于传统数据库的主备或一主多从方案,OceanBase 数据库同样使用性价比较高、可靠性略低的服务器,但同一数据保存了多台(>=3)台服务器中的半数以上服务器上(例如 3 台中的 2 台,5 台中的 3 台等),每一笔写事务也必须到达半数以上服务器才生效,因此当少数服务器故障时不会有任何数据丢失。不仅如此,传统数据库主备镜像在主库发生故障时,通常需要外部工具或人工把备库升级成主库,而 OceanBase 数据库底层实现了 Paxos 高可用协议,在主库故障后,剩余的服务器会很快自动选举出新的主库,并继续提供服务。在多次蚂蚁机房断网演练中,OceanBase 数据库都做到了自动切换且完全不丢数据,证明了 OceanBase 数据库高可用架构的技术优越性。
Q:在生产环境中,OceanBase 数据库会如何部署?
A:
方案名称 | 方案特点 | 基础设施要求 | 适用场景 |
---|---|---|---|
单机房 3 副本 | RPO=0,RTO 低,故障自动切换。 可抵御个别硬件故障,无法抵御机房级灾难或者城市级灾难。 | 单机房 | 对机房级容灾能力和城市级容灾能力没有要求。 |
同城 3 机房 3 副本 | RPO=0,RTO 低,故障自动切换。 可抵御个别硬件故障和机房级灾难,无法抵御城市级灾难。 | 同城3机房。 同城机房间网络时延低。 | 需要机房级容灾能力,但对城市级容灾能力没有要求。 |
* 3 地 5 机房 5 副本 | RPO=0,RTO 低,故障自动切换。 可抵御个别硬件故障、机房级灾难和城市级灾难。 | 3 地 5 机房。 其中 2 个城市距离较近,网络时延低。 | 需要机房级容灾能力和城市级容灾能力。 |
同城 2 机房,集群间数据复制 | RPO>0,RTO 高,人工决策切换。 可抵御个别硬件故障、机房级灾难,无法抵御城市级灾难。 | 同城 2 机房。 | 有 2 个同城机房,同时有机房级容灾的要求。 |
2 地 3 机房,5 副本+集群间数据复制 | 机房级故障:RPO=0,RTO 低,故障自动切换。 城市级故障:RPO>0, RTO 高,人工决策切换。 可抵御个别硬件故障、机房级灾难和城市级灾难。 | 2 地 3 机房。 | 有 2 个城市 3 个机房,同时有机房级容灾和城市级容灾的要求。 |
Q:OceanBase 数据库作为一款分布式数据库,业务 APP 连接数据库时和传统数据库是否有不同?
A:OceanBase 数据库作为分布式数据库,副本可能分布在不同的机器上,为了尽可能地减少跨机数据访问,我们提供了 OBProxy。OBProxy 作为 OceanBase 分布式关系数据库专用反向代理服务器, 为前端用户请求提供了高性能、高准确率的路由转发服务, 为后端 Server 服务提供了高可用易扩展的容灾保障. 相对于其他数据库的代理服务器, OBProxy 根据实际单机环境和 OceanBase 多集群部署的特点, 采用异步框架和流式转发的设计, 采用 FastParse 和 LockFree 的内存方案, 具备有限资源占用下百万 QPS 的能力和海量部署下丰富便捷的运维支持能力。
Q:什么是实例,什么是租户,它们的关系是什么?
A:OceanBase 数据库是一个多租户系统, 一个实例即 OceanBase 集群中的一个租户。 租户之间的数据不能互相访问。
Q:我需要一个实例还是多个实例?
A:如果有多个子系统, 每个子系统在数据库层面没有交互,建议每个子系统使用不同的实例。
Q:OceanBase 数据库在开发中要特别注意什么?
A:以下列出开发过程中的注意事项,供参考:
表建好后,主键不能更改。如果需要修改,只能删表重建。
列类型修改有较大限制。varchar 长度只能由短变长,不能由长变短。
索引生效时间较长,建议在建表时将索引语句一并纳入。
大数据量导入需要特别关注内存的使用情况。
mysql-connector-java 的版本建议使用 5.1.30 及以上。
如果一个连接超过 15 分钟空闲,服务端会主动断开,在使用连接池的时候需要设置一个连接最大的空闲时间,比如 Druid 的 minEvictableIdleTimeMillis 小于 15 分钟。
Q:应该使用分区表吗?
A:是否使用分区表,可以参考以下信息进行判断:
如果一张表的数据量在可预期的未来会突破 200 GB,建议使用分区表。
如果表具有比较明显的时间周期,建议使用分区表。