6

在过去的几天里，我一直在阅读文档并观看特定于 Mongo DB 的截屏视频，当这样的解决方案比典型的 pg 或 mysql 环境更好时，我不知所措。

具体来说，我的问题是在什么情况下（带有用例会很好）你想走 nosql 路线？

谢谢！

4

3 回答 3

10

  1. 许多不同的作家。特别是当写入器由于网络断开而被分段时，以后需要重新同步已写入分叉两侧的数据。这破坏了 ACID，虽然您可以使用显式业务逻辑解决问题，但您现在处于 NoSQL 领域。这在军事情况下很常见，但是任何人人都是多产作家的系统都会在 ACID 系统上设置一些写争用锁。

  2. 流体模式。更改传统数据库中的模式是一项昂贵的操作，通常需要某种服务器停机时间或其他复杂的过程。对于大多数 NoSQL 系统来说，这是微不足道的。因此，如果您有来自许多不同来源的数据要合并和/或您可能希望在以后开始跟踪新信息，那么 NoSQL 系统将更容易处理。合并两个数据源以便彼此绘制图表是我能想到的一个很好的例子。

  3. 低带宽复制。一旦您破坏了 ACID，您就可以在网络图的叶节点上拥有读取器和写入器，其中包含不需要数据库的完整副本的部分数据。我自己公司的产品，未来的陆军指挥所使用这个。

  4. 数据互操作性。大多数 NoSQL 数据库允许您在不提前知道架构的情况下内省数据，从而使不同系统之间的连接更容易发生。

  5. 大规模缩放。这是最常争论的问题，也是 NoSQL 支持者最常滥用的问题。如果这是您选择 NoSQL 的唯一原因，请从 MySQL 开始，然后再进行扩展。

于 2010-09-01T19:35:28.227 回答
8

Use Case
We use MongoDB for a large scale extremely transient data structure. It in effect works as a job tracker / manager with many work units being processed every second. The work unit has no defined schema (different units are invented somewhat frequently) yet we need to have the ability to query for specific fields or properties without iterating over the entire DB. So to recap: highly transient, highly available (can't afford to block for a query) with a work load of approximately 600QPS for a single "commodity" machine running in the cloud.

Fact of the matter is it is extremely difficult to do the same on a SQL machine while still maintaining the same costs.

Other popular use cases for MongoDB (also for us) are statistic collection, it is extremely efficient at incrementing specific properties inside documents, much more so then most RDBMS systems.

Again, it's not that it is impossible to do so in MySQL it's just more expensive and takes more time (more skill) which for a small company or a fast development environment means it can't be done.

于 2010-09-01T19:42:33.417 回答
7

一些 REST API 返回 JSON 数据（例如，许多开放的政府数据 API）。如果您想将 REST 数据转储到本地数据存储（以防您需要运行分析等），使用 MongoDB 摄取 JSON 对象是微不足道的。无需定义表模式。更好的是，如果 JSON 对象随时间发生变化（例如 REST API 返回附加字段），您仍然可以一步获取数据。尝试使用关系数据库！

于 2010-09-05T07:28:23.483 回答