江苏龙网

  1. 首页 > 人文 > >

空心|万字详文：腾讯数据库专家深度探索Amazon Aurora( 二 )


RDS是由位于每个节点上的称为HM(HostManager)的agent来提供主从集群的状态监控、以应对主节点fail over的问题以便进行HA调度、以及某个从节点fail over需要被替换等问题 。 这样的监控服务 ， 称为control plane 。
空心|万字详文：腾讯数据库专家深度探索Amazon Aurora图1-1 Aurora整体架构
空心|万字详文：腾讯数据库专家深度探索Amazon Aurora图1-2 Aurora的Region分布图
数据库的计算服务和存储分离 ， 数据缓冲区和持久化的“数据”（对于Aurora实则是日志和由日志转化来的以page为单位的数据 ， 而不是直接由数据缓冲区刷出的page存储的数据）位于Storage VPC中 ， 这样和计算节点在物理层面隔离 。 一个主从实例 ， 其物理存储需要位于同一个Region中 ， 这样的存储称为EC2 VMs集群 ， 其是由一个个使用了SSD的Storage Node组成 。
1.2 核心技术与架构
Aurora提倡“the log is the database” ， 这是其设计的核心 。 围绕这个观点 ， 传统数据库的组件架构 ， 发生了一些变化 。
对于Aurora ， 每一个存储节点 ， 如图1-3 ， 由两部分构成 。
第一部分：Caching
第一部分是“Caching” ， 这是一个重要的关键点 ， 可惜论文没有描述其细节 。
如同传统数据库架构的数据缓冲区 ， 向事务层提供数据 。 传统数据库架构的数据缓冲区 ， 向上起着消耗存储IO的I加载数据到内存供计算层读写数据的作用、向下起着消耗IO的O写出脏数据到存储层以实现数据持久存储的作用 。 对于一个写密集的OLTP系统 ， 大量随机写花费了很多时间 ， 系统的性能因此经常表现为存储层的IO瓶颈 。 尽管checkpoint技术缓解了每个写操作刷出脏数据的冲动 ， 尽管SSD的使用缓解了存储层的瓶颈 ， 但是 ， 毕竟存储层的I与O的时间消耗还是巨大的 ， 尤其是对于随机写密集的OLTP系统 。
Aurora的设计 ， 消除了脏数据刷出的过程 ， 数据缓冲区的作用 ， 只是加载数据供上层使用 ， 而脏数据不必从数据缓冲区刷出到物理存储上 ， 这对于随机写密集的OLTP系统而言 ， 是一个福音 ， 性能的瓶颈点被去掉了一个（如图1-3 ， 在“Caching”和“Logging+Storage”之间 ， 竖线的箭头 ， 应该是指向“Caching”的 ， 以表示数据只是加载到Caching中 ， 不存在脏数据的刷出操作） 。
但是 ， 观察图1-3 ， “Caching”是位于了存储层内还是计算层内？论文没有明示 。
从图1-3观察 ， 似乎“Caching”是存储层和计算层所共用的一个组件 ， 那么就可能存在这样的一个两层设计：位于存储层和计算层各有一部分“Caching” ， 这两部分“Caching”组合成为一个逻辑上的“Caching” ， 而逻辑意义上的“Caching”似乎在AWS认为 ， 其更像是属于计算层的 。 如下文引自论文原文：
Althougheach instance still includes most of the components of a traditional kernel(query processor, transactions, locking, buffercache, access methods and undo management) several functions (redologging, durable storage, crash recovery,and backup/restore) are off-loaded tothe storage service.
位于存储层内的“Caching” ， 更像是一个分布式的共享文件系统 ， 为了提高性能也许是一个分布式内存型的共享文件系统 ， 为主从架构的数据库提供高速读服务 ， 此点妙处 ， 论文没有点出 ， 这里权做推测 。 存储层如果能为所有的主备节点提供一致的缓冲数据 ， 则有更为积极的意义 ， 可以对比参考的如Oracle的RAC 。
而位于计算层内的“Caching” ， 是单个数据库实例读数据的场所 ， 独立使用 。


推荐阅读


上一篇：|中国幸福感排名又下滑7位，为啥经济越发展，国人幸福感越差？

下一篇：引领先锋|金立K3Pro发布，1600万单摄+10W，起售价699元