我习惯于使用关系数据库（如MySQL或PostgreSQL），并与诸如Symfony，RoR或Django的MVC框架结合使用，我认为它很好用。
但是最近我听到了很多有关MongoDB的信息，MongoDB是一个非关系型数据库，或者引用官方定义，
可扩展，高性能，开源，无模式，面向文档的数据库。
我真的很感兴趣，希望了解下一个项目的所有选择，并从中选择最好的技术。
在哪种情况下，使用MongoDB（或类似数据库）比使用“经典”关系数据库更好？一般而言，MongoDB与MySQL相比有什么优势？或者至少，为什么如此不同？
如果您有文档和/或示例的指针，那也将有很大帮助。
Answers:
以下是MongoDB用于构建Web应用程序的一些优点：
您需要阅读更多有关它的内容并尝试使用它，以获得更好的主意。这是一个在线演示：
有许多优点。
例如，您的数据库架构将具有更高的可伸缩性，您不必担心迁移，代码将更易于编写...例如，这是我的模型代码之一：
class Setting
include MongoMapper::Document
key :news_search, String, :required => true
key :is_availaible_for_iphone, :required => true, :default => false
belongs_to :movie
end
添加密钥只是添加一行代码！
从长远来看，还有其他优点，例如更好的可调用性和速度。
... 但是请记住，非关系数据库并不比关系数据库好。如果您的数据库有很多关系和规范化，那么使用像MongoDB这样的东西可能就没什么意义了。都是为了找到适合该工作的工具。
有关更多内容，我建议您看一下“ 为什么我认为Mongo对数据库而言，而Rails对框架而言 ”或mongodb网站上的这篇文章。要感到兴奋，如果您会讲法语，请看一下这篇文章，其中介绍了如何从头开始设置MongoDB。
无模式的优点在于，您可以转储其中的任何负载，而且没有人会抱怨它或说错了。
这也意味着，无论您转储其中的内容，执行此操作后都将完全没有意义。
有些人会贴上严重的劣势，有些则不会。
关系数据库具有完善的架构这一事实是由于它具有一套完善的扩展谓词这一事实的结果，这些扩展谓词使我们能够将含义附加到数据库中记录的内容以及这也是我们这样做的必要先决条件。
没有完善的模式，没有扩展谓词，也没有扩展谓词，用户将无法从填充的内容中获得任何意义。
MongoDB在本周的FLOSS每周活动中精选-http: //twit.tv/floss105 一个使用类似概念的数据库是CouchDB，该数据库在另一个FLOSS每周新闻中精选：http：//twit.tv/floss36
在使用我的项目中的两个数据库后，我在Postgres和Mongo的经验。
Postgres（RDBMS）
如果您将来的应用程序具有需要大量联接的复杂架构，或者所有数据都具有关联性，或者如果我们撰写大量文章，则建议使用Postgres。Postgres是开源的，更快的，符合ACID的并且在磁盘上使用的内存更少，并且在JSON存储方面表现良好，并且具有3个级别的事务隔离级别，包括事务的完全可序列化性。
住在Postgres的最大优势是我们两全其美。我们可以以约束，一致性和速度将数据存储到JSONB中。另一方面，我们可以将所有SQL功能用于其他类型的数据。底层引擎非常稳定，可以很好地应对各种数据量。它还可以在您选择的硬件和操作系统上运行。Postgres提供NoSQL功能以及完整的事务支持，存储对字段数据有约束的JSON文档。
Postgres的一般约束
水平扩展Postgres难度较大，但可行。
使用Postgres不能完全实现快速读取操作。
没有SQL数据库
Mongo DB（有线老虎）
MongoDB可能在“水平规模”方面击败Postgres。存储JSON是Mongo经过优化的工作。Mongo以一种称为BSONb的二进制格式存储其数据，（大约）只是JSON超集的二进制表示形式。MongoDB完全按照设计存储对象。根据MongoDB的说法，对于写密集型应用程序，Mongo表示，新引擎（Wired Tiger）为用户提供了高达10倍的写性能提升（我应该尝试这样做），并将存储利用率降低了80％，从而有助于降低存储成本，实现更高的硬件利用率。
MongoDb的一般约束
使用较少模式的存储引擎会导致隐式模式的问题。这些架构不是由我们的存储引擎定义的，而是根据应用程序的行为和期望定义的。
独立NoSQL技术不符合ACID标准，因为它们牺牲了关键数据保护，而为非结构化应用程序提供了高吞吐量性能。在NoSQL数据库上应用ACID并不难，但在一定程度上会使数据库变慢且缺乏灵活性。“大多数NoSQL限制已在较新版本和发行版中进行了优化，这些新版本在很大程度上克服了其先前的限制”。
这都是权衡取舍。MongoDB速度很快，但不是ACID，它没有事务。在某些用例中它比MySQL更好，而在另一些用例中则更糟。
MongoDB中编写的波纹管线：权威指南。
有几个很好的理由：
- 将不同种类的文档保存在同一集合中可能是开发人员和管理员的噩梦。开发人员需要确保每个查询仅返回某种类型的文档，或者执行查询的应用程序代码可以处理不同形状的文档。如果我们要查询博客文章，那么清除包含作者数据的文档很麻烦。
- 获取集合列表比提取集合中的类型列表要快得多。例如，如果我们在集合中有一个类型键，说明每个文档是“略读”，“整个”还是“矮胖的猴子”文档，那么在单个集合中查找这三个值将比在其中查找慢得多。有三个单独的集合并查询其名称
- 在同一集合中将相同类型的文档分组在一起可以实现数据局部性。从仅包含帖子的集合中获取多个博客帖子，与从包含帖子和作者数据的集合中获取相同帖子相比，可能需要更少的磁盘搜索。
- 创建索引时，我们开始在文档上施加一些结构。（在唯一索引的情况下尤其如此。）这些索引是针对每个集合定义的。通过仅将单一类型的文档放入同一集合中，我们可以更有效地索引我们的集合
在询问带有文本存储的数据库之后，我浏览了MongoDB和类似的系统。
如果我理解正确，它们应该更易于使用和设置，并且速度更快。也许由于缺少SQL会阻止SQL注入，因此也更加安全。
显然，MongoDB主要用于Web应用程序。
从根本上说，这些数据库本身并不适合复杂的查询，数据挖掘等。但是它们擅长快速检索大量平面数据。