设计数据密集型应用 ( DDIA ) 读书笔记(2)
前言
本周 DDIA 读书会的进度来到了第三章与第四章，内容分别是存储检索 与 编码与演化 两个小结，个人的读书进度已经到了第十章左右，现在写这篇读书笔记权当复盘之前的内容了。第三章和第四章的内容非常有趣，第三章主要讲的是分布式数据库的存储结构，第四章则讲的数据库的网络交互，这两章都是属于那种讲的部分知识是之前接触过的，但是有部分知识对于没有接触过大数据相关知识的人(比如我)来说可能非常新颖。
CH3：存储结果
章节描述
本章主要说的是数据在存储介质(硬盘，内存)内存储的结构，主要讨论了市面上比较常见的一些数据库存储结构，分别讨论了哈希索引，LSM树，B树，模糊搜索与B+树以及列存储，列存储部分的内容说实在的我不是特别了解且之前的项目并没有接触过多少列存储的内容，这里只能放一个 TODO 等到之后对列存储相关的内容有所了解了才进行讨论。
哈希索引
第三章最开始讨论的就是哈希索引，其实哈希索引算是老朋友了，无论是 py 中的 dict 还是 java、golang 的 hashMap，亦或者是 php 的 array 其本质就是基于哈希索引的 key-value 存储结构，哈希索引的好处是可以非常快的检索到需要的数据存储的位置，坏处也非常明显:哈希索引不存在范围读取的说法，对于每一个key值都需要进行hash处理，如果要进行范围查询，则需要计算对应的 hash 值，对于单条数据索引以及查询数据存储位置可能会比较好使，但是仅仅使用哈希索引是很难满足实际业务需求的。
LSM树
LSM 树算是这章我了解的非常新颖的知识了，LSM 树算是 google BigTable 论文的核心所在，其根本思想就是利用硬盘顺序读写的优势，对key值进行排序并进行保存，保证读取效率，单有这个顺序读取的功能其实是远远不够的，LSM 树之所以称为树，是因为他使用了一种类似于 CPU L1,L2 ,L3 缓存的思想，将数据进行缓存。查找数据的时候会按照层级依次查找，越热门的数据存储的结构可能保存在越高的层级，非热门数据会被合并并打包到下一层的内容中，在看这部分内容的时候和一个平时处理 Cassandra 数据的同学沟通了下，Cassandra其实还附带了一个位图，用于判断 key 值是否保存在当前集群，LSM 树的这种保存形式和硬件缓存以及 LRU 算法某种意义上达到了一致我也是没想到的，算是软硬不分家了。
B树 B+树
这部分算是老朋友了，网上B树与B+树相关的内容多如牛毛，我就不献丑了，总结一下就是B树更适合连表及范围查询，而B+树则非常麻烦。一个是 Mysql 一个是 Mongo 的主要存储格式。
列存储与数仓分析
这部分内容，只能给个 TODO 了，老实说我是真没看明白。希望有朝一日能和BigTable论文一样，能够在某个地方恍然大悟吧。
CH4 编码与演化
章节描述
本章主要讲的是数据库存储与调用的时候的数据格式，主要介绍了 JSON XML 以及GRPC REST等相关协议的实现和编码，比较硬核
编码格式
编码格式先介绍了 XML 和 JSON 两种在开发的时候常用的数据格式，这两种格式的特点都是对于人类阅读非常友好，但是对于机器读取及存储非常麻烦，都需要对数据进行解析，并且会有非常多的数据冗余，然后介绍了MessagePack ，一种 json 的二进制存储结构，MessagePack 使用特定的标志来表示某个结构的长度和类型，虽然部分减少了存储的结构大小，但是还是保存了键值，字段类型等数据，而之后介绍的 GRPC 则更加精简，通过代码生成的形式来省去了字段名称，通过客户端和服务端的协议来满足 RPC 通信，在之后的介绍的 Avro ，个人不是特别熟悉，就不献丑了。
服务中的数据流
TODO 这部分的内容算是囫囵吞枣，之后可能会再读一遍
