以下是事实：
-
答案 0 :(得分：3)
让我们回顾一下：
我们每天都有很多（L O T）数据。
NoSQL解决方案基本上都是为了扩展到大数（Riak，MongoDB，Cassandra等）而创建的。
...标题比其他标题更频繁地出现，没有真正的标准......要上传到mySQL数据库的每个文件的规范化非常耗时并且经常促使我们改变模式
NoSQL绝对适合这个模型，其中许多都是“无模式”，所以很容易存储这些额外的字段。但是，这会花费额外的空间，因为字段名称通常与文档一起存储。
只要提供密钥，“面向文档”和“键值”数据库就非常适合这种情况。如果必须运行重复检查，那么大多数键值数据库都配备不足。 “面向文档”的数据库可能稍微好一些，但不是很多。虽然主键是唯一的，但其他任何内容都可以重复
我们可以为同一个人发送多封电子邮件
这些数据库中的大多数都有一些“数组作为基本类型”的概念。 CouchDB和MongoDB都将对象存储为JSON，因此很容易看到客户如何拥有一组电子邮件而无需“连接表”。 MongoDB还提供“原子更新”功能，如“$ addToSet”，可以很好地与数组配合使用。
我们阅读了70％的时间，而且我们写了30％的时间 可扩展性可能是一个问题，但它现在不是，虽然可用性是关键
主要的NoSQL DB都设计为 scale 。 （包括读写）
可用性的唯一方法是通过硬件和位置冗余（与MySQL或其他数据库没有区别）。尽管版本号较低，但许多大型公司正在生产环境中使用这些数据库，因此涵盖了许多简单案例。它仍然是处女地，但我们也经历了“当没有任何改变时随机崩溃”阶段。
速度是我们正在寻找的... Schema less noSQL似乎很有吸引力。你会推荐什么，你实施了什么？
我们在MongoDB中拥有100多个灵活的用户记录。个人寻求的表现真的很棒。
但是，您必须对正在运行的查询类型保持警惕。
如果您需要同时运行带回多个用户的查询，那么基本上任何这些键值或面向文档的数据库都会出现速度问题。您可能需要查看Graph数据库或其他一些奇特的解决方案。但是，如果您的用例一次只围绕一个用户，那么请查看MongoDB。
MongoDB还支持本机map-reduce，因此您可以扩展“非实时”查询。