一、什么是 Data-Intensive applications
Data-Intensive applications是相对于 Cpu-Intensive而言的，由于摩尔定律的发展，cpu已经不是瓶颈，而随着大数据时代的到来，导致Data-Intensive 称为了新的关注点
二、Data Systems 关键的3个三个方面
databases，queue，cache等，由于目前框架都支持多种传统分类的功能，因此可以将他们通通当做data systems进行处理
- 说一千，道一万，对于一个 数据系统，我们最关心的就3个，reliablity，scalability，maintainability
2.1 Reliablity
可持续地正确工作
设计一个 fault-tolerant 系统，有很多方面可以考虑，但反直觉的是，人为的引发错误对系统也是有意义。这是因为，很多情况下，严重的bug是源于糟糕的容错能力，在开发，测试和生产上主动引发bug可以解决更严重的bug
例如：netflix的 chaos monkey
- hardware fault
通过备用电源等硬件技术可以粗略的估算一台服务器可以平稳工作数年，但不是100%保证硬件系统不会宕机 - software errors
第一部分是系统错误，这些很难处理。如千年虫等，带宽等。但这些问题很少，每次发生都很严重 - human errors
最常见的fault了
2.2 Scalability
面向未来扩展的角度，处理未来增长负载的能力
举例：twitter的2种实现方式：
第一版twitter:所有人发出的tweet被插入一个中心化的tweets，每个人读取的时候，去tweets读取自己发的和自己follow的人的tweet，再merge返回。
随着规模扩大很难持续第二版twitter，为每个用户维护一个时间线，假设你发了一个tweet，就会推送到每个follow你twitter用户，那个用户就加入到自己的时间线上，在放入缓存
这个潜在的问题时，你维护的规模扩大了，假设某个明星有3000W的follow，此明星发一个tweet，意味着要为3000W个用户维护新增时间线内容，twitter设立了要在5s内完成的目标最终实现，为大部分人采用维护单独时间线方式，因为一个人平均75个followee，但为少部分拥有很大规模follower的人，采用方案1的中心时间线。 read twitter的时候采用2者的结合，你关注的普通人就从你的时间线读取，你关注的名人从中心时间线读取，再结合在一起
关于指标：通常不采用平均时间，而是采用百分比，90%的用户响应时间等。
2.3 Maintainability
legacy-system是一个令人头痛的问题，你无法避免可能接收别人的烂代码，但要尽量避免自己也对别人造成这样的问题。
最重要是关注3方面：
- Operability
即操作顺畅：这块其实可以参考ElasticSearch
进程状态，heathly，错误的追踪，安全系统，相应的辅助控制插件，即你可能关心的，最好都有相应的支持 - Simplicity
从代码到模块设计到架构，关键点就是抽象，抽象可明晰这个环节各个组成的功能范围，减少复杂性 - Evolvablity/entensibility
三、数据模型和查询语言
3.1 数据库模型
- relational database
- NoSQL--not only SQL
优点：1、scalability，更大的吞吐量 2、商业上免费 3.传统数据库不支持的特殊查询 4、不需要严格的关系型表，使用更为灵活
3.2 Object-Relation Mismatch
指的就是 Object-oriented progreamming 和 SQL data model之前的错位
因此产生了许多 ORM框架（Object-relational mapping）
举例了一个 one-to-many 例子
每一个简历选项，如工作经历，可能还有很多
演变历程
1.传统数据库：一个主表，然后通过外键关联其他表
2.later：数据库支持row存储 multi-valued data，大大减少关联的复杂度
3.第三种选择：一个document包含所有，在one-to-many的情景中，大大减少了复杂度
3.3 many-to-one 和 Many-to-many 关系的处理
Join 成本，传统数据库新增数据 join是非常简单的，但document并不是特别容易，设计时需要适合应用，尽量 join-free
如这个例子，将变动的工作经历，单独作为了一个entity的引用，以减少整个大文档的变动。这在我理解中其实也是和关系型数据库一样，进行了外键连接，还有更为复杂的many-to-many关系，必须实际考虑修改的频率，文档的大小，服务器性能等因为。
在这个简历的例子中，由于简历并不是一个更新频率高的文档，其实整个文档重建的刷入性能消耗一点时间是完全可以接受的，并不需要特殊处理。使用文档，加速查询时的速度才是关键的
3.4 Query Languages for Data
这里将查询分为2类，一类是 declarative query，如SQL，CSS等，另一类是利用 imperative code去查询如java等
2者的区别
- imperative code：如java使用DOM时，你知道每一步是如何解析的，知道每一个细节
- declarative query：你只是提供了你所需数据的条件，符合这些的都会返回，数据引擎对于你封装了实现细节，你不用去关心底层到底是如何得到这些数据的
- MapReduce 的query
MapReduce作为处理数据流的理念流行起来，那么对此应该如何进行查询
MapReduce是介于 imperative code 和 imperative code 的一个维度 ,就是一个进化未完成的东西，较低层次的编程模型
MongoDB的例子
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"
}
);
3.5 Graph-Like Data Models
many-to-many的关系，一般不选用document 模型，而使用relational database，但如果你的数据大部分全是many-to-many，哪怕你用了relational database，你的查询仍然是复杂的。为应对这种情况，有专门的 graph-like Data Models进行处理
Graph-Like Data Models 基本组成
- node (entities)
- edge (relationships)
举例：
Social graphs
Vertices are people, and edges indicate which people know each other.
The web graph
Vertices are web pages, and edges indicate HTML links to other pages.
Road or rail networks
Vertices are junctions, and edges represent the roads or railway lines between
them.
为了集中重点，此部分写在数据库系列中
因为这块图不怎么了解，写在另一个篇中
//www.greatytc.com/p/830e7664f8b1
四、总结
主要讲了3种数据模型，relational，document，graph，这些是主要的，但为了很多特殊的用途，还有许多其他的模型
如基因组，物理研究大数据，全文搜索等
