与关系数据库相比，使用类似MongoDB的无模式数据库有什么好处？
我习惯于使用像MySQL或PostgreSQL这样的关系型数据库，并结合了像Symfony，RoR或者Django这样的MVC框架，我认为它很好用。
但最近我听说很多关于MongoDB的非关系数据库，或者引用官方的定义 ，
一个可扩展的，高性能，开源，无模式，面向文档的数据库。
我真的很感兴趣，希望知道下一个项目的所有选项，并select最好的技术。
在哪些情况下使用MongoDB（或类似的数据库）比使用“经典”关系数据库更好？ MongoDB与MySQL的优势有哪些？ 或者至less，为什么它是如此不同？
如果您有指向文档和/或示例的指示，那也是非常有帮助的。
下面是MongoDB构buildWeb应用程序的一些优点：
- 基于文档的数据模型。 存储的基本单元类似于JSON，Python字典，Ruby哈希等。这是一个丰富的数据结构，能够存储数组和其他文档。 这意味着你可以经常在一个实体中表示一个构造，这个构造需要几个表在关系数据库中正确表示。 如果你的数据是不可变的，这是特别有用的。
- 深层查询能力。 MongoDB支持使用基于文档的查询语言对文档进行dynamic查询，这种查询语言几乎与SQL一样强大。
- 没有模式迁移。 由于MongoDB是无模式的，所以你的代码定义了你的模式。
- 横向扩展性的明确path。
你需要阅读更多关于它的信息，并使用它来获得更好的想法。 这是一个在线演示：
有许多优点。
例如，您的数据库模式将更具可扩展性，您不必担心迁移，编写代码会更愉快。例如，下面是我的模型代码之一：
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的东西可能没什么意义。 这一切都是为了find合适的工具。
对于更多的东西来看，我build议看看“ 为什么我认为Mongo是数据库什么Rails是框架 ”或在mongodb网站上这篇文章 。 要兴奋起来，如果你说法语，看看这篇文章解释如何从头开始设置MongoDB。
编辑：我几乎忘了告诉你Ryan的 这个railscast 。 这很有趣，让你想马上开始！
MongoDB本周在FLOSS Weekly上发布 – http://twit.tv/floss105使用类似概念的数据库是另一个FLOSS Weekly上的CouchDB： http : //twit.tv/floss36
我认为除了@marcgg提供的链接之外，还是值得一听的
无模式的好处在于，你可以抛弃任何你的负载，没有人会抱怨，也没有人会说这是错误的。
这也意味着，无论你倾倒在里面，在你这样做之后仍然完全没有意义。
有些人会认为这是一个严重的缺点，有些则不会。
关系数据库有一个完善的模式这一事实是一个事实的结果，它有一套完善的外延谓词，这就使得我们可以把意义附加到数据库中logging的内容上，也是我们这样做的一个必要的先决条件。
如果没有一个完善的模式，没有扩展的谓词，也没有扩展的精确性，用户就没有办法用它来填充任何含义。
这都是关于折衷。 MongoDB很快，但不是ACID，它没有交易。 在某些使用情况下，它比MySQL更好，而其他情况则更糟。
在使用我的项目中的两个数据库之后，我对Postgres和Mongo的经验。
Postgres的（RDBMS）
如果你将来的应用程序有一个复杂的模式，需要大量的连接，或者所有的数据都有关系，或者如果我们写的很重，那么推荐使用Postgres。 Postgres是开源的，速度更快，符合ACID标准，在磁盘上使用更less的内存，而且JSON存储性能也很好，包括3级事务隔离的完全可串行化事务。
留在Postgres的最大优势是我们两全其美。 我们可以将数据以约束，一致性和速度存储到JSONB中。 另一方面，我们可以使用其他types的数据的所有SQLfunction。 底层的引擎非常稳定，可以很好地处理大量数据。 它也运行在您select的硬件和操作系统上。 Postgres提供NoSQLfunction以及完整的事务处理支持，存储JSON文档和字段数据的约束。
Postgres的一般约束
水平缩放Postgres比较难，但可行。
Postgres无法完全实现快速读取操作。
没有SQL数据库
Mongo DB（有线老虎）
MongoDB可能在“横向规模”的维度上击败Postgres。 存储JSON是Mongo最适合做的事情。 Mongo以一种名为BSONb的二进制格式存储其数据，这个（大致）只是JSON超集的二进制表示。 MongoDB完全按照它们的devise来存储对象。 根据MongoDB的说法，对于编写密集型应用程序，Mongo说新的引擎（Wired Tiger）使用户的写入性能提高了10倍（我应该试试），存储利用率降低了80％，有助于降低存储成本，实现更高的硬件利用率。
MongoDb的一般约束
使用模式较less的存储引擎会导致隐式模式的问题。 这些模式不是由我们的存储引擎定义的，而是基于应用程序的行为和期望来定义的。
独立的NoSQL技术不符合ACID标准，因为它们牺牲了对非结构化应用的高吞吐量性能的关键数据保护。 在NoSQL数据库上应用ACI并不困难，但会在一定程度上使数据库变得缓慢和不灵活。 “大部分的NoSQL限制都在较新的版本和版本中进行了优化，这在很大程度上克服了以前的限制”。
在MongoDB中撰写的白皮书：权威指南。
有几个很好的理由：
- 在同一个集合中保存不同types的文档对于开发人员和pipe理员来说可能是一场噩梦。 开发人员需要确保每个查询只返回某种types的文档，或者执行查询的应用程序代码可以处理不同形状的文档。 如果我们查询博客post，淘汰包含作者数据的文档是一件麻烦事。
- 获取集合列表比提取集合中的types列表要快得多。 例如，如果我们在集合中有一个types键，表示每个文档是“脱脂”，“整体”还是“矮胖的猴子”文档，那么在一个集合中查找这三个值要慢得多有三个单独的集合，并查询他们的名字
- 在同一个集合中将相同types的文档分组在一起允许数据局部性。 从仅包含post的集合获取多篇博文可能需要的磁盘search次数要less于从包含post和作者数据的集合中获取相同的post。
- 当我们创build索引时，我们开始在文档上强加一些结构。 （在唯一索引的情况下尤其如此）。这些索引是按集合定义的。 通过仅将单一types的文档放入同一个集合中，我们可以更有效地索引集合
在用文本存储的数据库问题之后），我瞥了一眼MongoDB和类似的系统。
如果我理解正确，他们应该更容易使用和设置，而且要快得多。 也许也更安全，因为缺乏SQL防止SQL注入…
显然，MongoDB主要用于Web应用程序。
基本上，他们自己说，这些数据库不适合复杂的查询，数据挖掘等，但他们闪耀在快速检索大量的平面数据。
- MongoDB支持按字段search，正则expression式search。包括用户定义的Java脚本函数。
- MongoDB可以用作文件系统，利用多台机器上的负载平衡和数据复制function来存储文件。
