我如何选择SQL和非SQL方案

在这篇文章中，我描述了如何在解决方案中选择SQL和No-SQL数据库。作为这一决定的一部分，我探讨了结构化和非结构化数据对决策的影响以及其他因素。这可能是一个复杂的决定。

不使用SQL，SQL

记得有一次，说过：“不教你们如何成为工程师。工程就是赚钱！”

当我回顾我的工程职业生涯时，我看到他说得对。技术决策不仅要看成本，还要看技术是否适合当前的任务。两者都得合适，才能做出决定。

在选择 No-SQL 还是 SQL 时，情况也是一样的。

关于 No-SQL 和 SQL 的讨论，一般来说是关于选择哪种数据库技术来为特定的解决方案服务的讨论。

让我们从“胜任工作”开始，首先我们要考虑的是我们的数据。首先，这涉及我们是否应该关注数据是结构化的还是非结构化的。

然后我们将看看决策中非技术部分的内容。

有结构的 vs 无结构的

我听说很多人在谈论他们的数据是非结构化的。有些报告表明，企业大约有80%的数据是非结构化的。

很少有人会提到他们的数据是结构化的。这可能是因为，在某种意义上，所有的数据都是有一定结构的。

那么，拥有结构化或无结构化数据具体指的是什么呢？

我们可以通过两种方式来判断数据是否结构化。

• 在编写代码之前，我们是否已经知道了数据的元数据？
• 我们在运行时收到的数据是否会改变其形式？

对于这两个问题，答案可能更像是“嗯，一半对一半错”。

我们来看一页文本。这听起来有些奇怪，因为它实际上非常有结构化。它使用有限的一组符号书写，并且（通常）遵循该语言的语法规则。这一切都表明，我们这页看似非结构化的文本实际上包含了非常有结构的元数据。

文本的实际含义可能是什么都行。因此，它的意义是没有固定结构的。

所以，我们手头的数据一部分是结构化的，另一部分是非结构化的。这种情况很普遍。

真正的非结构化数据是没有固定格式或结构的，因此非常随机，很少有规则可以适用于它。这些数据的限制主要包括存在、大小以及转换能力（例如加密）。

对于任何具有复杂功能的解决方案，软件依赖于数据及其元数据必须是结构化的。当你想到这一点时，讨论数据是否结构化与否已经无关紧要。你很可能会同时拥有这两种数据。

数据流的灵活性

与其谈论结构，我觉得谈论这种数据的流动性更好。

如果你的数据符合严格的类型约束，那么它可以被视为坚固的，就像盖房子用的砖头。它的结构是固定的，不会改变。

如果你的数据不符合任何规则，那么它可以被视为像水一样流动。这样的话，它的结构就是没有定义的，几乎是随机的。

现在我们可以看看我们的数据的流动性如何。显然，它位于砖块和水之间，更像果冻（或杰罗）。

根据你要解决的问题，数据流动性程度可能更像砖块或更像水。理解这一点有助于理解你需要的技术来支持它。

持久化了的数据

我之前说过，选择No-SQL还是SQL实际上是一个关于数据库技术或持久化层的决策。让我们来看看这代表什么。

如果你在 Google 上搜索 “结构化 vs 非结构化”，你会发现大多数描述都集中在数据如何在数据库中存储（或持久化）的方式上。你会发现，这种定义倾向于将存储解决方案分为两类：一类是基于 SQL 的数据库，用来存储结构化数据（比如砖头）；另一类是基于 No-SQL 的数据库，用来存储非结构化数据（比如水）。

不过在这篇文章里，我将使用这俩。

让我们看看这会是怎么回事。

结构化数据和非结构化数据

SQL数据库中的结构化数据：

结构化数据具有固定的定义（或结构）。数据库将数据存储在_表_中，每一条新的数据（或记录）作为表中的一行被保存。记录中的每个字段作为行中的_列_被保存。每列都是特定类型的数据。所有结构化数据都被存储在一个固定的由表、行和列构成的三维网格中。

由于采用了严格的结构来存储数据，因此使用结构化查询语言（SQL）来创建、读取、更新和删除数据。现在您的代码可以依赖于这些数据及其结构来进行处理了。

你应该知道，SQL 数据库也可以通过 BLOB（即二进制大对象）、字符串甚至是 JSON 格式的字段来支持非结构化数据。关于这点我们后面会再聊。

No-SQL数据库中的数据

无结构数据没有固定的结构模式，数据库也不规定记录的形式或内容，完全不关心数据是什么。

你现在可能在想，“如果没有特定的结构，我们该如何访问数据？”

好吧，即使是非结构化的数据，也需要某种方式来引用。通常，SQL数据库中的表和行会被替换为集合（collections）和文档（documents）。

这挺合理的。在日常词汇中，一个文档可以包含任何内容，这与非结构化的数据一样。一个集合就是指一些有共同主题的文档，比如关于鱼类的文档。文档里面可以放任何类型的信息，同一个集合里的文档也可以有不同的内容。

现在大家应该都明白，高度流动的数据和No-SQL数据库更匹配得多。

关系型数据库

当我们提到SQL数据库时，我们实际上指的是关系数据库管理系统（RDBMS）。

在结构化的数据中，数据之间可能存在关系。例如，如果我们有一个关于鱼类的表格和一个关于鱼缸的表格，我们可能想知道哪些鱼位于哪些鱼缸中。这表明了鱼类和鱼缸之间的关系。

一个关系型数据库理解这些关联，并通过数据记录之间的引用表示这些关联。

由于关系非常重要，RDBMS这样的数据库管理系统将专门管理这些关系，比如利用参照完整性规则确保引用保持完整。

正是这些关系模式使得SQL能够在数据库中即使数据分布在不同的表、行和列时进行管理。

NoSQL数据库

在一个真正没有结构的数据集中，数据之间没有任何固定的关联。比如，图书馆中的书籍，它们之间可能没有任何联系。它们只是（图书馆里）一堆看似无关的书籍。

在没有结构的情况下，访问非结构化数据需要另一种方法，而不是使用SQL。虽然SQL相对标准化，但No-SQL查询语言更多地依赖于底层存储技术。它们共同的一点是，这些语言都被统称为No-SQL。

将 No-SQL 查询想象成在图书馆中搜索某物的描述，比如一条金鱼的描述，这样思考会很有帮助。

虽然很容易觉得非SQL数据库中的数据项（文档）与其他文档无关，但实际上很少是这样。非SQL数据库支持关系性，但并不一定像关系型数据库那样强制执行关系的完整性。这可能对你来说是个问题，也可能不是。

现在许多 NoSQL 数据库支持一种形式的 SQL。

最适合的技术解决方案

好的，到目前为止，我提到数据通常既不太结构化也并非完全非结构化。我还提到，SQL数据库和No-SQL数据库（非关系型数据库）都能处理这两种类型的数据。

那么我们怎么决定呢？

你需要考虑你的数据有多“灵活”。如果数据更像固定不变的砖块，你将从SQL数据库的严格规则中受益。如果数据更像水，将从No-SQL数据库的灵活性中受益。

还有一个场景。在某些情况下，你的数据结构还不清楚，但你仍需要存储数据。你可以先存储数据，等到你更清楚数据结构后再进行处理。在这种情况下，你可能更适合使用 No-SQL 数据库，因为你还不知道数据的流动性。

希望你已经明白，说到流畅性，大多数数据既不是完全的这一端，也不是完全的另一端，而是在中间某个位置。它可能更偏向于一端，因此你更可能选择适合的SQL或No-SQL数据库。

但是你又怎么应对另一种类型的数据呢？

非结构化数据：与SQL数据库

如我之前所说，SQL 数据库通常可以处理非结构化数据。它们可以将这些数据作为二进制大对象 (BLOB) 存储。就像文件一样，BLOB 也可以包含任何类型的数据。

或者，你也可以将其存储为文本字段。一种常见的做法是将其存储为文本字段中的 JSON 格式字符串。JSON 是一种常见的灵活数据格式（但实际上它自身有着严格的结构）。

最新的PostgreSQL数据库实际上支持一种名为JSONB的字段类型，可以原生支持JSON格式的数据。你能够用SQL来查询JSON字段中的数据。

你看，可以在SQL数据库中存储非结构化数据的方式有不少。

使用 No-SQL 数据库的结构化数据

另一方面，你可能选择了 NoSQL 数据库，但需要给它一定的结构以便处理。

就像 SQL 数据库一样，有选项。

在一个完全未定义的数据库结构中（除了集合和文档之外），你可以存储任何你喜欢的内容，包括包括结构化数据在内的任何内容。你唯一需要做的就是在存储数据到数据库之前，应用验证规则以确保数据符合你期望的结构。

这样确保你可以依赖于代码中的数据结构。

否则，如果数据不是由您的系统输入的，您可以应用校验规则来确保其符合您想要的结构。当然，任何校验失败都可能意味着您无法处理该数据，并且您需要一个机制来先解决它。

保持一致的需求

在选择存储技术时，这一点需要考虑的另一个要点是一致性。这一点指的是对一致性的需求。

当一个用户修改了数据时，其他用户是如何察觉这一变化的？

主要有两种经历：

1. 当一个或多个变化在一个事务期间发生时，其他用户在这期间不会看到这些变化，直到事务结束。在事务结束时，所有在该事务期间变化的内容将被一起保存，并且其他用户将始终看到一致的数据。

2. 在相同的情况下，每次更改都会被单独保存，其他用户会立即看到这些更改，这意味着数据可能在事务完成之前就不一致。

第二种方案被称为最终一致性模型，指的是在短时间内数据存在不一致。在出现故障的情况下，数据可能会处于不一致甚至无效的状况。

您可能已经知道，SQL 数据库（SQL）提供选项 1，而 No-SQL 数据库（No-SQL）提供选项 2。

所以，如果你的解决方案需要所有数据保持一致的状态，你可能需要使用SQL数据库。

然而，如果你可以暂时接受数据的不一致，也是有好处的。通过放弃一致性保证，No-SQL 数据库可以实现水平扩展。在需要时可在多个节点间复制。这意味着 No-SQL 数据库在处理大量数据时表现更佳，并且可以跨地区复制内容，加快响应速度，尤其是在当数据读取频率远高于写入时。

你可能会问，为什么要在解决方案中接受“最终一致性”？毕竟，使用计算机不是就是为了得到那份确定性吗？

实际上，如果你采用的是微服务架构，并且使用异步事件或消息队列作为支撑，那么你已经默认最终一致性是一种有效的设计选择。对于大多数解决方案来说，这似乎是一个可接受的策略。

在我们选择一种技术而非另一种技术的决定中，一致性和连贯性作为我们选择技术时考虑的技术因素。

我怎么做出选择

直到现在，你可能已经考虑了你的问题和解决方案，并选择了某种技术。记得我说过，这不仅仅是关于能否完成任务的问题，还要看它会耗费你多少成本。

这不仅包括开发解决方案的成本，还包括运行和维护它的成本。这些共同构成了总拥有成本（TCO）。TCO 考虑的是在一段时间内的各种成本，比如说：

• 开发成本
• 运行成本

• 维护成本

• 错过的时间成本（上市时间）
• 初始开发
• 增强与更新
• 维护更新
• 了解更多关于质量保证的信息
• 第三方许可和支持
• 服务质量和可用性
• 扩展能力

实际上，你的技术选择可能更多地与总拥有成本(TCO)有关，而不是与技术能力有关。这通常是因为解决方案有一个设定的预算，从而限制了总拥有成本的上限。

这些成本大致可以分成几类：

• 上市时间
• 开发工作
• 运营支持和维护

让我们更仔细地看看每一个。

上市时间

每个项目都有一个最后期限。这可能是因为它需要满足市场条件、达到收入目标、节省成本或其他依赖因素。

错过了那个截止日期，公司可能会遭受经济损失。

这推动了对减少交付时间风险的解决方案的需求。

因此，基于市场发布时间的决策不会特别偏向任何一种技术，而是选择实施风险最小的那种技术。这通常是您已经熟悉或交付团队最熟悉的技术。

这种决定可能导致更多的[技术债务]，但就像其他债务一样，它可能使您更快地实现当前的业务目标。

开发努力

通常认为采用 No-SQL 数据库可以加快开发速度，因为不需要设计和实现存储层。理论上，这可以加速并减少交付的风险，但实际上省下来的时间可能非常有限。

实际上，虽然数据层无需配置，但仍需设计并编写代码来强制执行这个设计。

No-SQL 数据库确实倾向于支持未知的数据结构和业务需求。这使得它们非常适合现在需要快速解决方案，但需求可能要稍后确认的场景。使用 No-SQL 数据库可以减少因这些决策产生的技术债。

在做出技术决定之前，您需要考虑您的开发团队。在上市时间、解决方案质量（包括功能、非功能和安全要求方面）以及减少技术负债方面，使用开发团队熟悉的语言和技术会更好。

如果开发团队有足够的时间和预算来掌握新技术的技能，或者团队可以通过增加相关技能来弥补，那么开发时间就不再是决定因素。然而，实际情况很少如此。

运营支持和维护

好的，你选择了另一种不同的技术，并基于它创建了一个解决方案。一切顺利，你对自己的选择感到满意。你将这个方案投入生产，但问题接踵而至。

你会发现维护支持费用增加了，因为新的技术许可不在现有协议覆盖范围内，所以变成了额外的费用。

你的运营团队（包括一、二、三级支持）不熟悉新技术，也需要像开发人员一样学习新技术。这将影响你的项目交付时间表和/或服务质量。

需要建立新的运营支持工具，以便您的运营团队可以处理不同严重程度的问题。在学习过程中难免会犯错，这可能会对您的用户产生影响。恢复时间可能会延长。

所有这些都对您的业务有影响，在考虑更改技术时需要考虑（并做好规划）。

总结一下。

到目前为止，在这篇文章中，我探讨了在选择数据库技术方案时需要考虑的各种因素。总的来说，决策不仅仅局限于“我想在xyz上工作”。从一个更高的角度来看，它涉及：

• 数据流动
• 保持一致性
• 上市周期
• 开发投入
• 运行支持和维护

希望我已经证明了 No-SQL 和 SQL 数据库之间的差距和差异正在一天天缩小。虽然每种数据库都有自己的一套特点，可能对你的项目有帮助，但总体来说，这些独特的优势正在变得越来越不明显。

如果在技术层面上一切相同，我们接着会转向业务影响，这些影响通常归结为财务影响。除非你有进行绿地项目（greenfield project）并能组建新开发团队的奢侈条件，否则将存在一些现有因素倾向于支持目前技术。

在我的职业生涯中，我参与了技术选型，并目睹了它所带来的挑战。我有幸在一个greenfield项目中工作过，并有机会组建自己的开发团队。我也接手了嵌入式技术及其开发团队，并不得不考虑不同的方案。

在几乎每次情况下，我需要回答的问题都是关于对预算和时间表的影响。就像所有债务一样，技术欠债最终会迟些解决，并且最终不管怎样都会累积起来。

据坊间传闻，软件在5到8年内会被淘汰并替换。这一时间框架是基于整体当代架构变化、市场需求波动以及竞争对手对供应商技术改进的压力等因素。例如，这包括了整体当代架构变化、市场需求波动等。你会愿意用一张5年后就消失的信用卡吗？

说到选择No-SQL和SQL时，我会参考以下优先级来做决定：

• 数据在设计和运行时的流动性
• 需要保持数据一致性
• 可用的预算/时间限制
• 现有技术及团队的技术实力
• 规模及性能

我们可以通过一些场景来看看这个问题。

比如说我们有两个项目，一个是这样的，另一个是那样的：

项目#1 — 一个流动的数据集，无需保证数据一致性，需要大量扩展。

项目二 — 相对稳固的数据集，需要保持一致，无需大规模扩展

1. 面对一个新项目，即所谓“绿地项目”（greenfield project），#1 会倾向于选择 NoSQL 选项。
2. 面对一个新项目，即所谓“绿地项目”（greenfield project），#2 会倾向于选择 SQL 选项。
3. 如果我们有现有的技术和相关技能，并有足够的预算和时间来更换技术，相应的选择将同样适用（#1 = NoSQL）和（#2 = SQL）。
4. 如果我们有现有的技术和相关技能，但没有预算或时间来更换技术，我将使用现有的技术来解决 #1 或 #2 并采取适当的策略来应对任何折衷方案。

摘要

在这篇文章里，我研究了在选择 NoSQL（非关系型数据库）和 SQL（关系型数据库）数据库时考虑的一些因素。

主要看是否能胜任工作，然而随着技术的进步，这一点变得越来越无意义了。

这个决策是基于总成本，包括开发成本、支持与维护成本，以及运营相关的成本。

值得注意的是，引入新技术的商业理由比利用现有技术更难说清楚，因为技术方面并没有明显的“决定性优势”。

每个人的项目、业务和决策框架都有所不同，但我希望我已经帮你理清了需要考虑的方面。

我希望你喜欢这篇文章，并且通过学习到哪怕是很小的新知识，你的技能因此得到了提升。

如果你喜欢这篇文章，请给我点个赞哦，这能帮助我了解大家觉得哪些内容有用，以及我将来可以写些什么。如果你有任何建议，也可以在评论区留言。