NoSQL 还是非 NoSQL

什么是 NoSQL

简单来说，NoSQL 是一种不遵循关系数据库模型的新型数据存储后端。这意味着我们谈论的是一个与传统的基于 SQL 的后端不同的“容器”。
为满足一系列新需求而诞生的 NoSQL 技术问世，而传统数据库已经成熟。当然，在过去的几年里，应用程序需要改变并且变得更加挑剔（大数据、集群、文件存储库），所以这个新的存储系统的设计考虑到了这些新的要求。

但是，我所说的“要求”是什么意思？这是 NoSQL 旨在支持的一组案例。

• 应用程序处理大量数据（大数据）
• 应用程序处理快速改变关系和数据类型的数据（半结构化、非结构化和多态数据）
• 开发人员使用敏捷方法在一个小团队中工作：大量小弹簧对抗长期瀑布迭代
• 作为服务的应用程序，可以在网络上发布
• 应用程序交付给成千上万的用户，而不是公司内部的少数人
• 不确定应用程序的未来负载：需要可扩展和动态，需要轻松地将软件基于后端集群

市场提供了许多 NoSQL 解决方案，无论是否开源。它们中的每一个都有点不同，可能专门针对某些特定需求，但基本思想和共同特征是提供更好的可伸缩性和性能。为此，他们放弃了通用 RDBMS 的一些特性，引入了新特性，但保留了足够有用的功能。

NoSQL 实现

SQL DB 的一个重大变化是，同时 SQL 后端是通用存储系统，NoSQL 发行版专注于特定类型的数据。这允许数据库在其范围内更有效，并允许拥有更高性能的系统。在本节中，报告了某种 NoSQL 数据库，以了解它们具有哪些应用程序。请注意，它们可以一起使用（也可以与传统的 SQL 系统一起使用）以充分利用所有系统。

面向文档

这种类型的数据库不需要具有一致的数据结构，因此当您必须处理多态数据或数据结构不断变化时，它们很有用。这种后端可以将规范化的实体（如键值数据集或 EAV 模型）转换为简单的文档集。

• 目标：存储非类型化的“记录”集，称为“文档”
• 示例：MongoDB、CouchDB
• 目标：异构数据、工作面向对象、敏捷开发

图数据库

我们被告知 NoSQL 数据库去除了关系的概念以实现更好的性能。在这种数据库中，这是不正确的。相反，这些数据库强制执行关系的概念。

他们的目标是通过数据与其他数据的关系来定义数据。当大多数数据结构被设计为与实体保持关系时（即，如果您有很多表，而大部分是外键列），这种数据库会很有用。

• 目标：描述数据关系
• 示例：Neo4j、GiraffeDB
• 目标：数据挖掘

键值存储

这是一种旨在存储大量键值对数据的数据库。当数据库用于存储属性、翻译或缓存目的时，这可能很有用。

• 目标：以键值形式存储数据
• 示例：Redis、Cassandra、MemcacheDB
• 目标：键值存储

NOSQL的优势

我们知道 NoSQL db 有一些有趣的优势，它们可以轻松解决传统 RDMS 无法解决的简单问题。如今，它们在关键系统中的大量使用，如大型云系统和一些大型SaaS产品，证实它们是成熟和有用的。但问题是，我为什么要搬到他们那里？在这种情况下，此举何时能盈利？我们不能仅仅根据我们的印象做出这样的决定，并且阅读一些供应商手册，其中认为 NoSQL 非常酷是不够的。此外，我们不能仅仅因为害怕变化而停留在不合适的平台上。

在本章中，我将尝试解释为什么这个解决方案足够好，可以继续使用它，以及什么用例使它更有利可图。

正如我们所说，NoSQL 数据库是针对传统关系数据库技术的局限性而创建的。这意味着我们会发现一些改进，或者更好，一些传统 rdbms 中不存在且无法添加的特性，即使生产者会实现它们。

NoSQL 的优势包括易于处理的能力：

• 大数据：用这个术语，我们描述包含大量数据的数据集。
• 可变数据：数据可以是结构化的、半结构化的和非结构化的。NoSQL 还可以管理数据的转换。
• 动态开发：在我们需要敏捷冲刺、快速迭代、频繁代码推送以及总而言之以响应变化的环境中，拥有一个包含动态的数据库是非常有帮助的。
• 面向对象：易于使用且灵活的编程
• 可扩展性：我们可以轻松实现高效、可扩展的架构，而不是昂贵的单体架构。即使在传统的数据库中，我们也可以做到这一点，但它更加困难和有限。
• 开源：大多数解决方案都是开源的，因此无需支付许可费用。

合成中

NoSQL 数据库更具可扩展性并提供更好的性能，并且它们的数据模型更接近应用程序内部使用的域模型。如今，基于 NoSQL 数据库启动项目的公司正在增长。NoSQL 数据库也往往是开源的，这意味着开发、实施和共享软件的成本相对较低。

NO-SQL 的限制

在评估 NoSQL 数据库的局限性时，重要的是要记住 NoSQL 世界是一个多样化的生态系统。并非所有 NoSQL 存储产品都会在相同程度上受到所有缺陷的影响。这是一件好事，因为这意味着组织在权衡不同 NoSQL 解决方案的优缺点时有很多选择，以确定哪一个最适合他们的特定需求。本章总结了一些使用 NoSQL 解决方案可能会遗漏的特性。

通过阅读这篇文章，你会发现本章的内容比优点更丰富。这不会是阻止使用 NoSQL 的方法。本章将公正地描述 NoSQL 技术的所有限制，只是想让您了解使用它们时可能遇到的每一个问题。许多点可能会因实施而异（即，当我说支持的工具很少时，它可能适用于大多数工具但并非适用于所有工具），因此将它们视为一个概述，提醒您可能存在的风险寻找。我期望的是，在您选择了要使用的 NoSQL 产品之后，您可以使用本章作为清单来了解这些问题是否存在于您的特定数据库中，以及它们是否与应用程序相关。

安全

安全是每个人都想要的东西，但很难达到。从理论上讲，每种技术都可能存在安全问题。在 SQL 系统上存在并且可能存在安全问题。那么为什么我在 NoSQL 上将此标记为可能的问题呢？与安全相关的 NoSQL“概念”没有真正的问题，但我们可能会遇到与我们使用的产品的成熟度相关的安全问题。随着产品的增长和修复，安全问题就会出现。直觉上，一个年轻的产品可能有许多未知的安全问题。而且，年轻的产品上市时间还很短，所以顾问们还没有时间去体验它们，很多安全限制都可以忽略不计。所以，问题在于大多数 NoSQL 平台的年轻化。对于商业用途，我建议只采用成熟的解决方案，背后有供应商。

数据一致性

当我们开始学习 RDBMS 时，他们告诉我们 ACID 事务是使操作在整个数据库中保持一致的最佳选择。好吧，大多数 NoSQL 技术都没有实现这种事务。NoSQL 系统基于最终一致性原则。在实践中，承担一点一致性风险（一个节点可能与其他节点不同步），它们获得了一些性能提升。是的，这是一种妥协，但我们不能拥有一切。

我不得不提到一些 NoSQL 实现，比如 FoundationDB，允许类似 ACID 的事务来保持 NoSQL 的高性能。顺便说一句，当我们继续使用 NoSQL 时，数据一致性仍然是一个关键部分：根据您正在开发的应用程序，这可能是一个问题，也可能不是。

加入

当您与试图将您转换为 NoSQL 技术的人交谈时，您可以从他们那里听到的第一个好处是由于删除关系而带来的性能优势。我们都同意关系可能会降低性能，但是删除它们会失去什么？这就像你背着一个又大又重的背包在下降。当然，放下它你会走得更快。这样做方便吗？取决于这个包包含什么，取决于背包内容对你有什么价值。如果它包含过夜的帐篷，也许，最好晚一小时到达目的地但睡得暖和，然后走得更快。如果你带了有用的一次性物品，也许你可以做相反的事情。

遵循这种并行性，我们是否可以接受失去一致性来获得性能？这很方便？

退后一步，我将从联接的起源开始。RDBMS 使用关系将数据从一个表链接到另一个表，以便将数据保存在一个地方并且不复制它们。Join是允许在查询中重新连接它们的构造。当然，相对于直接在您正在查询的表中查找数据而言，在表之间进行连接是一项额外的计算成本。但是这个成本是保持关系所必需的（没有复制，一致性）。

很明显，虽然这样的构造具有可接受的开销，但这是可以的，并且可能是最佳选择。但是当它减慢一切或需要太多硬件时怎么办？这个问题允许 NoSQL 开发人员声称缺少JOIN某个功能，但 NoSQL 是解决方案吗？

不总是。有时，我们只需要重新设计数据库结构，可能会删除一些关系或重新构建数据。是的，我们会失去一些关系，或者我们会复制日期的某些部分，但这是可以接受的（在 NoSQL 中，我们将失去所有的关系）。

另一个问题是一致性。考虑类别和产品。我们可能有一个嵌套的类别树，其中有许多产品作为树的叶子。在传统的 RDMS 中，更改类别树只是对category表上的外键（自关系）进行更新。这些更改会自动反映在所有子类别和产品上。在 NoSQL 方式中，我们可以在所有类别\产品上拥有冗余数据，并且更改将需要对子元素进行大量更新。

棘手的交易

让我假设我们的应用程序可以放弃以JOIN提高速度，在我们的例子中，这是一个可以接受的权衡。我们还说过，在许多 NoSQL 实现中，很难使各种条目保持一致。当你在没有事务的情况下工作时，你可以按顺序进行许多操作，但在粉碎之后，你会得到不一致。对于 NoSQL 的首次实现来说确实如此，并且一些新技术试图提供开箱即用的东西来提供开箱即用的事务。您还可以考虑在应用程序级别管理事务，尝试回滚脏数据，但在许多情况下可能很难管理。