无模式数据库系统的吸引力是什么?

时间:2010-10-04 14:33:32

标签: database nosql key-value-store document-oriented-db schemaless

我听过很多关于无架构(通常是分布式)数据库系统的讨论,比如MongoDB,CouchDB,SimpleDB等......

虽然我可以理解它们可能在某些方面很有价值,但在我的大多数应用程序中,我都试图保留具有特定类型字段的对象,我只是在关系模型中自动思考。我一直在考虑具有唯一整数id的行,null / not null字段,SQL数据类型以及用于查找集的select查询。

虽然我对这些新系统的分布式特性和简单的JSON / RESTful接口感兴趣,但我不明白松散类型的键/值哈希将如何帮助我进行开发。为什么松散类型的无架构系统能够保持干净的数据集?例如,我怎样才能找到日期介于x和y之间的所有项目?有没有加入的概念?

我知道很多系统都有自己的差异和优势,但我想知道范式的差异。我想这是一个开放式的问题,但也许社区的答案以及他们亲眼看到这些系统优势的方式将有助于启发我和其他人关于何时我想要使用这些(当然更髋关节)系统而不是传统的RDBMS。

6 个答案:

答案 0 :(得分:29)

我只会说出一两个常见的原因(我相信人们会写作文答案)

  1. 对于高度分布式系统,任何给定的数据集都可以分布在多个服务器上。当发生这种情况时,DB引擎可以保证的关系约束大大减少。 您的参照完整性的某些需要在应用程序代码中处理。这样做时,您将很快发现几个痛点:

    • 您的逻辑分布在多个层(app和db)
    • 您的逻辑分布在多种语言(SQL和您选择的应用语言)

    结果是逻辑封装更少,便携性更低,而且更改成本更高。许多开发人员发现自己在应用程序代码中编写了更多逻辑,而在数据极端情况下,数据库架构变得无关紧要。

  2. 架构管理 - 尤其是在无法停机的系统上 - 很难。降低模式复杂度可以减少这种困难。

  3. ACID对分布式系统(BASECAP等)的效果不佳。 SQL语言(以及在一定程度上的整个关系模型)针对事务性ACID世界进行了优化。因此,一些SQL语言功能和最佳实践是无用的,而其他一些实际上是有害的。一些开发人员对“反对谷歌”感到不舒服,并且更倾向于完全放弃SQL,而是倾向于根据他们的要求设计的语言。

  4. 成本:大多数RDBMS系统都不是免费的。扩展领域的领导者(Oracle,Sybase,SQL Server)都是商业产品。在处理大型(“网络规模”)系统时,数据库许可成本可以达到或超过硬件成本!成本足够高,可以在OSS产品之上构建定制解决方案,大大改变正常的构建/购买考虑因素(所有重要的NOSQL产品都是OSS)

答案 1 :(得分:8)

Schemaless很棒有两个原因:

  1. 大脑优化文档存储的直观性
  2. 解决了Sparse-MatrixEntity-Attribute-Value存储问题。
  3. 我在Ruby on Rails中使用SQL和No-SQL作为生产应用程序。我不是数据库专家,我不得不承认谷歌搜索ACID和他们不熟悉的类似条款。

    "啊哈!另一个无知趋势追随者跳上最新潮流"你可以说。但是,实际上,我真的很高兴我决定在最近的2年应用程序中使用MongoDB,这就是为什么......

    大脑优化直观性的另一面是我对Magento电子商务系统的体验。我不想抨击它,因为它在当时很好地帮助了我,但它确实很难在处理器上试图计算每个产品的属性。根本原因是产品数据的实体 - 属性 - 值存储。缓存或被诅咒是解决方案。

    对我来说,主要优势在于真正重要的唯一优化 - 你自己的大脑。许多技术都被评价在内存,处理器,硬件方面的效率,而且拥有一个非常直观易懂的数据库带来了自己的优点。我们发现在代码中添加功能很快,因为数据库看起来很像我们正在建模的真实世界。当我要求电子商务客户向我提供他们的产品清单时,他们自然会倾向于使用Excel(想想桌面商店)。第一列很简单:

    1. 产品名称
    2. 价格
    3. 产品类型(
    4. 然后它变得越来越难以覆盖在笔记,颜色编码和其他表格的链接(是的......关系)

      1. 颜色(仅限某些产品)
      2. 尺寸(X大,大,小) - 仅适用于产品8' 9' 10,高尔夫球杆使用不同的比例
      3. 颜色2.猫项圈有两种颜色选择。
      4. 功率
      5. 固定类型(男,女)
      6. 所以它以可怕的Excel桌面结束,这对我来说毫无意义,对于日常工作的人来说没什么意义。我们把手放在空中,然后决定通过目录然后它就击中了我!如果您能够存储目录中显示的数据,那会不会很棒!?只是列出每个产品的记录集合,只列出该产品的属性。然后,您可以选择要索引的常用属性以便日后检索。当然,这是一个文档存储。

        总之,当您遇到稀疏矩阵问题或随时间变化其属性的对象时,文档存储会很棒。我已经在No-SQL世界中生活了2年,我无法想象一个没有这些功能的真实世界应用程序,因为世界本身看起来像文档存储。

答案 2 :(得分:7)

主要关注点应该是您需要对数据做些什么。如果您拥有庞大的数据集并且发现传统的RDBMS成为瓶颈,那么您可能需要尝试使用无模式或NOSQL解决方案。

我所知道的大多数使用NOSQL解决方案的环境也以某种形式或方式使用RDBMS解决方案。基于RDBMS的解​​决方案是数据完整性非常重要且您需要ACID事务的标准。但是,如果您的系统不是基于事务的高度,但您需要快速扩展或向外扩展,则可能需要NOSQL解决方案。

答案 3 :(得分:4)

我只玩过MongoDB,但我真正感兴趣的一件事就是如何嵌套文件。在MongoDB中,文档基本上就像一个记录。这非常好,因为传统上,在RDBMS中,如果您需要提取“人员”记录并获取相关地址,雇主信息等,您经常需要转到多个表,加入它们,创建多个数据库调用。在像MongoDB这样的NoSQL解决方案中,您可以嵌套关联的记录(文档),而不必弄乱外键,加入多个数据库调用。与该一条记录相关的所有内容都被提取。

这在处理对象时特别方便。在许多情况下,您可以将对象存储为一系列嵌套文档。

答案 4 :(得分:3)

NoSQL数据库不是无模式的;架构嵌入在数据中。它们被称为半结构化。但是,在某些KV数据存储中,架构甚至可以嵌入代码中。半结构化方法的优点有两个方面:列是行的一部分的灵活性(一行可以有5列,另一行有5个不同的列,并且列的特性具有灵活性(例如,可变长度)< / p>

答案 5 :(得分:-8)

通常情况下,吸引力是蛇油的吸引力 - 大多数人喜欢他们对关系定理没有任何线索,并且在专业人士呕吐的水平上讲SQL。不知道ACID的条件是什么,为什么它们很重要等等。

并不是说他们没有有效用途....只是说吸引力主要是人们不知道他们应该知道什么并做出愚蠢的结论。同样,不是每个人都是这样,但大多数开发人员都喜欢它们 - 不太了解数据库系统的实际负责。