守住携程“生命线”
每逢节假，尤其是黄金周，携程“IM+”客服业务，都会迎来一波流量高峰，而数据扩容一直是令DBA运维头大的问题，比如：
- 数据存储达到MySQL存储极限，只能保证两个月数据的存储；
- MySQL主备架构，无法通过横向扩容扩展存储性能；
- 采用MySQL机房间主备方案，在机房故障条件下无法保证数据强一致和快速业务恢复能力。
数据资产作为企业的生命线，任何机房的故障，DBA去切的时候，会造成数据损失，造成无法评估的资损。OceanBase 与携程携手面对挑战，提出了有效降本增效的解决方案：
降本增效·解决方案
针对存储极限问题，OceanBase 替换MySQL，获得接近85%的数据压缩能力，同样的存储配置情况下即可获得存储一年数据的业务价值。
针对扩容问题，采用 OceanBase 提供的横向扩容能力，通过OCP一键式白屏操作，加减机器即可应对业务的扩所容，保证业务的服务质量。
针对高可用问题，基于 OceanBase 多副本一致性保证，保证RPO=0 ，RTO<3分钟。
整个迁移过程非常平滑，OMS数据迁移和同步能力，保证了数据库切换过程的平滑稳定。
迁移后，携程在同等硬件投入前提下获得超过一年的数据存储能力，满足业务需求；自动的故障切换，提高针对机房，机器故障的快速恢复能力，保证SLA；同等应将投入前提下，通过技术升级，得到强数据一致性保证，降低数据丢失风险。
你好，我是“蓝”朋友
目前，国内DBA大概有几十万人，但研发群体却有几百万人，OceanBase 不仅仅面向DBA，更面向广大研发朋友。正如它的名字一样—— OceanBase，像蓝色大海一样，广阔无垠，蕴含着巨大的能量，希望通过一个原生的分布式数据库，向研发人员提供一个像单机数据库一样简单、易用、可靠的数据库。
从互联网技术架构演进，我们可以更清晰地认识 OceanBase 这位“蓝”朋友。
互联网的早期技术架构是单体架构，ALL IN ONE应用+数据库的模式就可以承载业务需求，当时的淘宝也是从“PHP+MySQL”的模式开始演进的。随着业务的增长，单体架构已经无法承载业务的容量，于是开始对架构进行模块拆分，出现了一些垂直架构。
2000年左右，互联网井喷式增长，分布式架构初现雏形。研发人员会用到如Nginx、SLB等负载均衡框架，将后端的复杂应用屏蔽；此时如果对后端应用实例进行增减，整个业务都是无感知的，这就是Spring Cloud的架构。本质上，微服务架构是分布式架构，解决的是分而治之的问题，而加入一些分布式中间件，如zookeeper、ETCD，或基于PAXOS、Raft、Zab等协议，解决全局业务的协调一致性。
随着数据库的架构演进，单机架构已经都到瓶颈，无法满足大多数业务应用的诉求；当前绝大数企业采用的是分库分表架构，架构理念采用的是PG数据库的PG XC架构，将分库分表、分布式一致性等中间件下移到数据库能力上，但依然是一套外挂架构，面对偏分析的场景可能会导致事倍功半；随着谷歌Spanner的发布，数据库进入分布式时代，并且Spanner实现了全球一致性。
从单机架构到分库分表架构，再到原生分布式架构，纵观架构演进历史，下一代数据库架构将具有哪些特性？
特性1：云架构
- 支持多云部署，裸金属/公有云/私有云均支持部署
- 不依赖专有硬件，基于普通X86/ARM提供金融级别高可用
特性2：原生分布式 多副本强一致性
- 数据自动分布对应用透明，无需中间件分库分表
- 全对等节点，读写多活
- 多副本，Paxos协议副本间强一致性
特性3：水平扩展 线性高性能
- 集群在线横向扩容/缩容，不停服务
- 性能线性扩展，单集群超过 1000 台服务器，单库数据量超过2PB，峰值处理6100万次/秒
特性4：多模式多租户
- 支持多运行模式， 高度兼容Oracle/MySQL数据类型、对象、函数、SQL语法、过程语言
- 单一OceanBase 集群灵活支持多个Oracle/MySQL租户
- 租户间资源隔离，且可以在线动态调整
特性5：平滑高可用 容灾切换
- 表/表分区级的高可用，自动故障/灾难切换
- 少数副本故障，RPO=0（不丢数），RTO<30s（自动内部平滑切换）
如何应对更多挑战
随着业务体量的不断增长，单个数据库无法满足需求，基础组件会外挂很多中间件，如Sharding分库分表、zookeeper等分布式一致性组件，数据库架构是异构的，不止有分库分表，部分数据库依然是主从，对业务架构提出了很多挑战。
- 当前数据库架构——技术挑战
当前数据库架构基本上是MySQL一主多从架构，业务写入只能写到Master，在业务爆发式增长下，写入量激增MySQL单Master会成为瓶颈；日常备库资源水位偏低，当从库的存储已经达到90%+，但资源（CPU）利用率只有5%-10%。读写分离架构是逻辑复制，由于业务量激增写入量变大，逻辑复制的性能消耗，加上多活、跨机房等原因，会出现binlog主从延迟，新写入的数据无法及时的被读取出来，导致业务受到影响。在高可用架构上，MySQL主库Down机，HA架构存在数据丢失风险，且需要 DBA手工做主从切换，业务连续性无法保障。Sharding分库，本质是由多个数据库组成，存在中间件瓶颈问题，跨库事务、一致性、关联查询等问题。
- 当前数据库架构——运维挑战
用户选择适应应用的数据库架构，就等于同时对运维提出了相应的要求，随着业务量的快速增长，也面临着规模化运维的问题。DBA在日常运维时，磁盘或服务器的故障是小概率事件，但规模化运维时，故障就可能每天都在发生，导致DBA的工作变得碎片化，充满着性能调优、故障处理、宕机恢复等工作，影响业务正常开展。通常来说，当故障发生时，DBA应当是企业数据库稳定性的最后一道保障，但他的日常工作过于琐碎，也缺乏良好的工具支撑，企业全局的业务连续性存在非常大的隐患。蚂蚁集团从2010年开始探索原生分布式数据库领域。2014年的去IOE过程中，支付宝业务迁移到 OceanBase，至今已有八年，扛过了一次又一次双十一“洪峰”，峰值一度高达6100万次/秒，同时也经过了大量金融场景的考验。到目前，OceanBase 已经100%成为蚂蚁集团的数据库底座，总规模达到数百万核量级。OceanBase Cloud助力企业显著降本增效，集成了一系列完善的工具，将蚂蚁集团多年的运维经验积累的能力分享给用户。
认识下OceanBase
2020年，OceanBase开启商业化进程，从金融走向千行百业、走向全球。两年来，OceanBase不断助力金融、政府、运营商、零售、互联网等多个行业的客户实现关键业务系统的稳定运行和长效发展，同时也在海外市场取得了优异的成绩。
这些成绩的背后，是十二年的坚持与热爱，是 OceanBase Cloud独特的技术魅力。
01 水平扩展
在线扩容（应用无感知），面对洪峰场景，在线扩容增加每个高可用域（Zone）的 OceanBase 节点的数量，数据库租户也增加资源单元，系统自动将表/表分区的各个副本重均衡分布到新增加的 OceanBase 节点，采用物理拷贝，每节点性能>500MB/s，无需重新 Hash 每条记录，同时，应用无感知，无需像分库分表那样对应用配合大量改造。该方法同样支持在线缩容的操作。
02 平滑高可用/容灾切换
OceanBase 内部自动切换、无需人工干预和复杂决策流程，基于Paxos协议的典型多副本(三副本或以上)部署，能够实现数据强一致性、持续可用，主备自动切换，对上层业务透明。
一旦发生单机、机房、城市级故障，OceanBase 内部自动故障切换，不影响服务（RTO < 30s），不丢任何数据（RPO = 0）。
03 计算资源整合和存储成本下降
一方面，OceanBase 通过DBaaS能力，多租户隔离，例如在一主两从架构下，通过多租户能力，主可用区提供写入，下一位租户就可以置入下一个可用区，让机器资源充分利用，按需分配调整资源（快速升降配），读写能力都可以放在从节点上。另一方面，OceanBase 自主研发的存储引擎，通过数据编码机制以lsm存储架构，无性能损耗，存储成本至少省 80% 以上。
守住携程“生命线”
每逢节假，尤其是黄金周，携程“IM+”客服业务，都会迎来一波流量高峰，而数据扩容一直是令DBA运维头大的问题，比如：
- 数据存储达到MySQL存储极限，只能保证两个月数据的存储；
- MySQL主备架构，无法通过横向扩容扩展存储性能；
- 采用MySQL机房间主备方案，在机房故障条件下无法保证数据强一致和快速业务恢复能力。
数据资产作为企业的生命线，任何机房的故障，DBA去切的时候，会造成数据损失，造成无法评估的资损。OceanBase 与携程携手面对挑战，提出了有效降本增效的解决方案：
降本增效·解决方案
针对存储极限问题，OceanBase 替换MySQL，获得接近85%的数据压缩能力，同样的存储配置情况下即可获得存储一年数据的业务价值。
针对扩容问题，采用 OceanBase 提供的横向扩容能力，通过OCP一键式白屏操作，加减机器即可应对业务的扩所容，保证业务的服务质量。
针对高可用问题，基于 OceanBase 多副本一致性保证，保证RPO=0 ，RTO<3分钟。
整个迁移过程非常平滑，OMS数据迁移和同步能力，保证了数据库切换过程的平滑稳定。
迁移后，携程在同等硬件投入前提下获得超过一年的数据存储能力，满足业务需求；自动的故障切换，提高针对机房，机器故障的快速恢复能力，保证SLA；同等应将投入前提下，通过技术升级，得到强数据一致性保证，降低数据丢失风险。
你好，我是“蓝”朋友
目前，国内DBA大概有几十万人，但研发群体却有几百万人，OceanBase 不仅仅面向DBA，更面向广大研发朋友。正如它的名字一样—— OceanBase，像蓝色大海一样，广阔无垠，蕴含着巨大的能量，希望通过一个原生的分布式数据库，向研发人员提供一个像单机数据库一样简单、易用、可靠的数据库。
从互联网技术架构演进，我们可以更清晰地认识 OceanBase 这位“蓝”朋友。
互联网的早期技术架构是单体架构，ALL IN ONE应用+数据库的模式就可以承载业务需求，当时的淘宝也是从“PHP+MySQL”的模式开始演进的。随着业务的增长，单体架构已经无法承载业务的容量，于是开始对架构进行模块拆分，出现了一些垂直架构。
2000年左右，互联网井喷式增长，分布式架构初现雏形。研发人员会用到如Nginx、SLB等负载均衡框架，将后端的复杂应用屏蔽；此时如果对后端应用实例进行增减，整个业务都是无感知的，这就是Spring Cloud的架构。本质上，微服务架构是分布式架构，解决的是分而治之的问题，而加入一些分布式中间件，如zookeeper、ETCD，或基于PAXOS、Raft、Zab等协议，解决全局业务的协调一致性。
随着数据库的架构演进，单机架构已经都到瓶颈，无法满足大多数业务应用的诉求；当前绝大数企业采用的是分库分表架构，架构理念采用的是PG数据库的PG XC架构，将分库分表、分布式一致性等中间件下移到数据库能力上，但依然是一套外挂架构，面对偏分析的场景可能会导致事倍功半；随着谷歌Spanner的发布，数据库进入分布式时代，并且Spanner实现了全球一致性。
从单机架构到分库分表架构，再到原生分布式架构，纵观架构演进历史，下一代数据库架构将具有哪些特性？
特性1：云架构
- 支持多云部署，裸金属/公有云/私有云均支持部署
- 不依赖专有硬件，基于普通X86/ARM提供金融级别高可用
特性2：原生分布式 多副本强一致性
- 数据自动分布对应用透明，无需中间件分库分表
- 全对等节点，读写多活
- 多副本，Paxos协议副本间强一致性
特性3：水平扩展 线性高性能
- 集群在线横向扩容/缩容，不停服务
- 性能线性扩展，单集群超过 1000 台服务器，单库数据量超过2PB，峰值处理6100万次/秒
特性4：多模式多租户
- 支持多运行模式， 高度兼容Oracle/MySQL数据类型、对象、函数、SQL语法、过程语言
- 单一OceanBase 集群灵活支持多个Oracle/MySQL租户
- 租户间资源隔离，且可以在线动态调整
特性5：平滑高可用 容灾切换
- 表/表分区级的高可用，自动故障/灾难切换
- 少数副本故障，RPO=0（不丢数），RTO<30s（自动内部平滑切换）
如何应对更多挑战
随着业务体量的不断增长，单个数据库无法满足需求，基础组件会外挂很多中间件，如Sharding分库分表、zookeeper等分布式一致性组件，数据库架构是异构的，不止有分库分表，部分数据库依然是主从，对业务架构提出了很多挑战。
- 当前数据库架构——技术挑战
当前数据库架构基本上是MySQL一主多从架构，业务写入只能写到Master，在业务爆发式增长下，写入量激增MySQL单Master会成为瓶颈；日常备库资源水位偏低，当从库的存储已经达到90%+，但资源（CPU）利用率只有5%-10%。读写分离架构是逻辑复制，由于业务量激增写入量变大，逻辑复制的性能消耗，加上多活、跨机房等原因，会出现binlog主从延迟，新写入的数据无法及时的被读取出来，导致业务受到影响。在高可用架构上，MySQL主库Down机，HA架构存在数据丢失风险，且需要 DBA手工做主从切换，业务连续性无法保障。Sharding分库，本质是由多个数据库组成，存在中间件瓶颈问题，跨库事务、一致性、关联查询等问题。
- 当前数据库架构——运维挑战
用户选择适应应用的数据库架构，就等于同时对运维提出了相应的要求，随着业务量的快速增长，也面临着规模化运维的问题。DBA在日常运维时，磁盘或服务器的故障是小概率事件，但规模化运维时，故障就可能每天都在发生，导致DBA的工作变得碎片化，充满着性能调优、故障处理、宕机恢复等工作，影响业务正常开展。通常来说，当故障发生时，DBA应当是企业数据库稳定性的最后一道保障，但他的日常工作过于琐碎，也缺乏良好的工具支撑，企业全局的业务连续性存在非常大的隐患。蚂蚁集团从2010年开始探索原生分布式数据库领域。2014年的去IOE过程中，支付宝业务迁移到 OceanBase，至今已有八年，扛过了一次又一次双十一“洪峰”，峰值一度高达6100万次/秒，同时也经过了大量金融场景的考验。到目前，OceanBase 已经100%成为蚂蚁集团的数据库底座，总规模达到数百万核量级。OceanBase Cloud助力企业显著降本增效，集成了一系列完善的工具，将蚂蚁集团多年的运维经验积累的能力分享给用户。
认识下OceanBase
2020年，OceanBase开启商业化进程，从金融走向千行百业、走向全球。两年来，OceanBase不断助力金融、政府、运营商、零售、互联网等多个行业的客户实现关键业务系统的稳定运行和长效发展，同时也在海外市场取得了优异的成绩。
这些成绩的背后，是十二年的坚持与热爱，是 OceanBase Cloud独特的技术魅力。
01 水平扩展
在线扩容（应用无感知），面对洪峰场景，在线扩容增加每个高可用域（Zone）的 OceanBase 节点的数量，数据库租户也增加资源单元，系统自动将表/表分区的各个副本重均衡分布到新增加的 OceanBase 节点，采用物理拷贝，每节点性能>500MB/s，无需重新 Hash 每条记录，同时，应用无感知，无需像分库分表那样对应用配合大量改造。该方法同样支持在线缩容的操作。
02 平滑高可用/容灾切换
OceanBase 内部自动切换、无需人工干预和复杂决策流程，基于Paxos协议的典型多副本(三副本或以上)部署，能够实现数据强一致性、持续可用，主备自动切换，对上层业务透明。
一旦发生单机、机房、城市级故障，OceanBase 内部自动故障切换，不影响服务（RTO < 30s），不丢任何数据（RPO = 0）。
03 计算资源整合和存储成本下降
一方面，OceanBase 通过DBaaS能力，多租户隔离，例如在一主两从架构下，通过多租户能力，主可用区提供写入，下一位租户就可以置入下一个可用区，让机器资源充分利用，按需分配调整资源（快速升降配），读写能力都可以放在从节点上。另一方面，OceanBase 自主研发的存储引擎，通过数据编码机制以lsm存储架构，无性能损耗，存储成本至少省 80% 以上。
