云原生数据库:原理与实践
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

1.1.4 云原生与分布式时代

在云原生时代,数据库的处理能力如何随着业务处理规模增加而扩展,有两种不同的实践方法。一种方法是垂直扩展(Scale up),提升数据库各个组件的容量,使用更好的硬件,比如小型机、高端存储,如著名的“IOE”解决方案,数据库系统架构使用多个计算节点共享一份存储,称为Shared-Storage架构,如图1-1(a)所示。另一种方法是水平扩展(Scale out),还是保持原来单个数据库实例的容量不变,用更多的数据库节点组合为一个无共享(Shared-Nothing)分布式系统来解决问题,每个节点根据分布规则(Sharding Rule)存储一部分数据(Shard),处理一部分请求,如图1-1(b)所示。

图1-1 数据库的垂直扩展与水平扩展

两种方法各有利弊,前者本质上还是一个单机形态,所有计算节点共享所有状态、数据或元数据,基本上所有功能都可以和单机版保持兼容。对于很多传统企业来说,保证业务的平滑是很重要的,应用尽量不做改动,便能获得扩展功能,这种方式无疑是合适的。但是扩展性受限,计算节点不可能无限制地添加,计算节点越多,同步状态的代价越大,包括存储容量也受限于共享存储的能力。如此一来,对处理互联网业务的海量数据和请求来说就显得力不从心了。因此,大部分互联网企业更看重数据库扩展能力,自然选择了用廉价硬件水平扩展的方案,代价就是数据做了水平拆分。很多业务的查询和事务变成了跨数据分片或跨节点,复杂度和开销较大,因此大部分互联网业务可以通过选择拆分规则来避免。

互联网业务的快速发展带来的海量数据不仅对在线事务处理带来扩展性需求,也使数据分析的形态发生了变化。21世纪初期,Google发表了著名的“三驾马车”:分布式文件系统(Google File System)、分布式表格(BigTable)和分布式计算模型(MapReduce),催生了大数据的概念。随后,开源社区积极跟进,实现了以Hadoop生态为主体的开源大数据处理技术体系,成为业界的事实标准。自2006年以来,对于大数据处理究竟是Hadoop体系更好还是传统的数据仓库技术路线更好,一直都是争论的热点。然而,无论选择哪种技术路线,“更简单的使用模式、更强劲的性能体验、更大的数据处理规模、更实时的处理能力”一直都是学术界和工业界研究的热点。随着时间的推移,以Hadoop为代表的大数据生态和以传统数据仓库为代表的数据库生态,在大数据领域正在逐渐向彼此靠拢。“SQL on Hadoop”成为大数据领域一个非常重要的研究方向,而数据库也逐渐向“数据库的体验,大数据的能力”方向发展,SQL逐渐成为被统一接受的通用查询分析语言。

进入21世纪以来,随着信息技术的不断发展,产生的数据越来越多,种类也越来越丰富,传统关系数据库的关系模型是严格的结构化数据,在处理频繁变化的业务和一些专用的特殊结构时殊为不便。一些使用更灵活的数据模型定义(Schemaless)或特殊的数据模型的数据库出现了,统称为NoSQL系统。NoSQL数据库主要包括键值(Key-Value,KV)数据库、文档(Document)数据库、图(Graph)数据库三大类。键值数据库的代表为Redis、HBase和Canssandra;文档数据库的代表为MongoDB;图数据库的代表为Neo4j等。这些数据库都是为了满足某些特定的要求,而在一些技术细节上做了取舍,满足特定场景下数据规模、灵活性、并发或性能的极致要求。在特定的场景下,NoSQL比关系数据库具有更优异的表现,包括性能、可扩展性、可用性及性价比等,然而关系数据库依然凭借SQL强大的表达能力、普适成熟的规范和完整严格的ACID语义牢牢占据主流。

进入21世纪20年代,云计算渐成规模,各大云厂商也纷纷推出了自己的数据库服务,传统的数据库厂商也纷纷试水云计算领域,推出基于云形态的数据库产品。数据库自此进入云时代,开启了新一轮波澜壮阔的变革之旅。