关系型数据库

引言

如今，我们正面临数据驱动型业务的迅猛扩张，尤其是那些基于网络、每秒都在传输海量数据的业务。事实上，互联网上几乎 90% 的数据都是在过去几年中产生的。通常，这些数据需要存储在数据库中。然而，由于每个企业的需求各不相同，在选择数据存储方式时必须考虑多种因素。目前主要有两种路径可供选择：

• 关系型数据库
• NoSQL

接下来，你将了解这两种数据库的优势与劣势，但重点将放在NoSQL数据库上，并探讨为何我们需要将其作为解决实际问题的一种方案。

关系型数据库

关系型数据库的概念最早由埃德加·F·科德（Edgar F. Codd）于1970年提出，自20世纪80年代中期以来一直主导着我们的技术世界。尽管在上世纪90年代曾出现过对象数据库等概念试图挑战其地位，但最终并未成功。人们之所以长期青睐关系型数据库，背后有诸多原因。

为什么使用关系型数据库？

• 首先，它们非常贴近我们对现实世界的认知方式。应用程序中的实体可以通过记录和表格自然地建模。表之间的关系也基于应用领域中实体之间的实际关联来建立。

• 关系型数据库具有强大的一致性：一旦对某些记录进行修改，该变化就能被该领域内的所有应用程序立即感知。这使得关系型数据库成为多应用系统间共享数据的理想集成机制。

• 关系型数据库支持事务功能。这允许我们将多个表的更改作为一个整体操作，并在某一步失败时回滚之前的所有变更。这一功能虽然复杂，但在数据密集型系统中极为重要，能有效保障系统的稳定性。

• 它们支持*连接（Joins）*操作，便于跨表查询和整合数据。

• SQL 已基本成为各类关系型数据库的标准语言。由于其表达能力强且易于学习，极大地提升了数据库的可访问性，也让开发者能够更高效地进行开发。

综上所述，正是由于一致性、集成能力、表达力和稳定性，关系型数据库才得以广泛应用于当今几乎所有的商业解决方案中。

关系型数据库的问题

近年来，我们的世界发生了巨大变化。正如前面提到的，这是一个数据量庞大、频繁存储、传输和处理的世界——其中绝大多数是非结构化数据。

这并不意味着数据没有结构，而是指其结构（尤其是以表格形式呈现）难以定义或理解。一个使用非结构化数据的典型应用是客户分析，企业通过收集的数据来分析并优化客户关系管理。

如今，我们已不再主要依赖为独立应用设计的关系型数据库。随着社交媒体、物联网、微服务等技术的发展，应用形态已经发生根本性转变。这种分布式的、数据量巨大的新环境，为NoSQL数据库的兴起提供了土壤。

当前关系型数据库面临的最大问题是“阻抗失配”。

阻抗失配 是一个通用术语，用来描述关系模型与内存中数据结构之间的差异。

例如，应用程序内存中的对象通常以图结构的形式存在，而关系型数据库则采用表格形式存储数据。因此，我们必须在将数据存入数据库前，对其进行转换、拆分和重组。

为什么这是一个严重问题？

由于这些数据转换操作往往与应用代码的修改紧密耦合，导致数据库的扩展和维护变得耗时漫长。而现代应用要求全天候（24/7）可用，无法像过去那样在周末停机更新数据库。同时，用户对响应速度的要求极高，前端不能容忍因后端数据存储正在更新而导致的延迟。

另一个问题是，关系型数据库并不具备良好的集群适应性。当需要设置副本时，所有节点都必须同步写入数据；只有在所有副本都保持一致后，事务才能提交。这意味着写操作成本高昂。此外，为了保证一致性，读取数据前必须等待所有副本完成同步，这显著影响了性能。

实现动态数据管理、快速上线生产环境，以及采用敏捷开发方法，都要求比关系型数据库更高的灵活性——而这正是后者所欠缺的。

---

现在，你已经了解了关系型数据库存在的各种问题，接下来我们将学习NoSQL数据库，以及它们如何克服传统关系型数据库的局限性。