蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf

所需积分/C币:31 2019-03-12 13:48:05 3.6MB PDF
收藏 收藏 2
举报

蚂蚁金服自研数据库OceanBase的设计与实践哲学,转自微信号“InfoQ”
2019/38 nfoQ 作者|隗华 编辑|薛梁 本文整理自2018年 Archsummit北京站蚂蚁金服 Ocean base团队高级技术专家隗华(花名:风羿)的演讲,本文将带读者深入了解 Ocean base应对业务挑战时在架构上的演进和思考。 写在前面 Ocean base自2010年开始立项,到现在已经走过了大约八年多的时间。这八年风风雨雨,几度生死。我们一直秉承着这样一个理念: 产品和技术最终是为了解决业务的实际问题,帮助业务持续成长而存在的。 关于 Ocean base 关于 Ocean base数据库,我会从以下四个断言开始介绍: 1.100%自主知识产权的国产数据库:这意味着 Ocean base数据库不基于任何开源数据库,比如 MySQL。我们的百万级的代码都是 整个团队一行一行地积累起来的,所以 Ocean base完全是一个拥有自主知识产权的数据库; 2.商业数据库: Ocean base在早期0.4版本的时候曾经开源过,从0.5版本后, Ocean base开始在支付宝的核心链路上线以后,整 个团队调整了产品的整体定位,逐渐向商业数据库的方向发展。在这样一个大背景下,在可预期的未来很长的一段时间里, Ocean base还会是一个闭源的数据库; https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 2019/38 nfoQ 3.通用关系型数据库: Ocean base是满足AC|D特性的通用关系型数据库; 4.原生分布式数据库: Ocean Base也可以被归到NewSαL数据库里, Oceanbase一直坚持的一点就是:在数据库层能够解决的事就 全都放在数据库里去解决,所以我们支持两阶段提交协议、全局索引和全局一致性等。 Ocean base项目从2010年开始启动,到现在为止走过了八年。2014年, Ocean base在内部开始承接支付宝的核心业务。截止到今 天,几乎所有的支付宝业务,不管是核心链路和非核心链路,都是跑在 Ocean base上。2017年底, Ocean base开始走向外部,正式 对外商用,到现在已经服务了数十个客户,持续帮助客户打造互联网金融的核心。 Ocean base目前已经发布到了2.0版本,而且这个版本已经经历了2018年双11的洗礼,后面我们也会把 Ocean base2.0版本推向 外部,来帮助更多的外部客户解决他们的实际问题 Ocean base架构介绍 Ocean base本身是一个分布式的集群,通常情况下是多副本的存储。所以一般会分为三个子集群,每一个子集群叫做一个z0ne。一个 zone里有多个节点和服务器组成,我们管它叫 OBServer。对于每一个分区,在整个集群内它都有三个副本。 https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 4/21 2019/38 nfoQ zone 1 0B Server 0B Server 总控服务(主 0B Server …""…""… Root Service sL引擎 5GL引擎 sQL整 Partition service Partition service RYeN 存储引擎 存储引擎 存储引擎 分分分 分分.分 分分.分 区区区 区区区 区区区 zone 2 0B Server zone 3 0B Server oB Server 总捏服务 0B Server 0B Server 总捏罹务(备 0B Server Root Sen Root service s引擎 sQL引擎 s引擎 S引擎 sQL引擎 sQl引擎 Partition Servi Partition Se vic Patition artition/ Service Partition/Service 存储引 存储引 存储引擎 存引擎 存储引擎 存锦弓 分分…分 分分 分分 分分 分分分 区区区 区区区 区区区 区区区 区区 区区区 Paxos协议介绍 另外值得一提的是, Ocean base支持的 Paxos协议。 Paxos协议本身相对复杂,但是其哲学思想是非常简单的,就是一个多数派投票 协议。比如一个事情,A认为成功,B认为成功,C认为不成功,根据多数派协议认定这个事情最后是成功的。那么具体到这里,这三个 分区的一主两备,就形成了 Paxos协议的成员组。 https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 2019/38 nfoQ 微观来看,这是实现数据库高可用和强一致性的一个基础。简单的描述一下 每个分区在集群里的数据实际有三份,即三副本。三副本之间的数据同步靠 Leader副本的事务日志同步到其他 Follower副本中。 Paxos协议会保障这个事务日志传输的可靠性(事务日志在一半以上的成员会落盘,剩余成员最终也会落盘),同时还有以分区为粒度的 选举机制,保障 Leader副本不可用的时候,能快速从现有两个 Follower副本里选举出新的 Leader副本,并且数据绝对不丟。 那么通过这种方式,在任何一个时间点数据在三个zone当中,必然是有两份完全一致的数据,而且是强一致的,这个是 Ocean base实 现一致性的基础。 同时通过这种方式,也可以实现数据库的高可用。现在有三个副本,其中有两个是完整数据的。如果宕掉一个副本的话,还剩下两个,那 么其实对整个集群对外服务是完全不受任何影响的 少数副本故障情况下 RPO=0,RTO<30秒 这里就体现了故障切换时的两个重要指标:RPo=0,RTO<30s。 OBProxy介绍 Ocean base是一个集群数据库,应用又该如何访问这个数据库? 每一个 OBServer都提供直连的功能,那么对于应用来说,当然第一个做法可以直接连里面任意的一个 OBServer;但连了之后有相当大 的概率会面对你所连的○ BServer上并没有要访问的数据。但是 OBServer本身提供这样一种能力:可以通过解析SQL语句,跟内部的 位置信息进行比对,然后知道你要访问的数据在哪个 OBServer之上,然后再做一次转发 https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 2019/38 nfoQ 但是这样就存在一个问题:首先你要做一个SαL的解析,SαL解析本身会耗去一段时间;然后解析完了之后,如果发现数据没在这里的 话,你还要再做一次转发,这个转发又会耗去一部分时间,那么对于SQL的响应时间是一个很大的挑战 所以在这个基础上我们做了一款产品叫做○ B Proxy, OBOroⅹy简单理解就是一个轻量级的sQL解析器 APP APP APP ObProxy obProxy ObProxy obServer obServer ObServer P1 P2 P1 P2 P1 P2 P3 P4 P3 P4 P3 P4 ObServer observer obServer P5 P6 P5 P6 P5 P6 PT P& P7 P8 P7 P8 IDC1 IDC2 IDC3 ---- Paxos Group https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 721 2019/38 nfoQ 那么当sαL来的时候,通过解析器可以做一个轻量的解析,大体看一下数据的位置。每一个 OBProxy会维护一个本地的 location 〔ache,然后做一个比对,知道数据在哪,然后直接做转发,把它发到对应的 OBServer节点上去执行。执行完之后,结果通过 OBProxy再返回给这个应用。 存储引擎介绍 那么最后简单给大家介绍一下 Ocean base的存储引擎,基于LSM-Tree的架构。增删改的数据其实都是在内存里。 Ocean base跟传统 数据库不太一样的地方,就是传统数据库中当一—个数据修改来的时候,要实时去修改存储,但是在这种架构下,增删改的数据就是增量数 据,它始终是放在内存里的。 那么这个架构带来的一个好处就是增删改相对来说会比较快。这个是肯定的,因为全部都在内存当中进行。 增量 MemTable(WoS Get Small-Query Row cache Update Row-Level Ln-M Redo/mv vcc s can ■叶 BigQuery Logs Block cache ■屺 InMemory in-Memory Hash · Trees Memory 基线 SSTable(ROS) epic Cas 转储 SSTable 》2》》 多个转储版本 合并 合拌后 https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 821 2019/38 nfoQ 但是有一个架构上的缺点。在读的时候,可能你的数据在內存和磁盘上同时都有。那么我们的做法是说我们接受这个事实,然后在里面做 一些优化 如上图所示的数据库中经常提到的" Row Cache”、" Block cache”还有" Bloom filter cache”等,热数据会缓存起来,大部分 单行操作只需要一次缓存查找,没有额外开销。那么相对来说性能能够达到一个比较好的状态。 我们线上的机器一般内存都比较大,一般都在512G,这些数据是不会往磁盘里去刷。当然,内存当中的增量数据到达一定的条件后,即 便有512G也总会爆的,最后总得把它写回到磁盘上来,我们管这个过程叫合并。那么合并的过程会产生大量的|O,其实对性能会有 定的影响,影响可能在10%左右。 当然这个合并其实也会带来一些额外的好处,比如说数据压缩。一般来说数据库在做数据压缩都是及时的;但是在 Ocean base里,可以 选择在合并的时候做一个集中的压缩。 现在大家知道,其实数据库我们广泛的使用SSD,随机读写型的SSD相当的贵。但是在 Ocean base里,因为我们有这样的一个操作: 写操作都在内存里进行,写磁盘都是在合并的时候,所以能够实现顺序的写,最终使得硬件的成本大峘度的降低。 3 Oceanbase架构演进 Ocean base是从2017年的时候开始走向外部,在这中间经历过很多艰难和挑战,可能是原来在淘宝和支付宝体系中根本不可能碰到的 些挑战。比如: 如何在业务高峰平滑扩容,高峰后如何缩容,甚至对业务无感知 如何去O,如何保证风险可控地去O https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 921 2019/38 nfoQ 如何解决多活和异地容灾; 如何备份分布式数据库,如何恢复到一个全局一致的时间点; ·如何规避分布式数据库的种种限制,如分区键和主键的绑定关系 如何合理部署分布式数据库,与现有云平台如何整合; ·如何解决业务数据量膨胀之后的冷热数据问题。 4 通过副本类型变更支持弹性大促 首先介绍一下 Ocean base的副本类型: https:/mp.weixin.gg.com/s/otzfedfhwi35zn9kLbhUcw 10/21

...展开详情
试读 21P 蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf
立即下载 低至0.43元/次 身份认证VIP会员低至7折
    抢沙发
    一个资源只可评论一次,评论内容不能少于5个字
    • 分享精英

      成功上传11个资源即可获取
    关注 私信 TA的资源
    上传资源赚积分,得勋章
    最新推荐
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf 31积分/C币 立即下载
    1/21
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第1页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第2页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第3页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第4页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第5页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第6页
    蚂蚁金服自研数据库OceanBase的设计与实践哲学.pdf第7页

    试读已结束,剩余14页未读...

    31积分/C币 立即下载 >