好问题。首先澄清一下。虽然关系存储领域是由相当坚实的原则基础组成的，每个供应商都选择在功能或定价方面增加价值，但非关系 (nosql) 领域的异构性要大得多。
有一些文档存储（MongoDB、CouchDB）非常适合内容管理和类似情况，在这些情况下，您需要围绕某个主题构建一组扁平的变量属性。采取网站定制。使用文档存储来管理定义用户希望查看其页面的方式的自定义属性非常适合该平台。尽管他们在营销上大肆宣传，但这些商店的规模并没有那么好。可以做到，但并不理想。MongoDB 有很多关系数据库中的特性，例如动态索引（每个集合/表最多 40 个）。CouchDB 被构建为在发生故障时绝对可恢复。
有非常适合高度分布式存储的键/值存储（Cassandra、HBase...）。Cassandra 用于低延迟，HBase 用于更高延迟。这些技巧是您必须在开始输入数据之前定义查询需求。它们对于针对任何属性的动态查询效率不高。例如，如果您正在构建客户事件记录服务，您可能希望将密钥设置在客户的唯一属性上。从那里，您可以将各种日志结构推送到您的存储中，并根据需要通过客户密钥检索所有日志。但是，除非您决定将其设置为辅助键，否则尝试通过日志查找类型为“失败”的日志事件会更加昂贵。另一件事：我上次看 Cassandra 时，你不能 t 在 M/R 查询中运行正则表达式。这意味着，如果您想在字段中查找模式，则必须提取该字段的所有实例，然后通过正则表达式运行它以找到您想要的元组。
图数据库与上述两个非常不同。项目（对象、元组、元素）之间的关系是流动的。它们不会扩展到 TB，但这不是它们的设计目的。它们非常适合提出诸如“嘿，我的用户中有多少喜欢绿色？其中有多少人住在加利福尼亚？”之类的问题。使用关系数据库，您将拥有静态结构。使用图形数据库（当然，我过于简单化了），您就有了属性和对象。您可以合理地连接它们，而无需执行模式。
我不会将任何重要的东西放入非关系存储中。例如，在商业领域，您希望在交付产品之前保证交易已完成。您想要保证完整性（或至少有保证完整性的最佳机会）。如果用户丢失了他/她的站点自定义设置，没什么大不了的。如果你失去了一笔商业交易，那就大不了了。可能有人不同意。
我也不会将复杂的结构放入上述任何非关系存储中。他们不能很好地进行大规模连接。而且，这没关系，因为这不是他们应该工作的方式。如果您可能将 address_type 的身份放入关系系统中的 customer_address 表中，您可能希望将 address_type 信息嵌入存储在文档或键/值中的客户元组中。数据效率不是文档或键/值存储的领域。重点是分布和纯粹的速度。牺牲是足迹。
商店系列的其他子类型标记为“nosql”，我在这里没有介绍。有大量（最后统计为 122 个）不同的项目专注于针对各种类型的数据问题的非关系解决方案。Riak 是我一直听说的另一个，迫不及待想尝试一下。
这就是诀窍。大额关系供应商一直在关注，而且很有可能，他们都在构建或计划构建自己的非关系解决方案以与他们的产品相结合。在接下来的几年里，如果不是更早的话，我们将看到这一运动变得成熟，大公司收购最好的品种，关系供应商开始为那些还没有的供应商提供集成解决方案。
在数据管理领域工作是一个非常激动人心的时刻。你应该尝试其中的一些。您可以下载 Couch 或 Mongo 并在几分钟内启动并运行它们。HBase 有点难。
无论如何，我希望我在没有混淆的情况下告知我，我已经开悟了，没有明显的偏见或错误。