NoSQL章启
# 为什么会有NoSQL
传统的关系型数据库为大量的应用提供了统一的数据持久化机制，通过标准化的SQL查询语言简化了数据操作。关系型数据库建立在E-R（实体-关系）模型上，将现实世界中的需求对象抽象为实体及其之间的关系，通过表格的方式存储实体与其属性、实体与实体的关系及关系的属性。通过过这种抽象，关系型数据库实现了通用性极强的数据建模，直至今日依然是很多解决方案的技术选择。
然而，关系型数据库并非万能，也存在着一些问题。首先，随着各类应用的数据量的增长，传统的单机数据库逐渐难以满足需求，数据库的纵向扩展（Scale-up）受制于触达边缘效应的单机性能。分页、分表与分库成为了另一种拓展的方式即横向扩展（Scale-out），这种方式采用大量廉价的机器组成的集群实现性能的增长，但依赖于更加复杂的分布式方案，而这些方案对于传统的关系型数据库而言具有挑战。例如，使用innodb的MySQL在分布式集群上更多地采用主-从模式而非同级模式，主机的写性能可能成为瓶颈；对事务的支持在分布式环境上也面临着挑战，事务的ACID特性难以得到完全的支持。另一方面，表格数据库受制于schema，即表格的定义。这使得关系型数据库在面对松散定义的非结构化数据时很难被快速地应用起来。例如，新闻网站中各种格式的文章被更新时，使用关系型数据库存储很可能需要重写SQL用于完成原先任务。
为了减缓这些实现中遇到的问题，NoSQL（Not Only SQL）就被提出了。他们主要是非关系型数据库，不使用表格存储数据，可运行在集群上并与大数据框架集成。NoSQL的典型数据模型主要分为4类，文档模型、键值模型、图模型及列模型。
# 几种典型的NoSQL数据库
# 文档型数据库——MongoDB
文档型数据库采用一种半结构化的方式存储数据。半结构化的数据不包含预先定义的刚性schema，而是采用一种自描述的方式，即通过文档内容描述数据的意图。典型的例子是XML和JSON。由于XML的冗余性质，XML的使用已经逐渐减少，而被更为简洁的JSON乃至YAML取代。
文档数据库的典型是Mongodb，采用类似JSON的BSON存储数据。BSON可以被视为JSON经过压缩编码后的文件，但仍然保留了一定的可读性。这类文档数据库虽然不提供SQL查询，但提供其他的查询方式，如聚合（Aggregation），可通过对文档进行流水线式的处理来得到查询结果。在MongoDB的实验中，文档的聚合处理速度常常取决于某些耗时操作的文档数量以及是否使用索引，例如提供类似join功能的$lookup如果没有索引，则1个包含一万文档的$lookup查询可能耗时超过1分钟。
关于MongoDB的更多讨论会放到这里。