NOSQL Document Store DB进行哪些真实用例？

Question

在过去的几天中，我一直在阅读文档并观看特定于Mongo DB的屏幕截图，而当这样的解决方案比典型的PG或MySQL环境更好时，我感到不知所措。

具体来说，我的问题是在什么情况下（如果没有用例，则不错）您想走NOSQL路线吗？

谢谢！

Answer 1

1. 许多不同的作家。尤其是当作家由于网络中的断开连接而被分割时，后来需要重新同步数据，这些数据已写入分叉的两边。这会破坏酸，尽管您可以通过明确的业务逻辑解决问题，但您现在在NOSQL领域。这在军事情况下非常普遍，但是每个人都是多产作家的系统都会在酸系统上有一些写作锁定。

2. 流体模式。在传统数据库中更改模式是一个昂贵的操作，通常需要某种服务器停机时间或其他复杂的过程。对于大多数NOSQL系统，这都是微不足道的。因此，如果您从许多不同的来源中获得了合并和/或可能需要在以后开始跟踪新信息的情况，则NOSQL系统将更容易处理。合并两个数据源，以便可以彼此绘制它们是一个很好的例子。

3. 低型带宽复制。一旦打破了酸，您就可以在网络图的叶子节点上有读者和作家，其中有部分数据，这些数据不需要数据库的完整复制品。我自己的公司的产品，陆军的未来指挥所使用。

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

5. 大规模缩放。这是最常见的辩论，最常被NOSQL支持者滥用。如果这是您选择NOSQL的唯一原因，请从MySQL开始，然后稍后扩展。

Answer 2

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

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

MongoDB（也适合我们）的其他流行用例是统计收集，它在递增文档内部的特定属性方面非常有效，比大多数RDBMS系统要多得多。

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

Answer 3

一些REST API返回JSON数据（例如，许多 打开政府数据API）。如果要将其余数据转移到本地数据存储（如果您需要运行分析等）中，则用MongoDB摄入JSON对象是微不足道的。无需定义表模式。更好的是，如果JSON对象随时间变化（例如，REST API返回其他字段），您仍然可以在一个步骤中摄入数据。使用关系数据库尝试一下！