- 数据模型：数据模型恐怕是开发软件中最重要的一部分，因为它不仅影响到软件如何编写，同时也影响我们如何去思考要解决的问题。在复杂的系统中会有很多的中间层，API通常构建在其他的API之上，但是基本的思路是一样的，屏蔽底层实现细节，提供一个一致的数据模型。
- NoSql的诞生：确切的说NoSQL是说Not Only SQL，主要基于以下几个驱动力：
- 更容易的水平扩展来解决大数据集和吞吐量的问题。
- 关系型数据库不支持查询。
- 渴望有一个更加动态的和更富表现力的数据模型，而不是严格的schema
- 关系型数据库和文档数据库对比
- 文档数据库的主要的点在于1）schema不是严格限制的，更好的性能，更贴近应用的数据结构，不会出现object-relation-mismatch的情况。而关系型数据库最主要的点在于对于Join的支持更好，对于处理一对多和多对多的模型更加得心应手。
- 如何选择：
- 如果你的应用的数据是文档类型结构（比如一个一对多的树形结构，并且典型的应用场景都是把一整个load进来）这个时候适合文档数据库。但是文档数据库有它的局限，没法直接获取到你想访问的片段，但是只要不是嵌套的太深也还ok。同时join支持的也很差，也是取决于应用场景。
- 如果你的应用中有需要多对多关系，这个时候用文档数据库不见得是明智之举。
- Schema
- 文档数据库有的时候被称作无schema数据库，但是这是有所误导的，应用的代码在读取数据的时候还是会假定数据是某一种结构，所以这里是有隐式的schema存在的，只是不是用数据库来强制约束的。更确切的描述是schema on read而不是schema on write。就像程序里面的动态类型和静态类型一样。
- 如果处于某种原因数据并不是所有的都有相同的结构的时候，schema on read是很有用处的。原因可能是：有很多类型或者数据是由外部系统提供的不可控。
- 数据局部性
- 文档数据库通常会存一个大的连续的字符串，比如Json，xml或者某些二进制结构。如果你的应用需要访问整个数据，数据局部性是有优势的。如果数据散落到几张表里面你会需要更多的时间。这种局部化的数据只有在面对需要一次拿到整个文档数据时候才有优势，如果你只关心一小部分，则不是很适合。在整个较大的情况下会造成很大的浪费，因为大多数的更新都会重新写入这条数据。需要指出的是把相关数据放在一块来达到数据局部性不仅限于文档数据库，比如HBase的 column-family也是为了达到这个目的。
- 声明式查询和命令式查询
- 声明式查询就是类似sql，命令式就是类似于一段JavaScript代码来写出sql的逻辑。声明式查询是更加生动的因为它更加的一致并且更容易上手。更重要的是，它屏蔽了数据库的实现细节，这可以在不改变查询的情况下通过数据库进行优化。
- 声明式查询不关心数据的顺序，但是命令式的代码数据库没法保证它是否依赖于数据的顺序。事实上SQL通过限制函数来给数据库更多的自动优化空间。
- 声明式查询更容易并行化。
- Map - Reduce既不是声明式查询也不是命令式，它介于两者中间，查询通过命令片段去表达，整体上通过基于map reduce函数的框架去调度。
- 图数据库
- 如果多对多的关系是非常常见的话，关系型数据库也会变得无力，这个时候考虑使用图数据库。
- 总结：最开始大家都使用一个树形结构来存放数据，后来发现在多对多关系中不太行，因此发明了关系型数据库。但是发展到最近，开发者发现有些应用用关系数据库也不太行，这个时候就产生了NoSQL，主要是两个方向：
- 文档数据库，对标于数据是一个包含自己的文档并且相互直接没啥关系。
- 图数据库恰巧相反，主要解决数据里面有太多的多对多的关系。
DDIA（二）
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- Spark SQL, DataFrames and Datasets Guide Overview SQL Dat...
- //我所经历的大数据平台发展史（三）：互联网时代 • 上篇http://www.infoq.com/cn/arti...
