淘宝海量数据库之二:一致性选择

简介:

众所周知,一致性是数据最关键的属性之一。2000年,Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论:

Brewer, E. A. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon)

即分布式系统不可能满足一致性(C: Consistency),可用性(A: Availability)和分区容错性(P: Tolerance of network Partition)这三个需求。

 

大约两年后,Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性:

Gilbert , S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2)

 

几种常见的一致性类型有:

  • 强一致性:系统中的某个数据被成功更新(事务成功返回)后,后续任何对该数据的读取操作都得到更新后的值。这是传统关系数据库提供的一致性模型,也是关系数据库深受人们喜爱的原因之一。
  • 弱一致性:系统中的某个数据被更新后,后续对该数据的读取操作得到的不一定是更新后的值,这种情况下通常有个“不一致性时间窗口”(inconsistency window)存在:即数据更新完成后在经过这个“不一致性时间窗口”,后续读取操作就能够得到更新后的值。
  • 最终一致性:属于弱一致性的一种,即某个数据被更新后,如果该数据后续没有被再次更新,那么最终所有的读取操作都会返回更新后的值。

关于最终一致性,Werner Vogels提出了NWR模型(Eventually Consistent - Revisited, By Werner Vogels on December 23, 2008 12:15 AM,   http://www.allthingsdistributed.com/2008/12/eventually_consistent.html):

  • N:数据复制的份数(the number of nodes that store replicas of the data)
  • W:数据更新完成前需要到达的节点数(the number of replicas that need to acknowledge the receipt of the update before the update completes)
  • R:为了读取正确数据需要读取的节点数(the number of replicas that are contacted when a data object is accessed through a read operation)

Werner Vogels还写到,如果W+R > N,那么读写节点有重叠,读总是能够得到最新的数据,这就是强一致性。在传统的一主一备同步复制的关系数据库中,N=2,W=2,R=1;在非同步复制模型中,W变成1,此时W+R=N,一致性也就无法保证。

 

不过,NWR模型只代表了一类情形,例如,在传统的一主一备的非同步复制的关系数据库中,尽管N=2,W=1,R=1,如果只有主库提供服务,则一致性仍然是保证的,不过主机异常时,服务的恢复不是实时的,因此CAP理论依然适用。

 

在调研中,我们发现一些项目正在或倾向于弱一致性或最终一致性,咋看这似乎表明这些工程师偏爱弱一致性或最终一致性。然而,在经过仔细沟通和深入分析后,我们发现,这些项目采用弱一致性或最终一致性,其实是在高数据量(十几亿条记录、数TB数据)和高访问量(数千TPS、数万QPS)需求压力之下的无奈选择。如果两个系统都能满足上述高数据量和高访问量需求且成本差异不是很大,那么在强一致性和若一致性(或最终一致性)两者中他们会毫不犹豫地选择前者。

 

显而易见,作为整个系统中最为基础的部件,如果数据库的数据是弱一致,那么上层应用就不得不承受这种弱一致导致的种种后果,从上层应用的角度看,这并不是十分友善的行为。由于上述原因,我们决心在我们的海量数据库中实现与传统关系数据库相同的强一致性,因为我们相信这种强一致性不仅会简化数据库的管理,减轻数据库管理的工作量,尤其重要的是,上层应用不再需要关注数据的不一致性,应用程序也会因此而简化,并且易于开发和维护。

目录
相关文章
|
JSON API 数据库
商城系统数据源 requests 淘宝商品数据库 API 接口
这些信息包括标题、价格、描述、图片等等。介绍如何对接淘宝详情API接口,并提供一些示例代码来帮助你开始
|
SQL 存储 NoSQL
淘宝数据库OceanBase SQL编译器部分 源码阅读--Schema模式
淘宝数据库OceanBase SQL编译器部分 源码阅读--Schema模式 什么是Database,什么是Schema,什么是Table,什么是列,什么是行,什么是User?我们可以可以把Database看作是一个大仓库,仓库分了很多很多的房间,Schema就是其中的房间,一个Schema代表一个房间,Table可以看作是每个Schema中的柜子,行和列就是柜子
1871 0
|
SQL 数据库 OceanBase
淘宝数据库OceanBase SQL编译器部分 源码阅读--生成物理查询计划
SQL编译解析三部曲分为:构建语法树,制定逻辑计划,生成物理执行计划。前两个步骤请参见我的博客<<淘宝数据库OceanBase SQL编译器部分 源码阅读--解析SQL语法树>>和<<淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划>>.这篇博客主要研究第三步,生成物理查询计划。 一、 什么是
1781 0
|
SQL 存储 数据库
淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划
淘宝数据库OceanBase SQL编译器部分 源码阅读--生成逻辑计划 SQL编译解析三部曲分为:构建语法树,生成逻辑计划,指定物理执行计划。第一步骤,在我的上一篇博客淘宝数据库OceanBase SQL编译器部分 源码阅读--解析SQL语法树里做了介绍,这篇博客主要研究第二步,生成逻辑计划。 一、 什么是逻辑计划? 我们已经知道,语法树就是一个树状的结
1457 0
|
SQL 关系型数据库 数据库
淘宝数据库OceanBase SQL编译器部分 源码阅读--解析SQL语法树
OceanBase是阿里巴巴集团自主研发的可扩展的关系型数据库,实现了跨行跨表的事务,支持数千亿条记录、数百TB数据上的SQL操作。在阿里巴巴集团下,OceanBase数据库支持了多个重要业务的数据存储,包括收藏夹、直通车报表、天猫评价等。截止到2013年4月份,OceanBase线上业务的数据量已经超过一千亿条。 看起来挺厉害的,今天我们来研究下它的源代码。关于
3067 0
|
24天前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
1天前
|
SQL 关系型数据库 MySQL