NoSQL数据库无法处理的任务示例(如果有)

Question

我想测试一下NoSQL世界.这只是好奇心,而不是绝对需要(尚未).我已经阅读了一些有关SQL和NoSQL数据库之间差异的信息.我确信潜在的优势,但我有点担心NoSQL不适用的情况.如果我理解NoSQL数据库本质上错过了ACID属性.

有人可以给出ACID关系数据库可以处理的一些真实世界操作(例如电子商务站点,或科学应用程序,或......)的示例,但NoSQL数据库可能会失败,无论是系统地某种类型竞争条件还是停电等？

如果没有修改数据库引擎,那么完美的例子就是没有任何解决方法.NoSQL数据库表现不佳的例子最终会成为另一个问题,但在这里我想看看理论上我们什么时候不能使用这种技术.

也许找到这样的例子是数据库特定的.如果是这种情况,那么让MongoDB代表NoSQL世界.

编辑:澄清这个问题我不想讨论哪种数据库对某些情况更好.我想知道在某些情况下这项技术是否绝对是一个绝对的死胡同,因为无论我们如何努力尝试某种类型的功能,SQL数据库提供的功能都无法在nosql商店之上实现.由于有许多nosql商店可用,我可以接受选择现有的nosql商店作为支持,但我最感兴趣的是商店应该提供的最小功能子集,以便能够实现更高级别的功能(比如可以使用不提供X的商店...).

Answer 1

这个问题有点像问什么类型的程序不能用命令式/函数式语言编写.任何图灵完整的语言,并表达可以通过图灵缓存解决的每个程序.问题是,作为一名程序员,您真的想在非便携式机器指令中为财富500强企业编写会计系统.

最后,NoSQL可以做任何基于SQL的引擎都能做到的,不同之处在于程序员可能会负责MySQL中免费提供的Redis中的逻辑.SQL数据库对数据完整性采取非常保守的观点.NoSQL运动放宽了这些标准,以获得更好的可扩展性,并使Web应用程序常见的任务变得更容易.

MongoDB(我目前的偏好)使复制和分片(水平缩放)变得容易,插入速度非常快,并且不再需要严格的方案.作为交换,当索引不存在时,MongoDB的用户必须编写较慢的查询代码,在应用程序中实现事务逻辑(可能具有三阶段提交),并且我们会对存储效率产生影响.

CouchDB具有类似的权衡,但也牺牲了即时查询,以便能够脱机处理数据,然后与服务器同步.

Redis和其他键值存储需要程序员编写大部分索引并加入内置于SQL数据库的逻辑.作为交换,应用程序可以利用有关其数据的领域知识,使索引和连接比SQL所需的通用解决方案更有效.Redis还要求所有数据都适合RAM,但作为交换,性能与Memcache相当.

最后,你真的可以做任何MySQL或Postgres所做的一切,只有操作系统文件系统命令(毕竟这是编写这些数据库引擎的人做的事情).这一切都归结为您希望数据存储为您做什么以及您愿意放弃的回报.

Answer 2

好问题.首先澄清一下.虽然关系存储领域由一个相当坚实的原则基础结合在一起,每个供应商选择增加功能或定价的价值,但非关系(nosql)领域更加异构.

有文档存储(MongoDB,CouchDB),它们非常适合内容管理和类似情况,在这种情况下,您需要围绕主题构建一组平面变量属性.进行网站定制.使用文档存储来管理定义用户想要查看其页面的方式的自定义属性非常适合该平台.尽管他们的营销炒作,这些商店往往不会很好地扩展到太字节.它可以做到,但它并不理想.MongoDB在关系数据库中有许多功能,例如动态索引(每个集合/表最多40个).CouchDB可在发生故障时完全恢复.

有一些键/值存储(Cassandra,HBase ......)非常适合高度分布式存储.Cassandra用于低延迟,HBase用于更高延迟.这些技巧就是你必须在开始放入数据之前定义你的查询需求.它们对于任何属性的动态查询效率都不高.例如,如果要构建客户事件记录服务,则需要在客户的唯一属性上设置密钥.从那里,您可以将各种日志结构推送到您的商店,并按需按客户键检索所有日志.但是,尝试查看日志事件(类型为"失败")的日志会更加昂贵,除非您决定将其作为辅助密钥.另一件事:我最后一次看Cassandra时,你无法在M/R查询中运行正则表达式.意味着,如果您想在字段中查找模式,则必须拉出该字段的所有实例,然后通过正则表达式运行它以查找所需的元组.

图形数据库与上面的两个非常不同.项目(对象,元组,元素)之间的关系是流动的.它们不会扩展到太字节,但这不是它们的设计目标.他们非常善于提出诸如"嘿,有多少用户喜欢绿色的问题？这些,有多少人住在加利福尼亚？" 使用关系数据库,您将拥有静态结构.使用图形数据库(当然,我过于简单化),您拥有属性和对象.您可以在没有架构实施的情况下将它们连接起来.

我不会把任何关键任务放到非关系型商店中.例如,Commerce,您需要在交付产品之前保证交易完成.您需要保证完整性(或至少保证完整性的最佳机会).如果用户丢失他/她的网站自定义设置,没什么大不了的.如果你失去了商业交易,那么大不了.可能有些人不同意.

我也不会将复杂的结构放入任何上述非关系存储中.它们并没有很好地连接.而且,这没关系,因为它不是他们应该工作的方式.如果您可以将address_type的标识放入关系系统的customer_address表中,您可能希望将address_type信息嵌入存储在文档或键/值中的客户元组中.数据效率不是文档或键/值存储的域.关键是分配和纯粹的速度.牺牲是足迹.

这个商店的其他子类型标记为"nosql",我在这里没有涉及.有很多(最后计数122个)不同的项目专注于各种类型的数据问题的非关系解决方案.Riak是我一直听到的另一个,迫不及待想要尝试.

这就是诀窍.这些大型美元的关系供应商一直在关注和机会,他们都在建立或计划建立自己的非关系型解决方案以配合他们的产品.在接下来的几年里,如果不是更早的话,我们会看到这一运动成熟,大公司购买最好的品牌,关系供应商开始提供集成解决方案,对于那些尚未购买的产品.

在数据管理领域工作是一个非常激动人心的时刻.你应该尝试其中的一些.您可以下载Couch或Mongo,并在几分钟内启动并运行它们.HBase有点困难.

在任何情况下,我希望我没有混淆地通知我,我没有明显的偏见或错误.

Answer 3

RDBMS擅长连接,NoSQL引擎通常不擅长.NoSQL引擎擅长分布式可伸缩性,而RDBMS通常不是.

RDBMS擅长数据验证共同安装,NoSQL引擎通常不擅长.NoSQL引擎擅长灵活且无模式的方法,而RDBMS通常不是.

这两种方法都可以解决一系列问题; 差异在于效率.