本章内容
MongoDB的历史、设计目标和关键特性
MongoDB Shell和驱动的简要介绍
MongoDB的使用场景及其局限性
近几年，如果构建Web应用程序，你可能会选择关系型数据库作为主要数据存储方案，而且它的表现通常也能接受。大多数开发者都熟悉SQL，能体会到精心正规化（normalized）后的数据模型所散发出的美感，了解事务的必要性，知道持久化存储引擎提供的保证。就算我们不喜欢直接和关系型数据库打交道，也能找出很多工具帮助我们降低复杂度，上至管理控制台，下至对象关系映射器。简言之，关系型数据库十分成熟且有口皆碑。因此，当一小群有主见的骨干开发者开始提倡另一种数据存储时，便有人提出了关于这些新技术的可行性和实用性的问题。这些新数据存储是关系型数据库的替代品吗？谁在生产环境中使用它们，为什么选择它们？在向非关系型数据库的迁移过程中又要做哪些权衡？上述问题的答案都可以建立在这个问题的答案上：为什么开发者对MongoDB感兴趣？
MongoDB是一款为Web应用程序和互联网基础设施设计的数据库管理系统。MongoDB的数据模型和持久化策略的设计目标是提供高读写吞吐量，在易于伸缩的同时还能进行自动故障转移。无论应用程序只需要一个还是几十个数据库节点，MongoDB都能提供惊人的性能。如果你对扩展关系型数据库的艰辛深有体会，一定会觉得这是个好消息。但并非每个人都需要扩展数据库，也许需要的就只是一台数据库服务器，那么为什么要使用MongoDB呢？
MongoDB之所以一下子这么引人注意，并不是因为它的扩展策略，而是因为它那直观的数据模型。假设基于文档的数据模型可以表示丰富的、有层级的数据结构，那么抛弃关系型数据库所强加的复杂的多表关联就成为了可能。举例来说，假设你正在为一个电子商务网站做产品建模，如果使用完全正规化的关系型数据模型，任何产品的信息可能都会被打散到多张表中。如果想要从数据库Shell里获得产品表述，我们需要写一句由join堆砌而成的复杂SQL查询。其结果就是，大多数开发者需要依赖软件中的辅助模块将数据组装成有意义的东西。
相比之下，使用文档模型的话，大多数产品信息都能放在一个文档里。打开MongoDB JavaScript Shell，可以轻松获得产品的完整表述，所有信息都按层级用一种类似JSON1的结构组织在一起。对于这样组织的所有信息，既可以做查询，也可以做其他操作。MongoDB的查询是专门为操作结构化文档而设计的，因此从关系型数据库切换过来的用户能有与之前类似的查询体验。此外，大多数开发者现在都使用面向对象的语言，他们想要一个能更好地映射到对象的数据存储。有了MongoDB，编程语言中定义的对象能被“原封不动”地持久化，消除掉一些对象映射程序的复杂性。
1. JSON是JavaScript Object Notation的缩写。我们马上就会看到，JSON结构由键和值组成，它们可以任意嵌套。JSON类似于其他编程语言中的字典（dictionary）和散列图（hash map）。
如果你对表列数据（tabular）和数据的对象表示之间的区别还很陌生，那么肯定会有很多问题。在本章末尾，我将给出MongoDB的特性和设计目标的完整概述，让你更清楚地明白为什么像Geek.net（SourceForge.net）和纽约时报（The New York Times）这样的公司的开发者要在他们的项目中使用MongoDB。我们将了解MongoDB的历史，认识它的主要特性。接下来，我们还要了解一些其他的数据库解决方案和所谓的NoSQL运动2，我会解释MongoDB在其中发挥的作用。最后，我还将概括说明MongoDB适用于哪些场景，在哪些场景下其他数据存储又可能会更合适一些。
2. NoSQL这个词出现于2009年，当时很多非关系型数据库越来越流行，NoSQL是它们的总称。