搜狐首页 科技 法医秦明

手机搜狐

SOHU.COM

一文掌握云数据库现状与前沿技术

「一切都会运行在云端」。现在越来越多的业务从自己维护基础设施转移到公有(或者私有)云上,带来的好处也是无需赘述的,极大降低了IaaS层的运维成本,对于数据库层面来说的,以往需要很强的DBA背景才能搞定弹性扩容高可用什么的高级动作,现在大多数云服务基本都或多或少提供了类似的服务。

今天的分享主要集中在比较顶尖的云服务商的云数据库方案背后的架构,以及我最近观察到的一些对于云数据库有意义的工业界的相关技术的进展。

Amazon RDS

其实说到公有云上的云数据库,应该最早 Amazon 的 RDS,最早应该是在 2009 年发布的,Amazon RDS 的架构类似在底层的数据库上构建了一个中间层(从架构上来看,阿里云 RDS,UCloud RDS 等其他云的 RDS 服务基本是大同小异,比拼的是功能多样性和实现的细节),这个中间层负责路由客户端的 SQL 请求发往实际的数据库存储节点,因为将业务端的请求通过中间层代理,所以可以对底层的数据库实例进行很多运维工作,比如备份,迁移到磁盘更大或者 IO 更空闲的物理机等,这些工作因为隐藏在中间层后边,业务层可以做到基本没有感知,另外这个中间路由层基本只是简单的转发请求,所以底层可以连接各种类型的数据库。

所以一般来说,RDS 基本都会支持 MySQL / SQLServer / MariaDB / PostgreSQL 等流行的数据库,对兼容性基本没有损失,而且在这个 Proxy 层设计良好的情况下,对性能的损失是比较小的,另外有一层中间层隔离底层的资源池,对于资源的利用和调度上可以做不少事情,比如简单举个例子,比如有一些不那么活跃的 RDS 实例可以调度在一起共用物理机,比如需要在线扩容只需要将副本建立在更大磁盘的机器上,在 Proxy 层将请求重新定向即可,比如定期的数据备份可以放到 S3 上,这些一切都对用户可以做到透明。

但是这样的架构缺点也同样明显:本质上还是一个单机主从的架构,对于超过最大配置物理机的容量,CPU 负载,IO 的场景就束手无策了,随着很多业务的数据量并发量的增长,尤其是移动互联网的发展,无限的可扩展性成为了一个很重要需求。当然对于绝大多数数据量要求没那么大,单实例没有高并发访问的库来说,RDS 仍然是很适合的。

Amazon DynamoDB

对于刚才提到的水平扩展问题,一些用户实在痛的不行,甚至能接受放弃掉关系模型和 SQL,比如一些互联网应用业务模型比较简单,但是并发量和数据量巨大,应对这种情况,Amazon 开发了 DynamoDB,并于 2012 年初发布 DynamoDB 的云服务,其实 Dynamo 的论文早在 2007 年就在 SOSP 发表,这篇有历史意义的论文直接引爆了 NoSQL 运动,让大家觉得原来数据库还能这么搞,关于 DynamoDB 的模型和一些技术细节,我在我另一篇文章《开源数据库现状》提过,这里就不赘述了。

精选