随着NoSQL数据库的出现,我为什么要使用SQL数据库?

在亚马逊,我用了很多代码。我编写的大多数代码都是没有人真正理解的代码。它充满了特殊的案例处理,这并没有被很好地理解,因为它是在很长一段时间内快速增长的补丁。如果你想完全理解改变的影响,那你就是走运了。从本质上讲,你是被迫增加的。

我也处理了很多数据。SQL中表的结构为数据提供了优秀的长期文档。数据库相对容易直接使用,数据结构也很合理。有些人的工作就是管理数据的结构和完整性。

我担心一个缺乏良好文档结构的NoSQL数据库会慢慢地获得我所处理的代码的所有缺点。它最终会充满旧结构的数据,而这些旧结构再也没有人真正理解,并且会变成一个大部分都是无用垃圾的巨大补丁。

我将SQL数据库的主要好处视为维护数据库结构和一致性规则所需的强制文档。这些好处没有一个简单的短期度量,比如查询速度或事务一致性。它们是长期的好处,会在一段时间内影响数据的有效性。

作为第二个相关的观点,我发现在使用ORM等工具时,将数据映射出来,然后决定如何将其转换为我正在编写的应用程序中的对象更有用。数据及其关系代表了一种长期的档案结构,可用于各种目的。

应用程序中对象关系的结构就是为了应用程序的目的而存在的。在SQL表和关系约束中表示的一组给定数据将具有许多可能的对象模型,这些对象模型在应用程序中表示它,并且每个对象模型都将反映该特定应用程序的目标。但是,数据及其结构的存在与任何给定的可能由它们构成的短暂使用无关。

我认为人们对“报告”的看法是,不同的应用程序可以以非常不同的方式有效地查看同一组数据。

我个人认为,SQL是一个很好的模型,可以直接用于存档数据、不经常修改的数据或具有极高一致性要求的数据。我认为我将继续使用关系代数来定义我的数据的整体结构,即使我将它存储在NoSQL数据库中。如果不首先修改描述它的关系结构,我将不会更改NoSQL数据库中数据的结构。这将允许我将NoSQL数据库映射回SQL,以便我仍然可以使用SQL进行长期存储和仓库存储,并强制我以文档化的形式维护数据结构。

这样做还可以帮助我将数据从NoSQL数据库中提取出来,用于创建数据库时无法想象的应用程序。

当然,有一些数据的结构很自然地适合NoSQL,在那里为它生成一个关系模式是没有意义的。例如,实际文档的存储、图片或其他媒体的存储,或其他没有可用于表示的结构的大数据块。不过,这种区别非常棘手。图片和电影对它们确实有结构,只是一般情况下不需要将结构存储在数据库中。如果你设计了一个系统来尝试阅读和理解博客文章,那么它也可能有结构,而这很可能是你想要保持记录的结构。

关系数据建模是一种形式化的数学解决方案,用于表示不需要 冗余 不允许 异常 . 您可以从数据关系本身设计一个优化的数据库设计。这是关系的过程 database normalization .

非关系数据建模没有从数据中定义最佳数据库结构的正式方法。您可以根据预期的使用情况设计数据库;也就是说,您的查询决定了最佳的数据组织,而不是数据本身。

在非关系数据库中,您永远无法确保数据符合特定的文档结构。您可以在数据库中保留早期版本的文档。因此,应用程序代码最好能够“发现”每个文档的结构,在必要时执行转换,并希望满足数据集合之间的引用。

在关系数据库中,可以将数据完整性作为模型的组成部分。如果您为规范化设计并正确设置约束,您就知道永远不会有孤立的或数据异常。

在设计数据库时,非关系数据库为您提供了一种效率。关系数据库为您提供了另一种效率,正如您 使用 数据库。

也就是说,您一直在处理的特定类型的问题——对象图——很难用普通的SQL有效地完成。但我认为使用NoSQL数据库并不容易。

回复你的意见:同意, consistency 不是每个应用程序的优先级。这并不能使一致性的价值对于那些重要的应用程序来说是“虚无的”。

您询问了为什么要使用关系数据库——当关系数据库的好处适合您的项目的优先级时,您将使用它们。

不要用螺丝刀拧钉子,也不要用锤子拧螺丝。有一个适当的工具来解决每种类型的问题。

这取决于你想做什么。当需要在对象的不同字段上进行搜索时,SQL是好的。如果您不需要进行搜索,并且您有非常复杂的多态树状结构,那么SQL是可怕的。

我已经开发了一个应用程序,它允许用户通过将小片段连接在一起来构建网页,而最初的序列化使用了键/值SQL表。所有片段都具有存储的属性(片段、属性、值)。所以没有计划,但仍有很多繁重的工作。这可能是两个世界中最糟糕的一个,因为您实际上没有从数据库中获得太多的数据验证,所以很难查看表并了解正在发生的事情,而且仍然有很多工作要将其写入数据库并读回。

我们也做了一个类似的应用程序,但是我们学到了教训,我们只使用纯Java类,并使用JSON对它们进行编码。用户只需在富用户界面的前面编辑页面。单击保存,整个页面作为JSON对象发送回服务器。然后,服务器对对象进行验证,以确保所有约束都是正确的,除非用户被篡改或代码中存在错误,否则这些约束应该始终是正确的。然后,通过编码将对象写入一行,返回到JSON。

这对我们很有效,因为我们从不想处理对象的一部分。我们总是处理整个对象,所以JSON不仅简单,而且比对每次读取进行40多个查询更快,如果它被正确规范化的话,我们将不得不这样做。

工具对于SQL更好。NoSQL有缺陷的名声。但即使假设这两个差异消除了…

我在用SQL建模复杂对象方面有与您相反的经验。要说表和列充其量只是对象的“模拟”,这有点语义化。对象的任何序列化也都将是一种模拟:尽管文档数据库或XML或其他一些可能比表/列更像是一种更好的模拟,但它往往是功能较弱的技术。ORM极大地帮助缩小了RBDMS与面向对象语言之间的差距。

自关系理论正式化以来,SQL一直是王者。分层数据库(文档数据库)丢失,关系数据库获胜。我会问你自己,考虑到这段历史,你的问题与过去30年中你需要恢复到等级结构的大多数问题有什么不同吗?

NoSQL DBS现在很适合需要水平伸缩的问题(SQL现在做得不好)。你的问题需要这样做吗?

这里不仅有SQL数据库的变体,而且每个数据库都有自己的优缺点。

有基于文档或对象的、基于列的(宽行)、基于键值的和基于图的,这只是我现在能想到的。每种类型的数据库都有其弱点和强大之处(与其他数据库和RDBMS相比)。

在决定选择哪种数据库类型时,您需要问自己的真正问题是如何使用数据?

在大多数常见的情况下,至少在某种程度上消除了对象的复杂性,对于非大型数据,RDBMS更关心的是数据本身,而不是如何使用数据。在RDBMS中,您只需要知道您的数据结构和内部关系,当您意识到这一点后,您只需将其放入正常形式的模式中,如果您放置了正确的键和索引,那么大多数查询的性能都会受到影响。

在NoSQL数据库中,它更为关键,例如,基于文档的DBS的一个特殊弱点是,如果您需要对多个文档进行复杂的查询,在大多数情况下,您将无法获得比RDBMS更好的性能。

例如,如果您正在维护订单文档,并且希望以一系列日期内获得的最大利润查询订单,那么Afaik如果您不是专家(我不是这样的专家),那么您最终将得到一个O(N)查询,而在RDBMS中,即使您是MongoDB专家,它所需的时间也会更少,而且性能也会更高。

总之,如果您事先知道数据将如何使用,并且您知道文档数据库将为您的用例执行,那么是的,使用文档数据库,但是如果您不确定数据将如何使用,那么RDBMS通常是更明智的决定。

当然,您需要考虑到大数据,因为RDBMS不会向外扩展(不能轻松地添加节点以支持更多流量),并且在处理大数据时性能会降低(可能开始滞后于GBS或PBS)。

此外,请记住,RDBMS比文档DBS老得多,多年来开发得非常广泛,这使得RDBMS包含的优化和工具比任何NoSQL备选方案都多。

当我调查NoSQL风格的数据库时,我发现它们既不提供ACID,也不提供关系特性(不是关系数据库)。自从我 喜欢 数据一致性,我通常需要某种关系特性,我没有选择NoSQL数据库。

但是,我不使用那里的ORM工具,我倾向于编写SQL本身。

重要的是要记住,关系仍然(并且将持续一段时间)是选择的平台:事务处理、主数据管理、引用数据、数据仓库(在MPP中)、BI(尽管倒列数据库在查询性能上非常出色)。考虑到NoSQL的当前状态,将其替换为以上用途的关系几乎是荒谬的。

我的关键问题是,在哪里,SQL数据库会真正超过文档数据库,而且从所有的响应来看,它们似乎并不多。

考虑到NoSQL数据库在数据库类型上的变化与关系数据库的变化一样多,两者都匹配ACID的全部或部分,这取决于此时使用的数据库,它们基本上是解决问题的公平方法。

在这之后,关键的区别将是工具和成熟度,因为SQL数据库作为一个既定的参与者有更大的把握,但这是所有新技术的特点。

我看待这个问题的方式是相反的:为什么我需要NoSQL?

SQL为我提供了关系建模、事务、触发器、键、约束、动态模式,这些模式可以在眨眼之间修改,但可以保证数据的完整性,对以最纯粹和最干净的形式表示的数据进行快速复杂的查询。

您的问题是,您正在尝试在圆孔中安装方钉:对象和RDBMS不能很好地结合在一起,因为RDBMS设计用于处理许多更复杂的get/set逻辑,并强制实现一致性,这正是您从对象层所期望的。

普罗提普:放下这些东西,它们不是合适的工具。