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

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

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

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

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

1> Addys..：

---

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

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

你的逻辑分布在多个层(app和db)

您的逻辑分布在多种语言中(SQL和您选择的应用程序语言)

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

模式管理 - 尤其是在无法选择停机的系统上 - 很难.降低模式复杂性可以减少这种困难.

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

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

---

我不认为成本应该是不使用RDBMS与NOSQL解决方案的考虑因素之一.有很多免费的开源RDBMS,比如MySQL和Postgres,可以很好地扩展.

---

@Deep Kapadia有一个有效的观点,因为你提到了许可费用而#4没有其他费用.MySQL和PostgreSQL确实可以很好地扩展.答案的其余部分包含非常好的点,imho#4并不属于你的答案.

---

"足够好"是非常相对的.每个系统都有不同的考虑因素,而成本往往是其中之一.如果不是许可的直接成本那么至少是间接成本,例如工具,经验丰富的开发人员在你的堆栈上的市场价格等.

2> Kevin Monk..：

---

Schemaless很棒有两个原因:

大脑优化文档存储的直观性

解决稀疏矩阵和实体 - 属性 - 值存储问题.

我在Ruby on Rails中使用SQL和No-SQL作为生产应用程序.我不是数据库专家,我不得不承认谷歌搜索ACID和类似的术语,因为他们对我不熟悉.

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

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

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

产品名称

价钱

产品类别 (

然后它变得更难和覆盖在笔记,颜色编码和其他表的链接(是的..关系)

颜色(仅限部分产品)

尺寸(X大,大,小) - 仅适用于8'9'10的产品,高尔夫球杆使用不同的比例

颜色2.猫项圈有两种颜色可供选择.

瓦数

固定类型(男,女)

所以它以一堆糟糕的Excel表格结束,这对我来说毫无意义,对于日常工作的人来说也没什么意义.我们把手放在空中,然后决定通过目录然后它就击中了我!如果您能够存储目录中显示的数据,那会不会很棒!？只是列出每个产品的记录集合,只列出该产品的属性.然后,您可以选择要索引的常用属性,以便日后检索.当然,这是一个文档存储.

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

3> Deep Kapadia..：

---

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

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