我想测试一下NoSQL世界 . 这只是好奇心，而不是绝对需要（尚未） . 我已经阅读了一些有关SQL和NoSQL数据库之间差异的信息 . 我确信潜在的优势，但我有点担心NoSQL不适用的情况 . 如果我理解NoSQL数据库本质上错过了ACID属性 .
有人可以给出ACID关系数据库可以处理的一些真实世界操作（例如电子商务站点，或科学应用程序，或......）的示例，但NoSQL数据库可能会失败，无论是系统地某种类型竞争条件还是停电等？
如果没有修改数据库引擎，那么完美的例子就是没有任何解决方法 . NoSQL数据库表现不佳的例子最终会成为另一个问题，但在这里我想看看理论上我们什么时候不能使用这种技术 .
也许找到这样的例子是数据库特定的 . 如果是这种情况，那么让MongoDB代表NoSQL世界 .
编辑：澄清这个问题我不想讨论哪种数据库对某些情况更好 . 我想知道这种技术在某些情况下是否会成为绝对的死胡同，因为无论我们如何努力尝试SQL数据库提供的某些功能，都可以在nosql商店之上实现 . 由于有许多nosql商店可用，我可以接受选择现有的nosql商店作为支持，但我最感兴趣的是商店应该提供的最小功能子集，以便能够实现更高级别的功能（比如可以使用不提供X的商店...） .
6 回答
这个问题有点像问什么类型的程序不能用命令式/函数式语言编写 . 任何图灵完整的语言，并表达可以通过图灵缓存解决的每个程序 . 问题是，作为一名程序员，您真的想在非便携式机器指令中为财富500强企业编写会计系统 .
最后，NoSQL可以做任何基于SQL的引擎都能做到的，不同之处在于程序员可能会负责MySQL中免费提供的Redis中的逻辑 . SQL数据库对数据完整性采取非常保守的观点 . NoSQL运动放宽了这些标准，以获得更好的可扩展性，并使Web应用程序常见的任务变得更容易 .
MongoDB（我目前的偏好）使复制和分片（水平缩放）变得容易，插入速度非常快，并且不再需要严格的方案 . 作为交换，当索引不存在时，MongoDB的用户必须编写较慢的查询代码，在应用程序中实现事务逻辑（可能具有三阶段提交），并且我们会对存储效率产生影响 .
CouchDB具有类似的权衡，但也牺牲了即时查询，以便能够脱机处理数据，然后与服务器同步 .
Redis和其他键值存储需要程序员编写大部分索引并加入内置于SQL数据库的逻辑 . 作为交换，应用程序可以利用有关其数据的领域知识，使索引和连接比SQL所需的通用解决方案更有效 . Redis还要求所有数据都适合RAM，但作为交换，性能与Memcache相当 .
最后，你真的可以做任何MySQL或Postgres所做的一切，只有操作系统文件系统命令（毕竟这是编写这些数据库引擎的人做的事情） . 这一切都归结为您希望数据存储为您做什么以及您愿意放弃的回报 .
好问题 . 首先澄清一下 . 虽然关系存储领域由一个相当坚实的原则基础结合在一起，每个供应商选择增加功能或定价的 Value ，但非关系（nosql）领域更加异构 .
有文档存储（MongoDB，CouchDB），它们非常适合内容管理和类似情况，在这种情况下，您需要围绕主题构建一组平面变量属性 . 进行网站定制 . 使用文档存储来管理定义用户想要查看其页面的方式的自定义属性非常适合该平台 . 尽管他们的营销炒作，这些商店往往不会很好地扩展到太字节 . 它可以做到，但它并不理想 . MongoDB有很多功能在关系数据库中，例如动态索引（每个集合/表最多40个） . CouchDB可在发生故障时完全恢复 .
有一些键/值存储（Cassandra，HBase ......）非常适合高度分布式存储 . Cassandra用于低延迟，HBase用于更高延迟 . 这些技巧就是你必须在开始放入数据之前定义你的查询需求 . 它们对于任何属性的动态查询效率都不高 . 例如，如果要构建客户事件记录服务，则需要在客户的唯一属性上设置密钥 . 从那里，您可以将各种日志结构推送到您的商店，并按需按客户键检索所有日志 . 但是，尝试查看日志事件（类型为“失败”）的日志会更加昂贵，除非您决定将其作为辅助密钥 . 另一件事：我最后一次看Cassandra时，你无法在M / R查询中运行正则表达式 . 意味着，如果您想在字段中查找模式，则必须拉出该字段的所有实例，然后通过正则表达式运行它以查找所需的元组 .
图形数据库与上面的两个非常不同 . 项目（对象，元组，元素）之间的关系是流动的 . 它们不会扩展到太字节，但这不是它们的设计目标 . 他们非常善于提出诸如“嘿，有多少用户喜欢绿色的问题？这些，有多少人住在加利福尼亚？”使用关系数据库，您将拥有静态结构 . 使用图形数据库（当然，我过于简单化），您拥有属性和对象 . 您可以在没有架构实施的情况下将它们连接起来 .
我不会把任何关键任务放到非关系型商店中 . 例如，Commerce，您需要在交付产品之前保证交易完成 . 您需要保证完整性（或至少保证完整性的最佳机会） . 如果用户丢失他/她的网站自定义设置，没什么大不了的 . 如果你失去了商业交易，那么大不了 . 可能有些人不同意 .
我也不会将复杂的结构放入任何上述非关系存储中 . 它们并没有很好地连接 . 而且，这没关系，因为它不是他们应该工作的方式 . 如果您可以将address_type的标识放入关系系统的customer_address表中，您可能希望将address_type信息嵌入存储在文档或键/值中的客户元组中 . 数据效率不是文档或键/值存储的域 . 关键是分配和纯粹的速度 . 牺牲是足迹 .
这个商店的其他子类型标记为“nosql”，我在这里没有涉及 . 有很多（最后计数122个）不同的项目专注于各种类型的数据问题的非关系解决方案 . Riak是我一直听到的另一个，迫不及待想要尝试 .
这就是诀窍 . 这些大型美元的关系供应商一直在关注和机会，他们都在 Build 或计划 Build 自己的非关系型解决方案以配合他们的产品 . 在接下来的几年里，如果不是更早的话，我们会看到这一运动成熟，大公司购买最好的品牌，关系供应商开始提供集成解决方案，对于那些尚未购买的产品 .
在数据管理领域工作是一个非常激动人心的时刻 . 你应该尝试其中的一些 . 您可以下载Couch或Mongo，并在几分钟内启动并运行它们 . HBase有点困难 .
在任何情况下，我希望我没有混淆地通知我，我没有明显的偏见或错误 .
RDBMS擅长连接，NoSQL引擎通常不擅长 . NoSQL引擎擅长分布式可伸缩性，而RDBMS通常不是 .
RDBMS擅长数据验证共同安装，NoSQL引擎通常不擅长 . NoSQL引擎擅长灵活且无模式的方法，而RDBMS通常不是 .
这两种方法都可以解决一系列问题;差异在于效率 .
可能回答你的问题是mongodb可以处理任何任务（以及sql） . 但在某些情况下更好地选择mongodb，在别人的sql数据库中 . 关于优点和缺点，你可以阅读here .
此外，正如@Dmitry所说，mongodb打开门，便于水平和垂直缩放，复制和分片 .
RDBMS强制执行强一致性，而大多数no-sql最终是一致的 . 所以在给定的从no-sql DB读取数据的时间点，它可能不代表该数据的最新副本 .
一个常见的例子是银行交易，当用户提款时，节点A用这个事件更新，如果同时节点B查询该用户的余额，它可以返回过时的余额 . 这在RDBMS中不会发生，因为一致性属性可以保证数据在被读取之前得到更新 .
RDBM非常适合快速汇总表中的总和，平均值等 . 例如
SELECT SUM(x) FROM y WHERE z. 如果你想立刻得到一个答案，那么在大多数NoSQL数据库中都很难做到这一点 . 一些NoSQL存储提供map / reduce作为解决同一事物的方法，但它不像SQL世界那样实时 .