读书记录
白马居士
半路出家的程序猿
展开
-
Design Data-Intensive Applications 读书笔记二十九 第九章:分布式事务,2PC
分布式事务和一致性一致性是分布式计算中最重要的一个问题。通俗来说,它的目标就是让多个节点对于某件事达成共识。这并不容易。有几个重要场景,需要节点达成一致:主节点选举:在单主节点备份中,所有的节点需要关于谁是主节点达成一致。节点的领导权可能因为网络问题而产生竞争。这种情况下,一致性对于避免错误的故障转移导致脑裂(两个节点都认为自己是主节点)的场景很重要。如果有两个主节点,它们都会接受写入,它们的数据会产生分歧,导致不一致和数据丢失。原子提交:在支持事务的多节点或者多分区的数据库中,我们要面对一原创 2020-08-16 14:17:44 · 150 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十八 第九章:顺序保障
顺序保障排序是本书中一再提及的问题。排序,线性化和一致性关联很深排序与因果排序的一个很重要的原因就是它能帮助维持因果。例如:1、“一致性前缀”读取中,用户可能先看到答案,再看到提问,这不符合因果逻辑。2、多主节点备份中,可能因为网络延迟,旧的写入会覆盖掉新的写入。因果规定了事件发生的顺序:原因先于结果,消息先发送,然后才收到;先提出问题,再回答问题。如果系统的排序遵从因果,那么称之为因果一致。因果排序不是全序全序意味着集合中任意两个元素都可以了拿来比较。线性化..原创 2020-08-16 14:15:32 · 275 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十七 第九章:线性系统和其代价
实现线性一致性(线性化)线性一致性就是像“只有一个数据库节点”。使用单一节点是一个方法,但是单一节点的方案不能容错。为了容错,需要使用备份。之前讨论过几种备份方案,看看它们是否能线性化。1、单主节点备份(潜在线性化)使用单主节点备份的系统,所有的写入首先会发送至主节点,然后会备份至从节点。如果从主节点读取或者是同步更新的节点读取,那么天然就是线性的。但是如果主节点出现故障,进行故障转移,那么新的主节点可能丢失最近的写入,这违背了持久化和线性化。2、共识算法(线性化)共识算法类似单主节点备原创 2020-08-16 14:13:32 · 230 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十六 第九章:一致性保障
第九章共识和一致性这章讨论一些算法来构建稳健的分布式系统。讨论时我们认为第8章讨论的问题都会发生:网络会丢包,会重复订阅,会有冗余值,网络延迟不确定;时钟大概近似;节点任何时候都可能暂停或者故障。构建这类系统的最好方法就是找到一些系统保障的抽象模型,然后实现它们,让应用依赖这些保障模型。分布式系统最重要的一个抽象就是“共识”consensus,即所有节点都认同一件事。在网络错误和进程故障的情况下,要实现共识是件很难的事情。一旦实现了共识,应用就能做到很多事情。比如在单一主节点的分布式数据库中,.原创 2020-07-26 18:34:12 · 160 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十五 第八章:信息、真相和谎言
信息、真相和谎言这章阐述分布式系统中的基本问题:我们能判断哪些事情的真假?我们如何确定信息,测量和感知是否可靠?软件是否会违背现实世界法则,起因和影响是什么?以及分布式系统中关于信息和真相的一些常识。事实由多数决定设想一个发生不对称的网络问题的场景:一个节点能够接受到其他节点的信息,但是其他节点没法收到它的信息,结果就是其他节点没有收到关于它的反馈,虽然该节点正常工作,但是系统只能认为它已经“死亡”。如果节点能够发现其他节点没有回应它所发送的信息,它可能意识到网络出了问题,可能意识.原创 2020-07-26 18:31:32 · 174 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十四 第八章:不可靠的时钟和进程停顿
不可靠的时钟系统中会用到时间段和时间点。两种用法:获取事件点和时间段。在分布式系统中,通信需要时间,因为延迟,难以知道分布式系统事件的发生顺序。而且机器都使用石英钟,不同节点多少存在不一致,这个不一致一般使用网络授时来解决。对应时钟的两种用法,有两种类型的计时方法,日期和计数。时钟同步和准确性计数时钟不需要授时,但是日期时钟需要,但是因为硬件的关系,时钟往往不准确。Google认为时钟偏移200ppm(一百万分之一),每30s就有6ms的偏移,一天有17s需要校准。使用授时系统也会.原创 2020-07-12 17:51:15 · 250 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十三 第八章:故障和不可靠的网络
分布式带来的问题之前的章节我们一直有讨论要怎么应对错误。例如我们讨论了故障转移,备份延迟,和事务的并发控制。我们看到了系统运营中的极端案例,以及要如何应对它们。但是现实是,我们还是过于乐观了。现实可能更糟糕。接下来我们会认为任何事情都会出错。使用分布式系统与单主机的系统基本的不同就是:引入了很多新东西,而且会出现很多错误。下面我们就来看看实际中会出现的问题。最后作为工程师,我们就是要会发生错误的情况下建立稳健的系统。这一章的视角全都是悲观的,任何事情都会出错。我们会看到网络问题,时钟问题。然后.原创 2020-06-27 11:32:49 · 277 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十二 第七章:两步加锁和SSI
两步加锁(2PL)之前30多年,数据库中只有一种序列化算法: two-phase locking,2PL,两步加锁。之前我们使用锁来防止脏写:如果两个事务同时写入相同对象,加锁会确保一个事务写入完成前,其他事务不会写入相同对象。两步加锁类似,但是锁更加严格。多个事务想同时读取相同对象,如果没有事务写入这个对象,那么同时读取时允许的。但是只要有任何事务想写入对象,那么就需要排他性:1...原创 2020-05-05 20:17:07 · 304 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十一 第七章:序列化执行
序列化我们之前看了并发会导致问题的场景,要解决并发问题前景很悲观。1、隔离等级很难理解,而且各数据库对此的标准不统一。2、编写应用代码时,很容易出现并发问题,因为很难知道哪里会出问题。3、没有好的工具来检测竞态条件。理论上使用统计有帮助,但是没有用于实践。这不是新问题,自上世界70年代就有的问题,但是解决方法也简单,就是序列化隔离。序列化隔离等级一般被认为是最高的隔离...原创 2020-05-05 20:15:22 · 291 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记二十 第七章:弱隔离等级
弱隔离等级如果两个事务没有触及到相同数据,那么他们可以安全地并行,因为它们没有依赖关系。并发问题(竞态条件)只在相同数据一个事务读,另一个事务写或者两个事务同时写入相同数据时才会发生。并发问题很难在测试中发现,因为那些问题只有在不走运的时候才会触发,但是那种时候很少出现并且很难复现。并发问题也很难归因,特别是在大型系统里面,你不知道那段代码就访问了数据库。在一个时间只有一个用户的情况下,应...原创 2020-05-05 20:13:20 · 303 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十九 第七章:事务的单对象和多对象操作
单对象和多对象操作总的来说,ACID中,原子性和隔离性描述了如果一个客户端在一个事务内做了多个写入,数据库该怎么做?原子性:如果在执行一系列写入过程中发生了错误,那么事务应该被中止,事务开始至出错时间点的写入都应该被丢弃。换句话说,客户端不需要担心中途出错,保证只有完成或者未完成。隔离性:并发执行事务不应该与其他交互。例如:如果一个事务做了多个写入,另一个事务应该看到所有写入或者看不到...原创 2020-05-05 20:10:32 · 325 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十八 第七章:事务,ACID
事务Transaction在实际使用中,很多事情会出错:1、数据库软件可能在任何时候出错(包括写入过程中)。2、应用可能在任何时候故障(包括在一些列操作过程中)。3、网络问题会终端应用和数据库,或者是数据库节点间的连接。4、多个客户端可能同时写入数据库,会互相覆盖写入值。5、客户端可能读取到无意义的数据,因为那是部分更新的值。6、客户端间的竞态条件可能会造成很多意外的...原创 2020-04-05 16:21:50 · 129 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十七 第六章:分区和第二索引
分区和第二索引我们目前讨论的分区方法都是基于键值数据结构,通过key确定数据存储的分区,通过key将读取写入请求转发至对应分区。如果在分区方法中包含第二索引,事情会变得更复杂。第二索引通常不是用来确定记录的,而是用来计算特定值的发生频次:如用户123的所有动作,所有红色汽车等。第二索引在关系型和文档数据库中都很常见。很多键值存储(HBase和Voldemort)避免第二索引,因为实现起来很...原创 2020-04-05 16:19:04 · 167 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十六 第六章:键值数据分区
分区上一章,我们讨论了备份,在多个节点上部署相同数据的备份,对于非常大的数据库或者查询量很高的数据库,这是不够的,这章我们来讨论分库,如何将数据划分成不同的部分 partitions,也叫分区sharding.一般而言,每一片数据(一行,一条记录,或者一个文档)都属于特定的一个分区。每个分区都是一个小数据库,同时数据库可以同时操纵多个分区。分区的最主要原因就是可扩展。不同的分区可以放在...原创 2020-03-22 15:23:06 · 213 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十五 第五章:无主节点备份
无主节点备份目前讨论的备份方法都基于这样一个想法,客户端将写入请求发送至一个节点,然后数据库系统将写入备份至其他节点;主节点决定了写入顺序。一些数据库系统采用了其他方法,允许所有节点接收客户端的写入,无主从节点之分,也就是无主节点。这个想法在关系型数据库时代几乎被遗忘。它曾经在Amazon用于内部的 Dynamo系统后流行过, Riak, Cassandra,和Voldemort这些无主...原创 2020-03-22 15:21:35 · 391 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十四 第五章:多主节点备份
多主节点备份目前我们只讨论了只有一个主节点的情况,所有的写入都要发送至主节点,如果客户端与主节点的通信发生问题,那么就无法写入数据至数据库。这是主从备份的一个主要缺点。主从备份的一个扩展就是让写入发送至不止一个节点。备份时,所有需要处理写入的节点都要将数据更改发送至其他节点。我们称之为 multi-leader,多主节点。这种情况下,每个节点都类似于其他节点的从节点。多主节点备份...原创 2020-03-07 20:38:42 · 243 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十三 第五章:主从备份和备份延迟产生的问题
主从备份每个存储一个数据库备份的节点称为replica,副本。有多个副本之后,一个问题无法避免:怎么保证数据都传送到了所有的副本上。数据库的每次写入都需要传递到每个副本;否则副本之间数据就会不同。最常见的解决方法就是lead-based replication,主从复制,如图:5-1,工作方式如下:1、一个副本设为主节点,当客户端写入数据库时,必须将请求发送至主节点,主节点会首先将数据...原创 2020-03-07 20:36:25 · 604 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十二 数据流模型
数据流模型在章节开头就说过,当你需要将数据传输到一个与你的进程没有共享内存的进程时,例如通过网络或者写入到文件时,你需要将数据编码为二进制序列。之前讨论了不同的编码方法。我们讨论了前向和后向兼容性,这对于演化性很重要(允许独立升级系统的一部分,不需要同时做出改变)。兼容性就是编码数据的进程和另一个解码数据进程之间的关系。接下来我们来看看进程间数据流动的最常见的几种方式。通过数据库,调用...原创 2020-02-07 09:07:25 · 337 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十一 编码数据的格式
第四章 编码和演化应用一直在改变。用户需求,商品上架等原因,应用一直在更新。第一章我们引入过“可进化性”,应用能易于改变。当应用的特性改变时,存储的数据一般也会要求改变,可能是添加新字段,也可能是改变展示方式。第二章的数据模型,我们讨论了如何应对数据的改变。关系型数据结构认定数据库中的数据都遵从特定的模式,即便是模式改变了,一个时间也只有一个特定的模式。“无模式”数据库不要求模式,所以...原创 2020-02-07 09:04:54 · 248 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记十 列存储
以列导向的存储如果你的事件数据库里有上万亿的行和PB级的数据,那么存储和查询是个很大的挑战。维度表通常很小(百万行),所以这一节首要讨论事件存储。尽管事件表格通常有上百列,但是数据仓库的查询通常一次只用4至5列。我们如何有效执行这种查询?在大多数的OLTP数据库中,存储是以行为导向(row-oriented)风格的,表中的行数据都是挨着存储的。文档数据库类似,整个文档一般是存储为连...原创 2020-01-12 10:11:43 · 300 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记九 事务处理或者分析
事务处理或者分析?早期商业数据处理过程,即应对商业事务的写入过程:完成交易,下订单,付薪水。随着数据库扩展到不包含金钱交换的领域,都会在事务这里卡住,即要求读取和写入形成一个逻辑单元。事务不需要满足ACID特性(原子性,一致性,隔离性,持久化)。事务过程只是意味着允许客户端执行低延迟的读取和写入,相对应的是定期运行的批量加工。即便数据库用于处理各种数据:博客评论,游戏等,基本的访问模式...原创 2020-01-05 11:18:28 · 208 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记八 其他索引结构
其他索引结构我们目前讨论的是键值索引,用于关系型数据库汇总的主键索引。一个主键唯一标志关系型数据库中的一行,或者是文档数据库中的一个文档,后正式图数据库中的一个顶点。一个记录可以通过主键来引用这一条记录。第二索引也是很常见的。在关系型数据库中,你可以在一张表格上创建多个第二索引,这对于执行join操作很有助益。第二索引可以使用键值索引来构建,主要的区别就是键可能不是唯一的,可能有多行(文档...原创 2019-12-29 11:09:40 · 84 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记五 索引结构:哈希表和LSM
第三章、存储和检索数据库最基础的两个功能:存储和返回数据。第二章我们讨论了数据模型和查询语句,即你存进数据库的数据格式以及你后来取出数据的原理。这章我们从相同的视角讨论数据库:我们如何存储数据,以及如何找到查询结果。我们开发应用时,不需要关系数据库如何存储和检索数据,但是你需要为应用选择合适的存储引擎,你需要理解引擎背后的工作原理。并且,事务优化的引擎和检索优化的引擎有很大不同,我们后...原创 2019-12-22 20:59:51 · 191 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记四 类图数据模型
类似图的数据模型早先我们看到多对多关系是区分不同数据结构的一个关键。如果你的应用绝大多数都是一对多关系,后者记录间没有关系,那么文档模型是合适的。但是如果你的数据中多对多关系很普遍呢?关系模型只能处理简单的多对多关系,对着数据的连接变得复杂,应该使用图表模型。一个图由两种东西组成:顶点(节点或者实体)和向量(关联或者轨迹)。很多类型的数据适用于用图结构建模。典型例子:社会网络:顶点...原创 2019-12-01 14:07:06 · 327 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记三 查询语句
数据查询语句引入关系模型的时候,它引入了一个新的查询数据的方法:SQL是一个声明式查询语言,IMS和CODASYL查询用的是命令式语言。一些常用的编程语言都是命令式的。在关系型语法汇总,你会这样写:命令式语言告诉电脑按顺序执行操作。你可以想象电脑按行遍历代码,计算条件,更新变量,决定是否继续循环。在声明式语言中,你只需要设定你想要的数据:什么条件能拿到结果,数据怎么传输(s...原创 2019-11-24 14:21:31 · 257 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记 二 数据模型
第二章 数据模型和查询语句数据模型或许是软件开发中最重要的部分,它们不仅规定了软件如何被编写,也影响了我们如何思考我们要解决的问题。绝大部分应用都是分层来构造数据模型,每一层的关键问题是:根据底层如何表示这一层?例如:1、作为应用开发者,你会查看现实世界(人,公司,货物,行动,现金流,感应器等等),然后将相关事物和数据结构建模。这些结构是你的应用特有的。2、当你想存储这些数据结...原创 2019-11-17 18:59:52 · 291 阅读 · 0 评论 -
Design Data-Intensive Applications 读书笔记 一
前言此系列文章主要翻译自书籍《Design Data-Intensive Application》。这本书的主要目的是探讨思考如何思考数据系统的方法,那些系统是如何设计的,为什么这么设计,以及其中解决的问题。现在数据是系统的核心,这本书可以帮助我们如何设计好的数据系统,也可以解答我们对其他数据系统如何设计的好奇。第一部分数据系统的基础第一章 可用、可扩展、可维护可靠性软件满足...原创 2019-11-10 08:49:18 · 1190 阅读 · 0 评论