各位关心OceanBase数据库的同学,大家好!我是OceanBase团队的蒋志勇。借DBAplus社群直播平台,和大家聊一聊近八年来OceanBase的发展以及关键特性。
遵循“解决问题→发展产品→解决更大的问题→锻炼出更好的产品”这个循环:
OceanBase从解决收藏夹的海量数据存储问题入手,有了一个小团队并活了下来;
为了解决高可用的问题,采用三集群部署方式;
为了降低业务迁移成本及支持分析型应用,增加了SQL功能;
到目前的全对等架构、三地五中心城市级自动容灾(可参考:城市级故障自动无损容灾的“新常态”方案)、支持主流关系数据库功能使得业务零修改迁移,最终使得支付宝核心业务能够运行在OceanBase上。
从特性上说,OceanBase具备线性扩展、高可用、高性能、低成本,以及和主流关系数据库产品高度兼容等特点。
一个是性能,通过OBProxy的路由功能,可以比较准确地将语句路由到合适的节点处理,减少集群内部转发;
另外一个是容错能力,在网络发生闪断情况下,OBProxy可以重建连接,让业务无感知。
对业务来说,OceanBase分布式架构能做到的最好状态是什么呢?我认为是对业务透明。通过分布式架构,我们做到高可用、做到可扩展,但是对业务系统,要做到透明,表现为一个单节点数据库,体现在如下几点:
在满足业务高速发展的过程中,OceanBase数据库要解决的首要问题就是扩展性问题。
在集群中增加节点→让新节点具备服务能力→将一部分负载分发到新节点上
看起来,似乎和将大象装进冰箱一样,步骤明确。但每一步都不是那么好做的。
多副本机制。多副本不仅是高可用的基础,也是在线扩容的基础。从本质上来看,扩容无外乎两种:一种是将新数据写入到新节点,后续对该部分数据的读写也在新节点;另一种是将现节点上的部分数据移动到新节点并在新节点提供服务。
第一种情况容易处理;第二种情况就需要利用多副本机制,简单地理解就是把其中的一个副本从原节点迁移到新节点,说起来简单,做起来有很多的细节要考虑,比如在异地增加一个副本,怎么样做到既能高效地迁移数据同时又不影响现有服务。
可参考:多类型副本混搭:降低集群成本的利器细粒度的主备关系。传统的主备大多数是节点级的,由于一个节点上保存的数据量较大,主备切换的影响很大。在OceanBase中,主备关系的粒度是分区级的,这是一个很细的粒度,切换对业务的影响比较小,并且切换是秒级的。
位置信息自动刷新。在扩容引起分区位置变化后,在第一次访问原位置时,系统会检测到变化,并且刷新位置信息来进行重试,执行成功后向客户端返回正确的结果。除OBServer端以外,OBProxy也会根据服务端的反馈来更新自己保留的位置信息,后续的访问就会被直接路由到正确的节点而无需集群内部转发。
高可用是OceanBase数据库安身立命的根本,以下三篇文章对此进行了详细的描述:
传统关系数据库高可用的缺失
如何在非可靠硬件上实现金融级高可用?
基于Raft分布式一致性协议实现的局限及其对数据库的风险
它们包括了“OceanBase和传统数据库的差异,以及,在选举协议上为什么我们选择Paxos协议而不是更容易理解的Raft协议?”等内容。在这里简短总结如下:
除了读写分离架构带来的性能提升外,我们在整个执行链路上做了不少优化,主要包括如下几类:
除上述情况以外,我们还做了很多细致的工作。整体来看效果非常明显:2017年“双十一”峰值4200万次操作每秒,用户体验相当顺滑,系统表现很平稳。
OceanBase一方面需要满足业务对数据库的要求,另一方面也要节约成本,不仅仅是运营成本,还包括业务迁移和人员学习成本。
通过执行路径性能提升降低计算成本;
通过读写分离架构优势降低存储成本,一个真实的案例是某内部业务从Oracle迁移到OceanBase,原先的100TB缩小到30几个TB。因为OceanBase中可以采用压缩比更高的压缩算法,而在Oracle中,由于是原地更新要兼顾性能,没法采用消耗CPU过多的高压缩比压缩算法;
通过多租户架构,不同负载类型的业务通过多租户方式混合部署,能更加充分地利用了机器资源(可参考:多租户机制概述)。从实际应用来看,采用OceanBase数据库的金融业务,单账户成本只有原先的1/5到1/10。
兼容性
以上的几个特点使得OceanBase具有竞争优势,但要将业务真正从原系统迁移到OceanBase还需要一个额外的特性——兼容性。高兼容性使得系统迁移能在可控的成本下进行。
对公司内部MySQL业务,OceanBase能做到业务零修改迁移。可以这么说,主流关系数据库具备的常用功能OceanBase都具备了。不仅是在语法层面,而且是在用户体验和业务体验上完全一致。
Q1:请问OceanBase支持多表Join、分组、窗口函数等复杂查询吗?
Q3:OceanBase查询优化器和Oracle相比如何?有没有像Oracle执行计划变更造成SQL性能下降的问题?
答:优化器相对于Oracle还有差距,也需要解决稳定性问题。
Q4:是每个Zone上的数据是不同的、每个Zone上有三副本么?
答:通常每个Zone数据是相同的,一份数据在各个Zone都有一个副本。
Q5:OceanBase多副本,副本间如何高效同步,又如何保持从多副本读写效率的高效呢?
Q7:如果查询设计多个表,而所分配的MergeServer缓存的子表信息不全,是否需要通过请求多个MergeServer共同完成?
答:在1.0以后,没有MergeServer了,都是全对等节点。涉及多个节点的查询会生成分布式计划。
Q9:请问阿里在双十一这种活动场景下,对超热点数据有什么特别的优化?比其他主流数据库的性能如何呢?
Q10:如果在获取ChunkServer数据的过程中MergeServer挂了怎么办?
Q11:OceanBase你说的Zone是Shard分片的意思么?
Q12:OceanBase是否对OLAP和OLTP系统是否由用户选择不同的存储引擎,还是同一个引擎支持?
Q13:OceanBase没有Shard的功能对么?那么提供高可用、城市级容灾、在线扩容,记得你说数据可能不在同一个节点,那就是数据分片了吗?
答:数据是分片的,分片的规则由用户来定,类似于Oracle的分区。
Q14:多副本下怎么保证每次读取的是最新或是满足一致性的数据?读取也走一次Paxos Instance?
Q15:多副本之间是如何复制的?物理日志?逻辑日志?还是其他方法?