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

Question

我听到很多关于无模式（通常是分布式）数据库系统的讨论，例如 MongoDB、CouchDB、SimpleDB 等...

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

虽然我被这些新系统的分布式特性和简单的 JSON/RESTful 接口所吸引，但我不明白松散类型的键/值哈希对我的开发有何帮助。为什么松散类型、无模式的系统有利于保持干净的数据集？例如，当它们可能没有日期时，我如何才能找到日期在 x 和 y 之间的所有项目？有join的概念吗？

我知道许多系统都有自己的差异和优势，但我想知道范式的差异。我想这是一个开放式的问题，但也许社区的答案和他们个人看到这些系统优势的方式将有助于启发我和其他人什么时候想要使用这些（诚然更时髦的）系统而不是传统的 RDBMS。

Answer 1

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

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

   • 您的逻辑分布在多个层（应用程序和数据库）
   • 您的逻辑分布在多种语言中（SQL 和您选择的应用语言）

   结果是逻辑的封装更少、可移植性更低，并且更改成本要高得多。许多开发人员发现自己在应用程序代码中编写的逻辑更多，而在数据库中编写的逻辑更少。极端情况下，数据库模式变得无关紧要。

2. 架构管理（尤其是在无法选择停机的系统上）非常困难。降低架构复杂性会降低这种难度。

3. ACID 不适用于分布式系统（BASE、CAP 等）。 SQL 语言（以及在一定程度上是整个关系模型）针对事务性 ACID 世界进行了优化。所以一些 SQL 语言特性和最佳实践是无用的，而另一些实际上是有害的。一些开发人员对“违背常规”感到不舒服，他们更愿意完全放弃 SQL，转而采用一种从头开始为他们的需求而设计的语言。

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

Answer 2

主要关注点应该是您需要如何处理您的数据。如果您有一个庞大的数据集并且发现传统的 RDBMS 是一个瓶颈，那么您可能想要尝试使用无模式或 NOSQL 解决方案。

我知道使用NOSQL 解决方案的大多数环境也以某种形式或方式使用RDBMS 解决方案。基于 RDBMS 的解决方案是数据完整性极其重要且您需要 ACID 事务的规范。但是，如果您的系统不是高度基于事务的，但您需要快速纵向扩展或横向扩展，则可能需要NOSQL 解决方案。

Answer 3

Schemaless 之所以伟大，有两个原因：

1. 大脑优化文档存储的直观性
2. 解决了Sparse-Matrix 和Entity-Attribute-Value 存储问题。

我在 Ruby on Rails 中将 SQL 和 No-SQL 用于生产应用程序。我不是数据库专家，我不得不承认我在谷歌上搜索过 ACID 和类似的术语，因为它们对我来说并不熟悉。

“啊哈！另一个一无所知的潮流追随者加入了最新的潮流”，你可能会说。但是，实际上，我很高兴我决定在我们最近 2 年的应用程序上使用 MongoDB，这就是为什么...

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

对我来说最大的优势是在唯一真正重要的地方进行优化 - 你自己的大脑。如此多的技术因其在内存、处理器、硬件方面的效率而受到批评，但拥有一个极其直观易懂的数据库也有其自身的优点。我们发现向我们的代码中添加特性很快，因为数据库看起来很像我们正在建模的真实世界。当我要求电子商务客户向我展示他们的产品列表时，他们自然会倾向于使用 Excel（想想表格商店）。第一列很简单：

1. 产品名称
2. 价格
3. 产品类型（

然后它变得更难，并被注释、颜色编码和其他表格的链接所覆盖（是的..关系）

4. 颜色（仅限部分产品）
5. 尺寸（X 大、大、小） - 仅适用于 8'9'10 的产品，高尔夫球杆使用不同的比例
6. 颜色 2。猫项圈有两种颜色可供选择。
7. 瓦数
8. 固定类型（公、母）

所以它以一团糟的 Excel 表格结束，这些表格对我来说毫无意义，对于日复一日使用这些产品的人来说也没有多大意义。我们举起双臂，决定浏览目录，然后它击中了我！如果您可以存储目录中显示的数据，那不是很好吗！？只是每个产品上仅列出该产品属性的记录集合。然后，您可以挑选出常用属性来编制索引，以便日后检索。当然，那是一个文档存储。

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

Answer 4

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

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

Answer 5

NoSQL 数据库不是无模式的；架构嵌入在数据中。它们被恰当地称为半结构化。然而，在某些 KV 数据存储中，模式甚至可能嵌入在代码中。半结构化方法的优点有两个：列是行的一部分的灵活性（一行可以有 5 列，另一行有 5 个不同的列，以及列特性的灵活性（例如，可变长度）

Answer 6

通常吸引人的是蛇油 - 大多数喜欢他们的人对关系定理一无所知，并且在使专业人士呕吐的水平上讲 SQL。不知道 ACID 条件是什么，它们很重要等等。

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