使用NoSQL Document Store数据库有哪些实际用例？

Question

过去几天我一直在阅读文档和观看Mongo DB特有的截屏视频，当这样的解决方案比典型的pg或mysql环境更好时，我感到很茫然。

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

谢谢！

Answer 1

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

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

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

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

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

Answer 2

使用案例
我们将MongoDB用于大规模的瞬态数据结构。 它实际上可以作为作业跟踪器/管理器，每秒处理许多工作单元。 工作单元没有定义的模式（不同的单元是经常发明的）但我们需要能够查询特定的字段或属性而无需迭代整个数据库。 所以回顾一下： 对于在云中运行的单个“商品”机器，工作负载大约为600QPS，具有高度瞬态，高可用性（无法阻止查询）。

事实上，在SQL机器上执行相同操作同时仍然保持相同的成本非常困难。

MongoDB的其他流行用例（也适用于我们）是统计信息收集，它在递增文档中的特定属性方面非常有效，远远超过大多数RDBMS系统。

同样，并不是说在MySQL中这样做是不可能的，它只是更昂贵，需要更多时间（更多技能），对于小公司或快速开发环境来说意味着它无法完成。

Answer 3

某些REST API返回JSON数据（例如，许多open government data APIs）。如果要将REST数据转储到本地数据存储（如果需要运行分析等），使用MongoDB提取JSON对象是微不足道的。无需定义表架构。更好的是，如果JSON对象随时间发生变化（例如REST API返回其他字段），您仍然可以一步摄取数据。尝试使用关系数据库！