DDIA
DDIA
ps∶软件设计哲学
我们现在做的系统刚好就是数据密集型应用，春哥之前提到的列式存储这本书里也有所提及，我甚至感觉春哥也看过这本书
我是不是应该专注于数据密集型应用这个领域呢？专注于数据处理领域，称为这个领域的专家，
数据处理领域，应该是一个业务领域，是一个业务概念，
我越看越觉得相见恨晚，这就是我熟悉的领域
neo4j
MySQL
达梦数据库
tdengine
我都熟
数据处理领域，这就是我的主场。
如果我还能做个开源项目，那就是王炸
第二章教会我们一点，我们应该根据概念的类型，来选择适合的数据库，这样会事半功倍，不要不管数据是什么结构都用 MySQL 去存。
如何分析一个数据模型：
基本考察点：数据基本元素，和元素之间的对应关系（一对多，多对多）
利用几种常用模型来比较：（最为流行的）关系模型，（树状的）文档模型，（极大自由度的）图模型。
schema 模式：强 Schema（写时约束）；弱 Schema（读时解析）
我要不要仿照数据集，通过 Java 数据库 api，写一个通用的数据操作接口，仿照数据库连接池的写法，数据库连接池也是对接多种数据库。还有 shard 库
我也得去了解一下我们的项目的元数据的做法
看到第三章
数据库索引：一种允许基于某些字段查找的额外数据结构。
用文件实现一个 key，value 数据库，
基于日志文件的数据库存储引擎的优点
数据通过顺序写写入磁盘，数据写入快，而且不存在并发修改的问题
所有的日志文件中只有一个日志文件可写，其他的日志文件全都是只读的，因此我们可以在数据写入的时候做历史数据的压缩，回收空间
索引放内存，查询起来很快
可以以当前写入行号为版本 ID，实现简单的事务，比如开启一个事务的时候，写到第 5 个文件的 100 行，那么后面的更改我都不考虑了，实现可重复读。
缺点
所有的索引数据放内存，如果 key 太多，内存就会不够
因为 key 是无序的，如果对 key 进行范围查询，比如 key 为 ID，我们搜索 ID 大于 100 小于 200，那么就需要遍历索引。
因此，这种类型的数据库只适合 key 数量不大，同时频繁写的那种数据库