使用 NoSQL 文档存储数据库有哪些实际用例？
在过去的几天里，我一直在阅读文档并观看特定于 Mongo DB 的截屏视频，我不知道像这样的解决方案何时会比典型的 pg 或 mysql 环境更好。
具体来说，我的问题是在什么情况下（有用例就很好）你会选择 nosql 路线？
谢谢！
I have been reading documentation and watching screencasts specific to Mongo DB over the past few days and I am at a loss for when a solution like this would be better than a typical pg or mysql environment.
Specifically, my question is under what circumstance (w/ use case would be nice) would you want to go the nosql route?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
许多不同的作家。特别是当写入器由于网络断开而被分段，并且稍后需要重新同步已写入分叉两侧的数据时。这破坏了 ACID，虽然您可以使用显式业务逻辑解决问题，但您现在处于 NoSQL 领域。这在军事情况下很常见，但是任何每个人都是多产写入者的系统都会在 ACID 系统上有一些写入争用锁定。
流动模式。更改传统数据库中的模式是一项昂贵的操作，通常需要某种服务器停机或其他复杂的过程。对于大多数 NoSQL 系统来说，这都是微不足道的。因此，如果您需要合并来自许多不同来源的数据和/或您可能希望稍后开始跟踪新信息，那么 NoSQL 系统将更容易处理。我能想到的一个很好的例子就是合并两个数据源，以便将它们彼此绘制成图表。
低带宽复制。一旦破坏了 ACID，您就可以在网络图的叶节点上使用部分数据的读取器和写入器，而无需数据库的完整副本。我自己公司的产品，陆军未来指挥所就使用了这个。
数据互操作性。大多数 NoSQL 数据库允许您在不提前了解架构的情况下内省数据，从而使不同系统之间的连接更容易。
大规模扩展。这是最常引起争议的问题，也是 NoSQL 支持者最常滥用的问题。如果这是您选择 NoSQL 的唯一原因，请先从 MySQL 开始，然后再扩展。
Many disparate writers. Especially when the writers can get segmented due to disconnections in the network, and will later need to resync data that has been written to on both sides of the bifurcation. This breaks ACID, and while you can solve the problem with explicit business logic, you're now in NoSQL territory. This is very common in military situations, but any system in which everyone is a prolific writer is going to have some write-contention lock on an ACID system.
Fluid schemas. Changing a schema in a traditional DB is an expensive operation that often requires some sort of server downtime or other complicated processes. With most NoSQL systems it's trivial. So if you've got data from a lot of disparate sources to merge and/or have situations where you may want to start tracking new information at a later date, NoSQL systems will be a lot easier to deal with. Merging two data sources so they can be charted with each other is a good example I can think of.
Low-bandwidth replication. Once you've broken ACID you can have readers and writers on leaf nodes of a network graph with partial data which don't need full replicas of the database. My own company's product, the Army's Command Post of the Future uses this.
Data interoperability. Most NoSQL databases allow you to introspect the data without knowing the schema ahead of time, allowing connections between disparate systems to happen easier.
Massive scaling. This is the one that is most-often debated, and most often abused by NoSQL proponents. If this is the only reason you're choosing NoSQL, start with MySQL instead and scale later.
用例
我们使用 MongoDB 来处理大规模且极其瞬态的数据结构。
它实际上充当作业跟踪器/管理器，每秒处理许多工作单元。
工作单元没有定义的模式（不同的单元经常被发明），但我们需要能够查询特定字段或属性，而无需迭代整个数据库。
回顾一下：
高度瞬态、高度可用（无法承受查询阻塞），对于在云中运行的单个“商品”机器，工作负载约为 600QPS。
事实上，在 SQL 机器上做同样的事情同时保持相同的成本是极其困难的。
MongoDB（也适用于我们）的其他流行用例是统计收集，它在增加文档内的特定属性方面非常有效，比大多数 RDBMS 系统更有效。
再说一次，这并不是说在 MySQL 中不可能这样做，只是更昂贵并且需要更多的时间（更多的技能），这对于小公司或快速的开发环境意味着这是不可能完成的。
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.
某些 REST API 返回 JSON 数据（例如，许多开放政府数据 API）。如果您想将 REST 数据转储到本地数据存储（以防您需要运行分析等），则使用 MongoDB 摄取 JSON 对象非常简单。无需定义表模式。更好的是，如果 JSON 对象随时间发生变化（例如，REST API 返回其他字段），您仍然可以一步提取数据。尝试使用关系数据库！
Some REST APIs return JSON data (for example, many of the open government data APIs). If you want to dump the REST data to a local data store (in case you need to run analysis, etc), ingesting a JSON object with MongoDB is trivial. No need to define a table schema. Even better, if the JSON object changes over time (e.g. the REST API returns additional fields) you can still ingest the data in one step. Try that with a relational database!