数据库 on 韩永发的博客

读《设计数据密集型应用系统》（第二版）有感-第二部分：分布式数据系统

Thu, 09 Apr 2026 00:00:00 +0000

第二部分：分布式数据系统

第五章、数据复制

通过网络在多台机器上保存相同的副本。

多副本的目的

使数据在地理位置上更接近用户，从而降低访问延迟。（CDN）
当部分组件出现故障，系统依然可以继续工作，从而提高可用性。（高可用，主从）
扩展至多台机器以同时提供数据访问服务，从而提高读吞量。（负载均衡，分布式）

主从复制

指定某一个副本为主副本（或称为主节点）。当客户写数据库时，必须将写请求首先发送给主副本，主副本首先将新数据写入本地存储。
其他副本则全部称为从副本（或称为从节点）。主副本把新数据写入本地存储后，然后将数据更改作为复制的日志或更改流发送给所有从副本。每个从副本获得更改日志之后将其应用到本地，且严格保持与主副本相同的写入顺序。
客户端从数据库中读数据时，可以在主副本或者从副本上执行查询。再次强调，只有主副本才可以接受写请求;从客户端的角度来看，从副本都是只读的。

同步和异步

同步和异步的区别在于主节点是否需要等待从节点返回成功后才算成功。

同步的优点：从节点的数据是完整的，从节点随时可以作为一个可靠的节点来读取数据或者替换主节点。
同步的缺点：虽然节点之间复制速度特别快，但只要从节点的一环出现错误，就会导致任务失败。如果同步的从节点过多，会让故障的概率指数级增加。
半同步：一个主节点，一个同步从节点，多个异步的从节点。如果同步的从节点出现问题，则将一个异步的从节点升级成为同步从节点。主节点出现问题，用同步从节点替换主节点。

配置新的从节点

当添加新的从节点后，如何保证新从节点和主节点之间数据的一致性。

如何在不停机的情况下，保证新节点的数据追平主节点（逻辑同样可以用来做数据库迁移）

在某个时间点，对主节点产出一个数据一致性快照，这样可以避免长时间锁定数据库。（MySQL的innobackupex）
将此快照拷贝到新的从节点。
从节点连接主节点并只请求快照点后所发生的数据修改日志（binlog）。
获取日之后，从节点追平主节点数据。

处理失效的节点

即使某个节点中断，也要保证系统总体的持续运行。高可用

从节点失效：追赶恢复数据

根据从节点数据日志情况，与主从复制日志情况，进行数据追赶。

主节点失效：节点切换

需要将某个从节点提升为主节点，同时客户端更新到新的主节点

确认主节点确实已失效。
确认新的主节点。可能需要多数节点达成共识，或者手动选择最接近主节点数据的从节点。让所有从节点同意新的主节点。
配置应用使用新的主节点。（写请求都到新的主节点）确保旧主节点已降级成从节点，且同意新的主节点。

主从切换时可能出现的一些问题：

异步复制，新的主节点可能没有收到所有旧主节点的数据；选举后，旧主节点又很快上线，出现旧主节点（现在的从节点）数据超过新主节点。

旧主节点未完成复制的数据丢弃掉。（会导致一部分数据丢失，违背数据持久化概念）所以应该尽量保证主节点提交的数据可以被全量同步。

如果程序依赖数据库的数据来生成主键，将直接导致业务系统出现问题。所以最好还是要保证有同步数据库。

超时时间设计的过短：可能导致不必要的主从切换。

应该尽量保持平衡，但其实也没有一个固定的解决方案。所以有些系统为了保证可靠，主从切换还是由运维手动操作。

复制日志的实现

基于语句的复制

主节点把所有写请求，都当做日志发送给从节点。（aof和增量binlog）

任何非确定性的函数调用（now，随机数等）
如何使用了自增id，必须保证所有库的自增键相同

可以把主节点执行后的结果当成转换成写语句同步给从库。

基于预写日志（WAL）传输

多数数据库都是基于WAL来做数据更新的，完全可以利用WAL，来向从库同步WAL，这样可以做到相同的写入操作。

WAL受限于存储引擎，如果不同的存储引擎（和版本号），采用的WAL将完全不同。（无法实现热升级，如果需要升级数据库版本，需要停机）

基于行的逻辑日志复制

通过自定义的逻辑日志来进行复制

新增：日志包含所有相关的列新值

删除：通过唯一标识来生成删除日志。

更新：通过唯一标识和需要更新的新列值来生成更新日志。

基于触发器的复制

不使用数据库本身，通过第三方工具（触发器）来实现复制。（canel：思想相同，不过实现采用的伪装成数据库从库）

Oracle的Databus、Postgres的Bucardo

通常开销更高，也容易出错，但非常灵活。

复制滞后问题

主从复制要求所有写请求都经由主节点，而任何副本只能接受只读查询。如果一个应用正好从一个异步的从节点读取数据，而该副本落后于主节点，则应用可能会读到过期的信息。如果同时向主节点和从节点发起查询请求，可能会查到不同的值。

主要涉及讨论对于各种复制滞后的问题应该如何解决

读取自己写入的数据（读写请求一致性）

用户提交一些信息，然后查看自己刚刚提交的内容。由于主从复制滞后问题导致读取的内容不一致。

读写请求一致性：如果用户重新加载页面，总是能看到自己最近提交的更新。（其他用户读取此信息不保证最新）下面是几种实现方式

总是从主节点读取自己的配置信息，对于他人的配置信息从从节点读取。
跟踪用户的更新请求，如果最近一分钟提交了更新操作，则从主库读取，否则从库。
客户端本地记录最后一次更新的时间戳，保证查询的信息至少晚于或等于本地记录的时间戳。（这些请求不一定是从主库查询的，可以在多个从库之间轮询，直到查到满足条件的信息）可能由于不可靠的时钟出错
如果有多个数据中心，必须把用户请求路由到主节点所在的数据中心

单调读（读一致性）

第一次读取的数据与第二次读取的数据不同。比强一致性弱，比最终一致性强的保证

如果某个用户依次进行多次读取，则他绝不会看到回滚现象，即在读取较新值之后又发生读旧值的情况。

确保同一个用户每次都从同一个副本查询，而不是每次请求都随机路由。（但如果被路由的节点失效，失效节点的所有用户都要重新分配）

前缀一致性读（happened-before）

对于存在因果关系的数据，必须要严格按照顺序复制。有点类似于jit需要保证乱序生成的代码，单线程结果一致性。（有序性）

微信聊天记录就存在这样的问题，产生这个情况的原因通常是：分布式写请求分片有多个，不能保证全集群写入顺序的一直。就会导致从分片读到完全乱序的情况。

所有具有因果关系的写请求都交给同一个分片来完成。（这样做效率会大打折扣）
可以用过一些happened-before算法来追踪因果关系。

多主节点复制

每个节点既扮演主节点，也同时扮演者其他主节点的从节点角色。

适用场景

多主模式逻辑复杂，在同一个数据中心内部使用没有意义，通过在多数据中心场景中使用。

多数据中心

为了容忍数据中心级别的故障，或者更接近用户，可以把数据库的副本横跨多个数据中心。

主从和多主之间的对比

场景	主从	多主
写性能	写请求必须传到主节点所在的数据中心。写入延迟高	写请求可以在自己最近的数据中心完成。然后把数据复制给其他数据中心
数据中心故障	如果主节点所在的数据中心发成故障，必须把另一个数据中心提升为主数据中心	每个数据中心独立运行，即使某个数据中心挂了也不影响其他数据中心
网络问题	对于同步的主从模式，需等待同步节点写完才能写入成功，需依赖数据中心之间的网络	每个数据中心之间异步通讯，只需要依赖数据中心本地的网络。

多主模式同样也带来了许多问题：

不同的数据中心可能会同时修改相同的数据，因而必须解决潜在的写冲突。
自增id问题：可能由于同步的不及时导致每个数据中心之间，相同数据自增id不同。（多数据中心不建议使用自增id）

离线客户端操作

应用在与网络断开后还需要继续工作

每个设备都有一个充当主节点的本地数据库（用来接受写请求）。

协作编辑

实时协作编辑应用程序允许多个用户同时编辑文档。（在线文档）

当一个用户编辑文档时，所做的更改会立即应用到本地副本，然后异步复制到服务器以及编辑同一文档的其他用户。

处理写冲突

如何避免冲突

通过应用层来指定特定记录的写请求总是通过同一个主节点，这样就不会发生冲突。（有点违背多主模式的冲突，变成了主从模式的变种）

收敛于一致状态

数据更新符合顺序性原则，即如果同一个字段有多个更新，则最后一个写操作将决定该字段的最终值。（可能会导致最终值的不确定性）

如何实现收敛一致

最大id：所有写请求分配一个唯一的id（时间戳+uuid）所有数据同步时，只保留id最大的数据（最终一致）
合并一致：让需合并的结果按照一定规则排序，只取序列最靠后的。
同2，应用自定义合并规则。

一些常见的自动解决并发修改冲突算法

无冲突的复制数据类型（ CRDT）：多个用户同时编写map、list等。
可合并的持久数据结构（Mergeable persistent data) ：类似git跟踪变更历史，三向合并。
操作转换（0perationaI transformation）：Etherpad和Google Docs等协作编辑应用背后的冲突解决算法。

复制的拓扑结构

不同拓扑结构对于容错、是否有中心、复制成本各有优缺点，这里就不展开说明了。

无主节点复制

放弃主节点，允许任何副本直接接受来自客户端的写请求。

节点失效时写入数据库

当节点失效时，用户不关心自己写入的节点是否发生变化，更不需要进行节点提权等操作。

用户向多个节点同时发起写请求，只有超过半数的节点写入成功，则此请求成功。

读修复：用户读取时决定值（通过半数以上的节点返回来确认值）
反熵：后台进程自动查找节点之间的差异并修复。

但上面的例子，如果有多个用户同时写入则可能出现如下问题：

处理并发写入

最后写入胜利法（last write wins）

由于每个客户端在写入时都不会互相感知，且由于网络关系，无法区分那个写入一定在哪个写入之后。

可以强制对所有的写入进行排序：

为所有写请求附加一个时间戳，然后选择最新即最大的时间戳，丢弃较早时间戳的写入。

以上思想，在zookeeper，raft，各种分布式一致性问题中都有借鉴。

happens-before关系和并发

happens-before：B的操作明确依赖A，具有先后关系

并发：A和B的操作“同时”，且完全独立的，互相不感知

为更好地定义并发性，我们并不依赖确切的发生时间，即不管物理的时机如何，如果两个操作并不需要意识到对方，我们即可声称它们是并发操作。

两个客户端同时多次向一个购物车中添加值，且相互不感知。

对于单个客户端，每次添加操作是有前后依赖关系的（happened-before），对于两个客户端之间，是“同时”发起的添加操作（并发）

服务器具体处理步骤如下：

服务器为每个主键维护一个版本号，当主键新值写入时，递增版本号，并将版本号和值一起保存。
当客户端读取主键时，服务器将返回所有（未被覆盖的）当前值以及最新的版本号。且要求写之前，客户必须先发送读请求。（读取最新值）
客户端写主键，写请求必须包含之前读到的版本号、读到的值和新值合并后的集合。写请求的响应可以像读操作一样，会返回所有当前值，这样就可以像购物车例子那样一步步链接起多个写入的值。
当服务器收到带有特定版本号的写入时，覆盖该版本号或更低版本的所有值（因为知道这些值已经被合并到新传入的值集合中），但必须保存更高版本号的所有值（因为这些值与当前的写操作属于并发）。

整体逻辑有点像kafka集群的值是否写入成功逻辑，如果同步指针追上了的值，才算写入成功。这里只不过是相反的，每次写入都删除当前写入依赖版本号之前的所有版本。（算是MVCC的一种体现）

有依赖关系的值可以覆盖，并发的值需保存多份。可以保证并发写入的数据不会丢失

第六章、数据分区

分区通常与复制结合使用，即每个分区在多个节点都存有副本。这意味着某条记录属于特定的分区，而同样的内容会保存在不同的节点上以提高系统的容错性。

键-值数据的分区（常见的分区方式）

分区的主要目标是将数据和查询负载均匀分布在所有节点上。如果节点平均分担负载，那么理论上10个节点应该能够处理10倍的数据量10倍于单个节点的读写吞吐量。

基于关键字分区

为每个分区分配一段连续的关键字或者关键字区间范围。

每个分区可以按照关键字排序保存（LSM-Trees）。这样可以轻松的支持区间查询。

缺点：某些访问模式会导致热点。如果数据按照每天一个分区，每天所有的写入都会在同一哥分区，会导致单个分区负载过高，其他分区一直处于空闲状态。

基于关键字hash值进行分区

一个好的hash函数可以处理数据倾斜并使其均匀分布。

基于一致性hash的分区方式，可以进行高效的查询，但是却使数据丧失了有序性。

有些数据库采用hash分区的数据库直接禁用范围查询、或者把查询语句发送到所有的分区上。

Cassandra的折中方案

声明一个由多列组成的符合主键。多列主键的第一部分用于hash分区，其他列用于对sstable的排序。（可以支持对于其他部分的区间查询）

负载倾斜和热点

基于hash的方法可以减轻热点，但无法做到完全避免热点。一个极端的情况是所有的读/写操作都针对同一个关键字，最终所有的请求都会被路由到同一个分区。

在社交媒体网站上，一个名人发布了热点事件，出现了大量相同关键字的写操作。此时hash起不到任何帮助，相同id的hash值相同。

一种无奈的解决方案

如果某个关键字被认定为热点，就在关键字的开头或者结尾添加一个随机数。只需一个两位数的十进制随机数就可以将关键字的写操作分布到 100 个不同的关键字上，从而分配到不同的分区上。

缺点：但之后所有的读操作都需要额外的工作，必须从所有100个关键字中读取数据然后进行合并。因此通常只对少量关键字做随机数才有意义。

分区和二级索引

二级索引通常不能唯一标记一条数据，而是用来加速特定值的查询。

二级索引不能规整的映射到分区中。

基于文档分区的二级索引

每个分区完全独立，各自维护自己的二级索引，且只负责自己分区内的文档而不关心其他分区中的数据。文档分区索引也被称为本地索引，而不是全局索引。

二级索引的查询

如果想要查询特定颜色的车使用二级索引，需要将查询发送的所有的分区，然后合并所有返回结果。（可以采用并行查询）

基于词条的二级索引分区

对所有的数据构建全局索引，而不是每个分区维护自己的本地索引。为了避免成为瓶颈，不能将全局索引存储在一个节点上，否则就破坏了设计分区均衡的目标。全局索引也必须进行分区，且可以使用与数据关键字不同的分区策略。

优点：查询足够高效，且不需要把查询分配给所有分区然后聚合，客户只需要向包含词条的分区发送读请求。

缺点：写入速度较慢且非常复杂，单个文档更新时，里面可能会涉及多个二级索引，二级索引的分区又可能完全不同甚至完全在不同的节点上，会引入显著的写放大。

由于二级索更新需要一个跨多个相关分区的分布式事务支持，写入速度极慢。因此大部分数据库都不支持同步更新二级索引。对全局二级索引的更新往往是异步的。

分区再平衡

当增加节点时，如何将之前的数据进行再平衡。

分区再平衡想要达到的效果

平衡之后，负载、数据存储、读写请求等应该在集群范围更均匀地分布。
再平衡执行过程中，数据库应该可继续正常提供读写服务。
避免不必要的负载迁移，以加快动态再平衡，井尽量减少网络和磁盘IO影响。

动态再平衡策略

为什么不推荐使用取模

如果频繁的增加节点，会导致大量的数据频繁的迁移，大大增加了再平衡的成本。

固定数量的分区

创建远超实际节点数的分区数，然后为每个节点分配多个分区。
如果集群中增加了一个新节点，该新节点可以从每个分区上匀走几个分区，直到分区再次达到全局平衡。
被选中的整个分区会在映射节点之间迁移，但分区的总数量仍然维持不变，也不会改变关键字到分区的映射关系。（不需要像取模一样对每个key重新计算分区值）
唯一需要调整的是分区与节点的对应关系。调整可以逐步动态完成。在此期间，旧的分区仍然可以接收读取请求。

动态分区

当一个分区的数据量增长超过一个阈值，就会被拆分成两个分区，每个承担一半数据量。

如果大量数据被删除，且分区缩小到某个阈值，则将其相邻的分区合并。

HBase 通过HDFS分布式文件系统来实现分区文件的传输

按节点比例分区

使分区数与集群节点数量成正比，每个节点都有固定数量的分区。当节点数不变，每个分区的大小与数据集大小保持正比的增长关系；当节点数量增加，分区则会变小。大量的数据需要大量的节点来存储，这种方式可以使每个分区大小保持稳定。

请求路由

当客户端发送请求是，如何知道应该连接哪个节点？其实就是一个服务发现问题。

几种常见的路由策略

客户端连接任意节点，有节点把这个请求转发到正确的节点，再返回给客户端。（redis）
将所有客户端的请求都发送到一个路由层，路由层负责把请求转发到对应的分区节点上。路由层本身不处理请求，只负责负载均衡。（nginx）
客户端感知分区和节点关系。客户端可以直接连接到目标节点，而不需要其他中介。（springcloud注册中心的做法）

做出路由的组件，需要知道分区和节点的关系，以及变化情况。

大部分数据系统通过zookeeper来维护分区和节点的映射关系。一旦分区发生变化，zookeeper主动通知路由层来保持最新状态。

关于IP地址的变化，可以借助机器自己的DNS就可以了。

并行查询执行

查询优化器会把复杂的查询分解成许多执行阶段和分区，以便在集群的不同节点上并行执行。尤其是涉及全表扫描的查询操作，可以通过并行执行获益颇多。

第七章、事务

深入理解事务

ACID的含义

我之前多次记录过关于ACID的文章，对于ACID等详细说明推荐看我在凤凰架构里记录的文章。

不符合ACID的系统被称为BASE，基本可用（Basically Available），软状态（Soft state）和最终一致性（Eventual consistency)。

原子性

多线程编程中，如果某线程执行了原子操作，这意味着其他线程是无法看到该操作的中间结果。只能处于操作前和操作后的状态，而不是两者之间。

在ACID中，多线程访问相同变量是由隔离性来保证的

ACID的原子性：在出错时中止事务，并将部分完成的写入全部丢弃。（可随意中止性，从而达到可重试的目的。）

一致性

ACID的一致性：对数据有特定的预期状态，任何数据更改必须满足这些状态约束（或者恒等条件）。（贷款系统中，贷款余额应和借款余额保持平衡。）

原子性，隔离性和持久性是数据库自身的属性，而ACID 中的一致性更多是应用层的属性。

应用程序可能借助数据库提供的原子性和隔离性，以达到一致性，但一致性本身并不拥于数据库。

字母其实并不应该属于ACID

隔离性

ACID的隔离性：并发执行的多个事务相互隔离，它们不能互相交叉。

相互交叉其实有两个表现，下面是mysql对于两个场景的措施

读取：查询到其他事务可能在使用的变量。（通过MVCC快照读这种弱隔离性来实现）
修改：修改相同的变量（通过锁机制，保证一个变量无法被两个线程修改）

持久性

对于单机程序，持久性表示数据已经写入了非易失的存储设备（如硬盘）

对于支持远程复制的数据库，持久性意味着数据已成功复制到多个节点。

数据库必须等到这些写入或者复制完成之后才能报告事务成功提交。

弱隔离级别

关于mysql不同隔离级别的实现，已经不同级别的锁实现可以看我的这篇文章。

隔离是假装没有发生并发，可串行化隔离意味着数据库保证事务的最终执行结果与串行执行结果相同。

可串行化会严重影响性能，而许多数据库却不愿意牺牲性能，因此更多倾向于采用较弱的隔离级别。它可以防止某些但并非全部的并发问题。

读-提交

读数据库时，只能看到已成功提交的数据（防止脏读）
写数据库时，只会覆盖已成功提交的数据（防止脏写）

防止脏读

脏读：一个事务看到另一个事务尚未提交的内容。

如果事务需要更新多个对象，脏读意味着另一个事务可能会看到部分更新，而非全部。

如果事务发生中止，则所有写入操作都需要回滚。

防止脏写

脏写：两个事务同时修改相同的值，一个事务把另一个事务未提交的值修改了。

读已提交解决脏写的方式是一个事务等待另一个事务提交后，才能修改另一个事务已经修改了的值。（利用锁）

如果事务需要更新多个对象，脏写会带来非预期的错误结果。

多事务的不同写入顺序导致结果不一致。

实现读-提交

防止脏写：

数据库通常采用行级锁来防止脏写：当事务想修改某个对象（例如行或文档）时，它必须首先获得该对象的锁；然后一直持有锁直到事务提交（或中止）。如果有另一个事务尝试更新同一个对象，则必须等待。

防止脏读：

不能利用锁来解决脏读，因为长时间的写事务会导致许多只读的事务等待太长时间，任何局部的写入都会扩散进而影响整个应用。

对于每个待更新的对象，数据库都会维护其旧值和当前持锁事务将要设置的新值两个版本。在事务提交之前，所有其他读操作都读取旧值；仅当写事务提交之后，才会切换到读取新值。

快照级别隔离与可重复度

读《设计数据密集型应用系统》（第二版）有感-第一部分：数据系统基础

Wed, 18 Mar 2026 00:00:00 +0000

第一部分、数据系统基础

第一章：可靠、可扩展与可维护的应用系统

当今许多新型应用都属于数据密集型，而不是计算密集型。对于这些类型应用， CPU的处理能力往往不是第一限制性因素，关键在于数据量、数据的复杂度及数据的快速多变性。

常见的数据系统模块

数据库：用以存储数据，这样之后应用可以再次面问。
高速缓存：缓存那些复杂或操作代价昂贵的结果，以加快下一次访问。
索引：用户可以按关键字搜索数据井支持各种过滤。
流式处理：持续发送消息至另一个进程，处理采用异步方式。
批处理：定期处理大量的累积数据。

一个常见的数据系统，往往有多个模块组成，各自负责不同的工作。

可靠性

当出现意外情况如硬件、软件故障、人为失误等，系统应可以继续正常运转：虽然性能可能有所降低，但确保功能正确。

什么是一个可靠的应用？

应用程序执行用户所期望的功能。
可以容忍用户出现错误或者不正确的软件使用方法。
性能可以应对典型场景、合理负载压力和数据量。
系统可防止任何未经授权的访问和滥用。

硬件故障

硬盘崩溃，内存故障，电网停电，甚至有人误拔掉了网线。

传统防止硬件故障的方式：

磁盘配置 RAID，服务器配备双电源，甚至热插拔CPU，数据中心添加备用电源、发电机等。

当一个组件发生故障，元余组件可以快速接管，之后再更换失效的组件。

现代硬件容错

随着数据量和应用计算需求的增加，现代应用运行在大规模机器上，随之而来的硬件故障率呈线性增长。

依靠传动办法以难以应对故障发生的频率，故而需要使用软件来做容错。

如当需要重启计算机时为操作系统打安全补丁，可以每次给一个节点打补丁然后重启，而不需要同时下线整个系统（滚动升级）

软件错误

常见的软件错误

一个应用进程使用了某些共享资源如CPU、内存、磁盘或网络带宽，但却不幸失控跑飞了。
系统依赖于某些服务，但该服务突然变慢，甚至无响应或者开始返回异常的响应。
级联故障，其中某个组件的小故障触发另一个组件故障，进而引发更多的系统问题。

软件bug通常会长时间处于引而不发的状态，知道碰到特定条件才会触发。

软件错误有时没有快速的解决办法，只能仔细考虑更多的细节，认真检查依赖的假设条件与系统之间交互，进行全面的测试，进程隔离，允许进程崩溃并自动重启，反复评估，监控并分析生产环节的行为表现等。

人为失误

人无法做到万无一失。人是不可靠的，那么该如何保证系统的可靠性呢？

以最小出错的方式来设计系统（接口最小依赖，单一职责）

精心设计的抽象层，API以及管理界面，使“做正确的事情”很轻松，搞破坏很难。

想办法分离容易出错的地方（灰度环境）

提供一个功能齐全但非生产用的沙箱环境，使人们可以放心的尝试、体验，包括导人真实的数据，万一出现问题，不会影响真实用户。

充分测试（自动化全面测试）

从各单元测试到全系统集成测试以及手动测试。

当人为出现错误时，提供快速恢复机制尽量减少故障影响（小范围发布和回滚）

快速回滚配置改动，滚动发布新代码，并提供校验数据的工具。

详细的监控（链路追踪）

包括性能指标和错误率。链路追踪等。

推行管理流程并培训

重要且复杂。

可扩展性

随着规模的增长，例如数据量、流量或复杂性，系统应以合理的方式来匹配这种增长。

系统现在工作可靠，并不意味着它将来一定能够可靠运行。

如何描述负载

按“扇出”来描述

多个明星发布消息（生产者）

这些消息被推送给更多的用户（消费者）

每个用户维护一个时间线缓存。当有人发布新tweet，查询其关注者，将tweet插入到每个关注者的时间线缓存中。（推送效率随着关注者数量线性增长）

对于大V，让用户采用主动拉取的方式。

所谓的负载，应当为可线性描述。

描述性能

批处理系统中，通常关心吞吐量，每秒可处理的记录条数，某个指定数据集运行作业需要的总时间。

现在系统通常看中服务的响应时间，客户端从发送请求到接收响应之间的间隔。

**产生延迟的原因：**上下文切换和进程调度、网络数据包丢失和TCP重传、垃圾回收暂停、缺页中断和磁盘I/O，甚至服务器机架的机械振动。

中位数指标：一半用户的请求延迟低于此指标，另一则大于，可以很好的反映总体延迟情况。
P999：有99.9%的请求响应时间快于阈值。这将直接影响用户的总体服务体验。（亚马逊，响应时间每增加100ms，销售额就下降1%）

应对负载增加的方法

当负载增加时，应该如何保证良好性能？

针对特定级别设计的架构，不太可能应付超出预设目标10倍的实际负载。

因此，负载增加时，应在在垂直扩展（即升级到更强大的机器）和水平扩展（即将负载分布到多个更小的机器）之间做取舍。

把无状态服务分布然后扩展至多台机器相对比较容易，而有状态服务从单个节点扩展到分布式多机环境的复杂性会大大增加。

对于有状态服务，将数据库运行在一个节点上（采用垂直扩展策略），直到高扩展性或高可用性的要求迫使不得不做水平扩展。

最理想的扩展是具有弹性的，数据量增加自动扩容，数据量减少，自动缩容。（弹性）

可维护性

随着时间的推移，许多新的人员参与到系统开发和运维，以维护现有功能或适配新场景等，系统都应高效运转。

监视系统的健康状况，井在服务出现异常状态时快速恢复服务。
追踪问题的原因，例如系统故障或性能下降。
保持软件和平台至最新状态，例如安全补丁方面。
了解不同系统如何相互影响，避免执行带有破坏性的操作。
预测未来可能的问题，并在问题发生之前即使解决（例如容量规划）。
建立用于部署、配置管理等良好的实践规范和工具包。
执行复杂的维护任务，例如将应用程序从一个平台迁移到另一个平台。
当配置更改时，维护系统的安全稳健。
制定流程来规范操作行为，并保持生产环境稳定。
保持相关知识的传承（如对系统理解），例如发生团队人员离职或者新员工加入等。
提供对系统运行时行为和内部的可观测性，方便监控。
支持自动化，与标准工具集成。
避免绑定特定的机器，这样在整个系统不间断运行的同时，允许机器停机维护。
提供良好的文档和易于理解的操作模式，诸如“如果我做了X，会发生Y”。
提供良好的默认配置，且允许管理员在需要时方便地修改默认值。
尝试自我修复，在需要时让管理员手动控制系统状态。
行为可预测，减少意外发生。

第二章：数据模型与查询语句

语言的边界就是世界的边界。

一一Ludwig Wittgenstein, 《逻辑哲学论》 ( 1922)

关系模型

SQL是最著名的关系数据模型，数据被组织成关系（表），每个关系都是元组的无序集合（行）。

关系模型的目标是将实现细节隐藏在更简洁的接口后面。

对象和关系的不匹配

如果数据存储在关系表中，那么应用层代码中的对象与表、行和列的数据库模型之间需要一个笨拙的转换层。

如何在关系模型中表示简历

一个简历信息，通过userid在多个表之间关联。如果想要获取一个完整的简历，需要查询多个不同的表。

优点：可以读取表中的任何一行或者多行，支持任意条件查询。可以使用列作为条件，匹配这些列来读取特定行。可以在任何表中插入新行，而不用关心与其他表之间的关系问题。（业务逻辑可能需要关系，但数据本身不需要关心）

文档模型

由一些特定的键来确定文档，此文档中存在多个不同的属性，每个属性又指向一个文档数据（此数据可能多个文档共享）。

用户可以通过键来高效的获取此文档。（一次获取文档内容）

和关系模型对比

优点

文档模型

文档模型主要是模式灵活，由于数据局部，所以可以带来更好的性能，对于应用程序来说，更接近应用程序所使用的数据结构。

关系模型

强在联结操作，多对一和多对多关系更简洁。

缺点

文档模型

文档模式修改如果变更了文档的大小，可能需要重写整个文档。且如果文档内容过大，即使只需要文档中的一小部分内容，也必须加载整个文档。

关系模型

如果数据被划分在多个表中，查询则需要多次磁盘IO，花费大量的时间。

融合

大多数关系数据库系统（MySQL除外）都支持XML。其中包括对XML文档进行本地修改，在XML文档中进行索引和查询等，这样应用程序可以获得与文档数据库非常相似的数据模型。

随着时间的推移，关系数据库和文档数据库变得越来越相近。

查询语句

命令式查询语言（编程语言常见）

告诉计算机以特定的顺序执行某些操作。你完全可以推理整个过程，逐行遍历代码、评估相关条件、更新对应的变量，并决定是否再循环一遍。

声明式查询语言（关系模型常用）

1

SE LECT * FROM animals WHERE family =’Sharks';

只需指定所需的数据模式，结果需要满足什么条件，以及如何转换数据，而不需要说明如何实现这一目标。数据库系统的查询优化器会决定采用哪些索引和联结，以及用何种顺序来执行查询的各个语句。

能够在不改变查询语句的情况下提高性能。

场景	命令式	声明式
磁盘空间回收（可能需要移动数据改变数据的顺序）	会受到影响，有些查询命令可能会依赖于顺序	sql只在乎结果是否符合条件，不关心数据的存储顺序。
并行执行（现代CPU往往通过增加核心数量来提交CPU的性能，单核性能的提升微乎其微）	只能单线程运行，一个查询只能按找顺序执行	可以并行执行，多个核心多台机器一起优化
web服务或API（这两种区别不只体现在数据库上，在服务的接口上也一样）	把命令通过API传入，非常依赖被调用服务的内部资源情况。如果资源发生变动，则会是灾难性的。	类似rest风格，只声明自己需要的资源，至于此资源是否存在，如何提供外部服务不关心。

MapReduce查询

MapReduc e是一种编程模型，用于在许多机器上批量处理海量数据，兴起于 Google。大部分NoSQL（Not only sql）数据库都支持有限的MapReduce方式的执行只读查询。

**MapReduce既不是声明式查询语句也不是命令式查询语句。而是介于二者之间的。**主要包括map和reduce两个函数组成。

假设你是一名海洋生物学家，每当你看到海洋中的动物时，就会在数据库中添加观察记录。现在你想生成一份报告，来说明每个月看到了多少鲨鱼。

在PostgreSQL中的查询：

1
2
3
4
5


SELECT date_trunc(’month ’, observation_timestamp) AS observation_month,
sum(num_animals) AS total_animals 
from observations
WHERE family= 'Sharks' 
GROUP BY observation_month ; 

先对物种过滤，只查询鲨鱼，然后根据月份分组，汇总每个月的动物数量。

MongoDB中的MapReduce功能也可以实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


db.observations.mapReduce( 
function map() {
var year = this. observationTimestamp.getFullYear(); 
var month = this.observationTimestamp.getMonth() + 1; 
emit (year +"-"+ month, this.numAnimals); 
},
function reduce(key, values) {
	return Array.sum(values);
},
{
query: { family:"Sharks"},
out :"monthlySharkReport"
 }
);

通过query方法指定种类为鲨鱼

对于所有需要查询的文档，都会调用一次map函数

map函数返回一个KV对，其中key是年份和月份字符串，value为动物的数量

map方法的kv对被reduce函数接收，并汇总。

最后通过out方法输出到monthlySharkReport。

MapReduce用于在计算集群上分布执行。必须编写两个密切协调的函数，一个对于多个数据过滤需要的条件，另一个对于过滤出的条件进行汇总。

第三章：数据存储和检索

如果你把东西整理得井井有条，下次就不用查找了。

—–德国谚语

数据库的核心：数据结构

日志

如果所有的数据都以KV的形式简单存储在一个文件中。

每次新增数据：在文件末尾追加新的KV，如果多次更新某个键，旧的值不会被覆盖，文件最后一次出现的KV表示最新的值。

只追加到末尾形式，写性能很好，但读取非常困难。

写入开销几乎为O(1)，查询开销为O(n)

哈希索引

数据以KV和追加的形式存储在磁盘中，在内存中建立key对应偏移量的hashmap。每次查询通过内存中的hashmap获取偏移量，通过偏移量高效的读取磁盘上的数据。

Bitcask（Riak中的默认存储引擎）所采用的做法。

可以提供高效读写，只要所有的key放到内存中，而vlaue都保存在磁盘上。只需要一次磁盘IO就可以把Value加载到内存中。

此种结构非常适合值频繁更新的场景，适合key不是特别多，但更新特别频繁的情况。

磁盘数据的压缩

由于数据依然采用文件追加的形式保存，所以当文件达到一定大小，就新建一个文件来追加。此时老文件可以进行压缩操作。

哈希索引的局限性

hash表必须全部存在内存中（如果放到磁盘里，修改需要大量的随机IO，效果很差）
区间查询效率不高，对于范围查询只能扫描所有键，来确定当前键是否数据对应范围

SSTable和LSM-Tree

在hash索引的基础上，新增要求，对KV要求按照顺序排序。

排序字符串表（SSTable）

压缩过程

如何写入数据

存储虽然是有序，但写入并不会按照排序的顺序写入。那该如何在乱序写入时保证顺序追加？

在内存中维护一个AVL结构树（红黑树）
当内存大于某个阈值时，就把树写入到新的磁盘段中。
读取数据：先在内存表中查找键，然后去最新的磁盘段中查找，接下来是次新段。
后台线程周期性合并磁盘的段。

从SSTable到LSM-Tree

LSM-Tree(Log-Structured Merge-Tree)：以日志结构的合并树

如果查找不存在的值：需要先查询内存表，在根据内存表查找每个磁盘段，直到最后一个段。

可以添加布隆过滤器来过滤掉不存在的值，但会占用额外空间

LSM-Tree的思想：

数据集远远大于可用内存，它仍然能正常工作。
由于数据按排序存储，可以有效的进行范围查询。
由于磁盘是顺序写入，所以LSM-Tree可以支持非常高的写入吞吐量。

B-Trees

最常见，也几乎是最标准的数据存储结构。

有序：按键值来排序KV对（可以范围查找）

把数据库分成固定大小的块和页，传统大小为4kb，页是内部读写的最小单位。这样更接近硬件，因为磁盘也是固定大小的块排序。

每个页都使用地址来进行标识，这样可以让一个页引用另一个页。（形成链表），每个指针都指向磁盘地址。

某个页被指定为B-tree的根，所有查询都需要从根页开始。根页包含若干个键和对子页的引用，每个子页都负责一个连续范围内的键，相邻的键指示这些范围之间的边界。

页的分裂：如果修改或新增值在页的范围内，修改对应页并刷盘。如果添加的新键，页中没有足够的空间容纳新键，则需要将此页分裂成两个半满的页，并且父页也需要包含分裂后新键的范围。

通过分裂，可以确保树始终保持平衡，且查询效率为Logn，分支因子为500的4k页，四级树可以存储256TB的数据。

如何使B-Tree可靠

可能存在的问题

B-Tree的写操作，需要覆盖磁盘上的旧页。（LSM-tree只在文件末尾追加写入，不会修改文件）

修改操作在机械磁盘上的操作：磁头移动到正确位置，旋转盘面，用新的数据覆盖相应的扇区。

SSD：必须一次擦除并重写非常大的存储片块。

在分裂的情况下：需要写两个分裂页，并修改父页对两个子页的引用。

如果部分页写入后发生了崩溃，会导致索引被破坏，出现孤儿页。

通过预写日志来解决（WAL：write-ahead log，重做日志）

mysql中对应redo log

通过一个仅支持追加修改的日志文件，每次B-tree修改操作，都需要先修改WAL，然后再修改树本身的页。当数据库崩溃后，通过该日志恢复到最近的一致状态。

通过日志可以解决原子性问题，在并发状态下与锁配合，可以做到原子更新。
数据连续的不同页在磁盘上可能不是连续的，可以通过分区尽量把连续的数据放到一起。但如果数据量特别大，此成本将远远高于LSM-Tree

LSM-Tree vs B-tree

LSM-Tree写入更快，B-tree 查询效率高

写放大

指完成一次写入操作，需要向硬盘中进行多少次写操作。

现代固态硬盘可以把磁盘的随机写入变成顺序写入，但更小的写放大依然可以带来更高的性能。

场景	B-tree	LSM-Tree	结论
写入数据	需要至少两次磁盘写入：写入预写日志，写入树上的页（还可能发生分裂）。即使只写一个字段，也需要更新整个页	只需要写入紧凑的SSTable文件（且是连续的顺序写入）	LSM-Tree的顺序写入成本要远远低于b-tree的多次随机写入
数据占用空间	数据由若干个未满的页组成，成碎片分布	有多个段组成SSTables，数据密集且连续。而且会定期通过压缩来回收碎片	LSM-Tree数据占用的空间要远远小于B-tree
稳定性	数据写入即确定，一般不会发生变动	定期会进行压缩，压缩时可能会给读写请求带来一定的影响。（极端情况：写入量过大，导致压缩一直结束不了）	B-tree更加稳定，LSM在压缩时会很小的影响性能

内存数据库和磁盘数据库对比

内存数据库的优点并不是不需要读取磁盘。如果内存足够大，完全可以把磁盘结构的数据存储到内存中。

内存数据库的优点在于不需要使用磁盘的格式对内存数据结构编码的开销。（内存数据库中可以直接按照应用使用的内存结构来存储数据，而无需转换）

事务处理与分析处理

事务主要指组成一个逻辑单元的一组读写操作。（不一定具有ACID属性）

OLTP（事务处理系统）与OLAP（分析系统）

属性	事务处理系统（OLTP）	分析系统（OLAP）
主要读特征	基于键每次查询返回少量的记录	对于大量记录进行汇总
主要写特征	随机访问，低延迟写入用户的输入	批量导入（ETL ）或事件流
使用场景	终端用户，通过网络应用程序	内部分析师，为决策提供支持
数据表征	最新的数据状态（当前时间点）	随着时间而变化的所有事件历史
数据规模	GB到TB	TB到PB

mysql是典型的OLTP与OLAP同时处理的数据库。但随着发展，公司放弃使用OLTP 系统用于分析目的，而在单独的数据库上运行分析。

数据仓库

数据仓库包含公司所有各种OLT 系统的只读副本。从OLTP数据库（使用周期性数据转储或连续更新流）中提取数据，，转换为分析友好的模式。

ETL

将数据导入数据仓库的过程称为提取－转换－加载。（Extract-Transform-Load）

星型与雪花型分析模式

星型表

一个事实表关联多个维度的配置信息表

列式存储

大部分OLTP数据都是按行来存储数据，如果一行数据有上百个列（甚至更多），则按列式存储是一个更好的方式。

列式存储的思想

不要将一行数据中的所有值存储在一起，，而是将每列中的所有值存储在一起。如果每个列存储在个单独的文件中，查询只需要读取和解析在该查询中使用的那些列，这可以节省大量的工作。

列压缩

列式存储出现了大量的重复数据，对于这些大量重复的列可以做压缩。

压缩思路

用一个超长的二进制字符串，每一位代表每一行，0/1表示是否存在，每个枚举值对应当前值的位图。这样可以把大量重复的值都存储在同一个位图里。如果多个值查询只需把多个位图的值做或运算。

对与二进制位图本身，也可以使用游程编码的方式来进一步压缩。（第一个数字表示前置0，后一个表示1，然后交替）

列式存储如何排序

规定排序的列应尽可能的让具有相同值的列排在一起，这样可以更好的压缩数据。

如果业务必须要按照不同的排序条件来查询数据，可以考虑按不同的规则复制几份不同的列存储。

现代生产中数据本身就会被备份多份，不如利用起来，按照不同的排序规则备份相同数据，然后根据业务决定查询哪一份。

列式存储的写操作

对于排序后的列式存储，如果按照常规原地更新的方式插入数据，那将重写所有的列，这是灾难性的。

vertica的做法：参考LSM-tree的解决方案，先把数据存储在内存中，当达到一定阈值，与磁盘中的列文件合并，生成新的列文件。

查询时，先查询内存中是否存在，再去磁盘中搜索列。

现代使用列式存储的数据库（扩展）

ClickHouse: 一个开源的分布式列式数据库，以其惊人的查询速度闻名。它非常适合处理海量数据，常用于实时分析、用户行为分析和日志处理等场景。
Apache Druid: 一个为实时分析设计的开源数据库。它在处理流数据、快速聚合和亚秒级查询方面表现出色，常用于实时数据仪表盘和事件驱动的分析应用。
Vertica: 一个高性能的企业级列式数据库，专为大规模数据仓库和商业智能（BI）场景设计，支持复杂的分析查询。
Apache HBase: 一个基于 Hadoop HDFS 的分布式、面向列的数据库。它提供对海量数据的随机、实时读写访问，常用于日志分析、实时推荐等场景。
Apache Cassandra: 一个分布式、高可用的 NoSQL 数据库。它的数据模型是“宽列存储”，虽然也常被归为列式家族，但其设计更侧重于高写入吞吐量和跨数据中心的容错性。

维度	ClickHouse (CK)	MySQL	Oracle
核心定位	极致性能的分析型数据库 (OLAP)	通用的事务型数据库 (OLTP)	企业级核心事务数据库 (OLTP)
存储方式	列式存储 (读取仅涉及相关列，压缩率极高)	行式存储 (适合读写整行数据)	行式存储 (侧重数据一致性与锁机制)
数据量级	PB 级 / 百亿行单机可处理数十亿行，集群轻松支撑 PB 级	TB 级 / 千万~亿行单表超过 2000 万性能下降，20 亿数据需极度复杂的分库分表	PB 级 / 海量单机处理能力极强，适合超大规模核心业务
查询性能	聚合/分析查询极快比 MySQL 快 10-100 倍甚至更多。适合全表扫描、Group By。	点查询/事务快基于主键的查询极快。复杂分析查询（如大表 Join）在数据量大时极慢。	复杂计算稳健优化器极强，擅长处理复杂的 SQL 逻辑和事务。
写入性能	高吞吐批量写入适合一次性写入大量数据，不支持高频单条插入。	高频实时写入支持高并发的单行 Insert/Update。	稳定事务写入保证 ACID 特性下的稳定写入，成本较高。
Join 能力	较弱大表关联容易内存溢出，建议使用宽表模型。	中等适合中小规模数据的关联查询。	极强擅长处理极其复杂的多表关联和子查询。
适用场景	日志分析、用户行为、报表实时大屏、数据仓库、监控指标。	互联网业务、Web 应用电商订单、用户系统、CMS、小程序。	金融核心、大型 ERP 银行交易、核心账务、复杂企业系统。
主要短板	不支持事务 (ACID)、不擅长高频更新/删除。	复杂分析性能差、大数据量下扩展困难。	昂贵、运维复杂、资源消耗大。