【发布时间】：2010-09-01 19:22:41
【问题描述】：
在过去的几天里，我一直在阅读文档并观看特定于 Mongo DB 的截屏视频，我不知道这样的解决方案何时会比典型的 pg 或 mysql 环境更好。
具体来说，我的问题是在什么情况下（带有用例会很好）你想走 nosql 路线？
谢谢！
【问题讨论】：
标签： mongodb use-case document-storage database nosql
【发布时间】：2010-09-01 19:22:41
【问题描述】：
许多不同的作家。特别是当写入器由于网络断开而被分段时，以后需要重新同步已写入分叉两侧的数据。这破坏了 ACID，虽然您可以使用显式业务逻辑解决问题，但您现在处于 NoSQL 领域。这在军事情况下很常见，但任何人人都是多产作家的系统都会在 ACID 系统上设置一些写争用锁。
流动模式。更改传统数据库中的模式是一项昂贵的操作，通常需要某种服务器停机时间或其他复杂的过程。对于大多数 NoSQL 系统来说，这是微不足道的。因此，如果您有来自许多不同来源的数据要合并和/或您可能希望在以后开始跟踪新信息，那么 NoSQL 系统将更容易处理。合并两个数据源以便相互绘制图表是我能想到的一个很好的例子。
低带宽复制。一旦您破坏了 ACID，您就可以在网络图的叶节点上拥有读取器和写入器，其中包含不需要数据库的完整副本的部分数据。我自己公司的产品，未来陆军指挥所使用这个。
数据互操作性。大多数 NoSQL 数据库允许您在不提前知道架构的情况下对数据进行内省，从而使不同系统之间的连接更容易发生。
大规模缩放。这是最常争论的问题，也是 NoSQL 支持者最常滥用的问题。如果这是您选择 NoSQL 的唯一原因，请从 MySQL 开始，然后再进行扩展。
【讨论】：
用例
我们将 MongoDB 用于大规模极其瞬态的数据结构。
它实际上是一个工作跟踪器/管理器，每秒处理许多工作单元。
工作单元没有定义的模式（不同的单元被频繁地发明）但我们需要能够查询特定字段或属性，而无需遍历整个数据库。
回顾一下：
对于在云中运行的单个“商品”机器，高度瞬态、高度可用（不能为查询而阻塞），工作负载约为 600QPS。
事实上，在 SQL 机器上做同样的事情同时保持相同的成本是极其困难的。
MongoDB（也适用于我们）的其他流行用例是统计收集，它在增加文档内的特定属性方面非常有效，比大多数 RDBMS 系统更有效。
再次重申，这并不是说在 MySQL 中不可能做到，只是更昂贵并且需要更多时间（更多技能），这对于小公司或快速开发环境来说意味着无法做到。
【讨论】：
一些 REST API 返回 JSON 数据（例如，许多 open government data APIs）。如果您想将 REST 数据转储到本地数据存储（以防您需要运行分析等），使用 MongoDB 摄取 JSON 对象是微不足道的。无需定义表模式。更好的是，如果 JSON 对象随时间发生变化（例如 REST API 返回附加字段），您仍然可以一步获取数据。尝试使用关系数据库！
【讨论】：