多可用区部署、生态支持和集群共享,金融核心系统如何实践云数据库OceanBase

  1. 云栖社区>
  2. 博客>
  3. 正文

多可用区部署、生态支持和集群共享,金融核心系统如何实践云数据库OceanBase

云栖小秘书 2016-09-01 09:49:22 浏览7912
展开阅读全文
本文主要从OceanBase的起源开始讲起,进而和大家分享了OceanBase的历程与架构演进,重点介绍了云数据库OceanBase,最后谈及了OceanBase未来的发展。

直播视频:点此进入

PDF下载:点此进入

以下为演讲内容整理:

 

什么是OceanBase

OceanBase是在2010年6月份开始立项的,OceanBase不是NoSQL系统,它是结合传统关系型数据库功能上的优点和分布式系统在可扩展性、可靠性上的优点打造的一款分布式关系型数据库。OceanBase支持完整的ACID,可扩展、高可用,兼容MySQL协议。

 

OceanBase的发展历程

fc0e7735b9d60cd307e38f1d9338305fa95ab434

互联网对传统关系型数据库的挑战

可扩展性

cec42e371e773bc67fed878e9d5aa05992ef6ea1

传统关系数据库本质上是单机数据库,当你的性能或容量不足时,需要换一台更大的机器,我们是一直向上扩展。想要水平扩展需通过读写分离 & 分库分表来解决,这也极大的增加了应用层的复杂度。以图中收藏夹业务为例,收藏一个商品称为收藏信息,包括收藏本身和收藏商品的信息,收藏的商品信息是变化的,商品降价需要在用户收藏夹里体现出来,收藏信息只能按用户区分,商品只能按商品ID区分,当一个用户收藏了多个表的商品时,需要在中间件层完成join操作,这样会加大业务的负担,相当于在中间件层或业务层完成了数据库本该完成的工作。

可靠性

5dee0d52364298246276fb2031bfa77b010d27a4

传统关系型数据库本质上是一个单机系统,主备间是需要进行数据同步的,数据同步有三种模式:最大可用模式、最大保护模式、最大性能模式。最大保护模式要求主库和备库都写成功后才会应答客户,一旦网络抖动或者备机宕机等,整个服务就中断了,互联网行业中用这种模式比较少。最大可用模式要求主库写成功后就立即应答客户,然后把数据异步同步给备库,一旦主库宕机,极有可能造成数据不一致的情况,为了解决数据不一致的问题,一般会加共享存储等保证可靠性;主备机无法决策出谁是主谁是备,如果主机宕机,备机无法自己切换成主机,需要通过第三方组件切换。

 

OceanBase的目标

在使用普通PC服务器,不使用共享存储、小型机等昂贵硬件,以及服务器、磁盘、网络、机房(IDC)等并非持续可用的情况下,OceanBase的目标是:

首先要保证关系型数据库的功能、支持跨表跨行事务,其次要保证数据可以分布式水平扩展,对应用透明,另外,数据库要高可靠、数据强一致,可抵御单机、机架、机房(IDC)故障,且高性能。

 

OceanBase主要面临的问题

  • 数据库的功能:传统关系型数据库发展时间较长,功能丰富
  • 分布式一致性:分布式系统的多副本如何保持一致性;最终一致性、弱一致性不符合用户需求
  • 分布式事务:理论成熟,工程与性能上的优化

数据库数据总量非常大,但增删改量很少。

93228b9b10aabd6be96cf3065a41f8688d69d916

我们设计了如图架构,把数据分成两个部分,一部分为基线数据,另一部分为增量数据。每次的修改我们就放到一个单机的内存中,基线数据拆分到多个机器上,这样就避免了分布一致性的问题。

22eb71bfc69023eabf6b4cf3675a203979daa747

增量数据不可能永远放在内存中,所以内存写到一定程度后会做每日合并,合并会在数据库每天的访问低谷时进行,对业务没有影响。

最初版本V0.2

a88fa0bf1d52b58706cd05c3888903b98a10ba43

  • 存在两个单点RootServer和UpdateServer,通过HA(http://linux-ha.org/)来实现高可用
  • 基线数据节点可任意扩展
  • 写节点半同步,不能区分insert / update

V0.2相对较原始,我们的客户端代码由业务同学来写,我们的更新直接会到UpdateServer端,不能区分insert / update,这样解决了收藏夹的一个业务痛点(通过数据冗余+Join更新信息消灭随机读/写)。

V0.3 IDC & OLAP                 

c09b11d4f34f3b915d12bfd3f039ea8e01fd57e1

  • 相比于V0.2不同的是,V0.3去除UpdateServer的HA,改由RootServer来决定谁是Master
  • 支持多IDC部署、但IDC切换需要人工介入
  • 在查询层面对并发作了优化,可满足轻量级的OLAP

f8580af83891872059394d0a1fd6e3aa912b6f1b

V0.3绑定的业务是广告报表,主要是把数据在离线的平台计算好后导到关系数据库中,实现数据分块、并发查询,旁路导入数据。V0.3达到了千亿条记录和百T规模数据,但客户端的表现力差。

V0.4 支持SQL

4237c3ca0fc0e533717f4e20f526e2cf64ae474a

V0.4支持SQL,并不是单纯改一个接口那么简单,我们在数据库功能方面迈出了一步。V0.4兼容MySQL协议,区分update/insert,支持并发更新。

V0.4去除自定义协议的客户端,没有特别多的核心业务,主要是历史库、结构化Key/Value类型的非核心业务,我们也对外开源,并开始核心业务的尝试。

V0.5 多机房同步

18f6b616b26631be35457a36db01834b33e10292

  • RootServer分布式选主,不再依赖HA
  • 多机房部署,少数派机房故障自动容灾,数据不丢失
  • 覆盖蚂蚁多个核心系统

7543049a206e2f4fb039746e3b52e1074807cf2b

在迁入核心业务系统时,我们也积累了经验,形成一套模板。比如最开始上线的蚂蚁交易核心系统;当年双11承担20%的流量;2015完成支付在内的多个核心系统迁移;第一个支撑的银行的非商业数据库。我们积累了一整套迁移方法,比如用蚂蚁中间层向应用屏蔽掉了SQL的差异,中间层通过访问数据的类型去调用不同的模板,灰度引流,随时回滚,我们称蚂蚁为流水型的系统。

回过头考虑0.5之前的架构,得出单UpdateServer的意义手至关重大的,极大简化实现,避免分布式事务,具有较简单的数据模型。当然在集群规模、数据导入上也有诸多限制。

V1.0

d38fa6ef4c34ca23fcb806d1c8ae718e4a61ae4b

V1.0变更了数据模型,我们把数据分布引入了传统观念数据库的分区表,交给用户来定义,根据业务特点可能把数据分成一片一片,这时,我们把四种角色都合并到一个角色中,称为ObServer。每个ObServer是对等的,它可以负责一个分区或者多个分区的数据,每个分区会部署在3个机房,这三个副本之间会自行通过分布式选举,选举出一个组来提供服务,此时我们具备很高的灵活性,用户可以根据业务逻辑来分区。

同步机制

04d125be840c6188330c9c9f6c993f9e50064782

主库执行写事务并同步到备库,超过半数成功则事务成功。

错峰合并

3679c472d4c8de64c6e40d96af9630995dbcbf9b

  • 逐IDC合并,灰度引流,缓存预热,对用户没有影响
  • 同样的用在升级流程上,往往是在备库升级好,再切到主库中

OceanBase有着天然的优势,无论是在版本升级还是维护,都可以应用到这套机制,整个维护或者故障都可以做到对用户透明,用户感知不到变化。

降低每日合并耗时

c3233bb79ab88238771a91013c6ee68de32d09c4

最开始数据分布采用范围分布,一条记录修改,整个数据重写。我们在每日合并上也做了优化,采用了更细粒度的分片,把数据分块,如果某块数据发生更改,只对这条数据进行重写即可。

 

云数据库OceanBase

afbfc820de81c98dfa3218236f3d3018b84019d3

云数据库OceanBase是一款阿里巴巴自主研发的高性能、分布式的关系型数据库,支持完整的ACID特性。它高度兼容MySQL协议与语法,让用户能够以最小的迁移成本使用高性能、可扩展、持续可用的分布式数据库服务,同时对用户数据提供金融级可靠性的保障。云数据库OceanBase相对于传统数据库的特点如下:

  • 基于OceanBase的DBaaS:提供自助化服务,一键即可拥有OceanBase实例;免管理;提供使用建议
  • 在蚂蚁和集团长期使用,原生态输出
  • 具备输出到专有云的能力:网商银行

总的来说,云数据库OceanBase具备多可用区部署,与内部最新版本保持同步,以及生态支持和集群共享模式、无缝动态伸缩、即时生效。

 

未来发展

  • OceanBase目前仍然在快速迭代
  • 灰度升级对应用透明
  • 让数据库的归数据库,一切以简化用户使用为目标

未来OceanBase主要应考虑以下几个方面:

完善功能:以业务需求驱动,业务不符合什么功能我们就做什么功能;满足内部业务的平滑迁移,完善数据库兼容性问题;OceanBase重点完善支持FlashBack。

历史库:历史库是关系型数据库的一些瓶颈造成的,OLTP系统有典型的冷热数据;为了降低成本等,冷数据需要迁移,OceanBase正在做冷热数据自动识别、异构机型等。

OLTP & OLAP混合负载:OceanBase比较适合OLAP的,OceanBaseK可以做在线数据和离线数据同时进行分析,可以做ObServer内的资源隔离、大查询限流、利用备副本等。

成本:保持高可用的情况下,降低副本数。

 

网友评论

登录后评论
0/500
评论
云栖小秘书
+ 关注