564-565, 标注, 2018 年 8 月 11 日星期六 下午 8:56:08
所有的写操作只追加而不修改老的数据。在 Bitcask 系统中，每个文件有一定的大小限制，当文件增加到相应的大小时，就会 产生一个新的文件，老的文件只读不写。
644-645, 标注, 2018 年 8 月 12 日星期日 下午 3:31:39
存储系统的数据模型主要包括三类：文件、关系以及随着 NoSQL 技术流行起来的键值模型。
690-692, 标注, 2018 年 8 月 12 日星期日 下午 4:01:13
表格模型往往还支持无模式（schema-less）特性，也就是说，不需要预先定义每行包括哪些列以及每个列的类型，多行之间 允许包含不同列。
842-844, 标注, 2018 年 8 月 12 日星期日 下午 4:29:58
需要将内存中的数据定期转储（Dump）到磁盘，这种技术称为 checkpoint（检查点）技术。系统定期将内存中的操作以某种易 于加载的形式（checkpoint 文件）转储到磁盘中，并记录 checkpoint 时刻的日志回放点，以后故障恢复只需要回放 checkpoint 时 刻的日志回放点之后的 REDO 日志。
746-822, 标注, unknown
NoSQL 系统带来了很多新的理念，比如良好的可扩展性，弱化数据库的设计范式，弱化一致性要求，在一
824-897, 标注, unknown
NoSQL 系统带来了很多新的理念，比如良好的可扩展性，弱化数据库的设计范式，弱化一致性要求
899-1082, 标注, unknown
需要将内存中的数据定期转储（Dump）到磁盘，这种技术称为 checkpoint（检查点）技术。系统定期将内存中的操作以某种 易于加载的形式（checkpoint 文件）转储到磁盘中，并记录 checkpoint 时刻的日志回放点，以后故障恢复只需要回放 checkpoint 时刻的日志回放点之后的 REDO 日
1084-1237, 标注, unknown
需要将内存中的数据定期转储（Dump）到磁盘，这种技术称为 checkpoint（检查点）技术。系统定期将内存中的操作以某种 易于加载的形式（checkpoint 文件）转储到磁盘中，并记录 checkpoint 时刻的日志回放点，以后故障恢复只需要回放
1239-1436, 标注, unknown
需要将内存中的数据定期转储（Dump）到磁盘，这种技术称为 checkpoint（检查点）技术。系统定期将内存中的操作以某种 易于加载的形式（checkpoint 文件）转储到磁盘中，并记录 checkpoint 时刻的日志回放点，以后故障恢复只需要回放 checkpoint 时刻的日志回放点之后的 REDO 日志。 由于将内存数据转储到磁
1438-1623, 标注, unknown
需要将内存中的数据定期转储（Dump）到磁盘，这种技术称为 checkpoint（检查点）技术。系统定期将内存中的操作以某种 易于加载的形式（checkpoint 文件）转储到磁盘中，并记录 checkpoint 时刻的日志回放点，以后故障恢复只需要回放 checkpoint 时刻的日志回放点之后的 REDO 日志。
1625-1867, 标注, unknown
存储系统在选择压缩算法时需要考虑压缩比和效率。读操作需要先读取磁盘中的内容再解压缩，写操作需要先压缩再将压缩结 果写入到磁盘，整个操作的延时包括压缩/解压缩和磁盘读写的延迟，压缩比越大，磁盘读写的数据量越小，而压缩/解压缩的 时间也会越长，所以这里需要一个很好的权衡点。Google Bigtable 系统中使用了 BMDiff 以及 Zippy 两种压缩算法，它们通过牺 牲一定的压缩比换取算法执行速度的大幅提升，从而获得更好的折衷。
1869-1981, 标注, unknown
设计容错系统的一个基本原则是：网络永远是不可靠的，任何一个消息只有收到对方的回复后才可以认为发送成功，系统设计 时总是假设网络将会出现异常并采取相应的处理措施。 （3）磁盘
1983-2066, 标注, unknown
设计容错系统的一个基本原则是：网络永远是不可靠的，任何一个消息只有收到对方的回复后才可以认为发送成功，系统设计 时
2068-2174, 标注, unknown
设计容错系统的一个基本原则是：网络永远是不可靠的，任何一个消息只有收到对方的回复后才可以认为发送成功，系统设计 时总是假设网络将会出现异常并采取相应的处理措施。
1099-1100, 标注, 2018 年 8 月 12 日星期日 下午 7:51:48
分布式存储系统需要能够自动识别负载高的节点，当某台机器的负载较高时，将它服务的部分数据迁移到其他机器，实现自动 负载均衡。
1100-1101, 标注, 2018 年 8 月 12 日星期日 下午 7:52:06
分布式存储系统的一个基本要求就是透明性，包括数据分布透明性，数据迁移透明性，数据复制透明性，故障处理透明性
1413-1414, 标注, 2018 年 8 月 14 日星期二 下午 12:33:53
Paxos 协议用于保证同一个数据分片的多个副本之间的数据一致性
1414-1415, 标注, 2018 年 8 月 14 日星期二 下午 12:34:05
2PC 协议用于保证属于多个数据分片上的操作的原子性
1573-1574, 标注, 2018 年 8 月 16 日星期四 下午 3:43:17
Master 创建了一个 chunk，它会根据如下因素来选择 chunk 副本的初始位置：1）新副本所在的 ChunkServer 的磁盘利用率低于平 均水平；2）限制每个 Chunk-Server“最近”创建的数量；3）每个 chunk 的所有副本不能在同一个机架
1616-1617, 标注, 2018 年 8 月 16 日星期四 下午 3:50:23
在设计 GFS 时认为节点失效是常态，通过在软件层面进行故障检测，并且通过 chunk 复制操作将原有故障节点的服务迁移到新的 节
1803-1806, 标注, 2018 年 8 月 16 日星期四 下午 4:16:50
考虑到节点的异构性，不同节点的处理能力差别可能很大，Dynamo 使用了改进的一致性哈希算法：每个物理节点根据其性能的 差异分配多个 token，每个 token 对应一个“虚拟节点”。每个虚拟节点的处理能力基本相当，并随机分布在哈希空间中。存储时， 数据按照哈希值落到某个虚拟节点负责的区域，然后被存储在该虚拟节点所对应的物理节点中。
1815-1817, 标注, 2018 年 8 月 16 日星期四 下午 4:25:27
所有节点每隔固定时间（比如 1s）通过 Gossip 协议的方式从其他节点中任意选择一个与之通信的节点。如果连接成功，双方交 换各自保存的集群信息。 Gossip 协议用于 P2P 系统中自治的节点协调对整个集群的认识，比如集群的节点状态、负载情
1967-1968, 标注, 2018 年 8 月 16 日星期四 下午 6:02:29
Bigtable 的设计理念是构建在廉价的硬件之上，通过软件层面提供自动化容错和线性可扩展性能力。
2957-2960, 标注, 2018 年 8 月 21 日星期二 下午 8:25:52
整个系统设计时完全摒弃了随机写，除了操作日志总是顺序追加写入到普通 SAS 盘上，剩下的写请求都是对响应时间要求不是 很高的批量顺序写，SSD 盘可以轻松应对，而大量查询请求的随机读，则发挥了 SSD 良好的随机读的特性。摒弃随机写，采用批 量的顺序写，也使得固态盘的使用寿命不再成为问题。
3006-3008, 标注, 2018 年 8 月 22 日星期三 下午 7:47:01
内存管理是 C++高性能服务器的核心问题。一些通用的内存管理库，比如 Google TCMalloc，在内存申请/释放速度、小内存管 理、锁开销等方面都已经做得相当卓越了，然而，我们并没有采用。这是因为，通用内存管理库在性能上毕竟不如专用的内存 池
3363-3533, 标注, unknown
整个系统设计时完全摒弃了随机写，除了操作日志总是顺序追加写入到普通 SAS 盘上，剩下的写请求都是对响应时间要求不 是很高的批量顺序写，SSD 盘可以轻松应对，而大量查询请求的随机读，则发挥了 SSD 良好的随机读的特性。摒弃随机写， 采用批量的顺序写，也使得固态盘的使用寿命不再成为问题，
3535-3684, 标注, unknown
内存管理是 C++高性能服务器的核心问题。一些通用的内存管理库，比如 Google TCMalloc，在内存申请/释放速度、小内存 管理、锁开销等方面都已经做得相当卓越了，然而，我们并没有采用。这是因为，通用内存管理库在性能上毕竟不如专用的内 存池
3686-3754, 标注, unknown
释放内存时，如果没有超出线程缓存的内存块个数限制，则将内存块还给线程局部的空闲链表