设计数据密集型应用 - Data Model And Query Language - 第三章小结

这章的主题是存储和检索(Storage And Retrieval), 整体可读性很强, 各个阶段的描述都围绕数据存储方式，以及的检索，更新，删除；

最简单的存储和索引系统可以简单的对记录(key,value对，可以衍生到按行记录) 进行追加(append)的记录/文件管理方式, 每次查询的使用用linux系统自带的grep进行查询;

• 存储方式，简单在文件末尾进行追加
• 检索方式，grep相对应的key(可能涉及多文件查询，因为一般会控制文件的大小， 而且设计更新和去除旧的记录的merge）
• 更新方式，简单的追加在文件末尾，系统会更具文件大小进行新文件建设，并在后台融合旧文件，已防止磁盘写满;

问题：对于查询(query)，会出现较多耗时较长的查询?

关于优化上面那种检索方式，有人建议通过哈希化主键(key), 并对记录进行排序(sort)，来优化上面那种存储系统中存在的查询慢问题。并由此衍生出的存储方式

排序表（Sorted Table）, 这种比较好理解，即将上面存储记录按key 进行排序（一般存于内存中， 通过树形结构将key保持有序），当积累到一定量后，写到文件中，在写的过程中涉及融合原有旧记录，一般采用sorted-merge方案, 这种方式也是用于范围式的查询场景，而且无需将所有key对应的hash值存储在内存中,这种方案也被成为日志结构融合式树结构(Log-Structured Merge-Tree)；

书中还提到一种被实际广泛采用的索引结构B-Tree, 即本质是将存储按指定大小页(Page)或块(Block)存储，每个页都有一个地址(Address)或引用(Reference)，可以被引用:

• 存储方式，按页存储数据，当页大小达限制时（一般4k）, 进行分页，父节点页记录子页的其实key大小；
• 检索方式，因为只有一个根节点页，只需按根节点进行二分/端查找
• 更新方式，与检索方式类似，除了当更新value大于页限制时需要进行分页;

书中又按数据库所进行的日常操作进行分类，一种是偏记录和查询的数据库(Online Transaction Processing Database, OLTP), 另一种是偏分析型数据库（Online Analytic Processing Database, OLAP）; 这么分的原因主要是两种数据库日常对数据库操作纯在本质差异(在分析型数据库中存在大量的sum, count的查询，如果有每次都扫一遍所有数据，存在大量的I/O浪费)；

在OLTP和OLAP的分化发展中，OLTP为了在一定程度上支持对应的数据分析，提出一些有趣的特征，比如Material View, 即建立一个表用来存储按不同纬度汇总的数据，具体例子是按日期汇总销量，在第二纬度用商品种类，第三纬度按生产地等；

OLAP为了优化分析分析效率，提出基于列存储（Column-Based）方式，可打来的好出，当行的纬度较高时，可以减少每次拉取所需要占用的I/O, 而且可以进行按列压缩