database - 为什么关系数据库存在可伸缩性问题？

Question

最近我在网上阅读了一些文章，这些文章表明关系数据库存在扩展问题，并且在涉及大数据时不适合使用。特别是在数据量很大的云计算中。但是通过谷歌搜索，我找不到很好的充分理由来解释为什么它不能很好地扩展。你能解释一下关系数据库在可扩展性方面的局限性吗？

谢谢。

Answer 1

想象两种不同的十字路口。

一个有红绿灯或警察在调节交通，十字路口的运动是限速的，还有一个看门狗准确地记录着什么车在十字路口准确地在什么时间开着，朝什么方向行驶。

另一个则没有，每个以他驾驶的速度到达十字路口的人都只是潜入并希望尽快通过。

前者是任何传统的数据库引擎。十字路口是数据本身。汽车是想要访问数据的交易。红绿灯或警察是 DBMS。看门狗保存日志和日志。

后者是 NOACID 类型的发动机。

两者都有一个饱和点，此时到达的汽车被迫开始在入口点排队。两者都具有最大吞吐量。对于前一种十字路口，该阈值较低，原因应该很明显。

然而，前一种十字路口的优势也应该是显而易见的。发生事故的机会更少。在第二种类型的十字路口，只有当交通密度远低于十字路口的理论最大吞吐量时，您才能预计事故不会发生。而在数据管理引擎的转换中，它转换为对一致和连贯结果的保证，只有前一种类型的交叉路口（经典的数据库引擎，无论是关系的还是网络的还是分层的）可以提供。

这个类比可以进一步延伸。想象一下如果发生事故会发生什么。在第二种类型的十字路口，主要关心的可能是尽快清理道路，以便交通可以恢复，完成后，还有哪些信息可以调查谁造成事故以及如何造成事故？什么都没有。不会为人所知。十字路口是开放的，只是等待下一次事故发生。在受管制的十字路口，有警察在指挥交通，他看到了发生的事情并可以作证。有记录表明哪辆车准确地在什么时间进入，准确地在哪个入口点，准确地以什么速度进入，大量的材料可供检查以确定事故的根本原因。但当然，这些都不是免费的。

足够丰富多彩的解释？

Answer 2

关系数据库根据ACID属性提供可靠、成熟的服务。我们获得事务处理、高效的日志记录以实现恢复等。这些是关系数据库的核心服务，也是它们擅长的。它们难以定制，并且可能被视为瓶颈，特别是如果您在给定的应用程序中不需要它们（例如，提供重要性较低的网站内容；例如，在这种情况下，广泛使用的 MySQL 不提供事务使用默认存储引擎处理，因此不满足 ACID）。许多“大数据”问题不需要这些严格的约束，例如网络分析、网络搜索或处理移动对象轨迹，因为它们本质上已经包含了不确定性。

当达到给定计算机的极限时（内存、CPU、磁盘：数据太大，或者数据处理太复杂和成本太高），分发服务是个好主意。许多关系数据库和 NoSQL 数据库都提供分布式存储。然而，在这种情况下，ACID 变得难以满足：CAP 定理状态有些相似，即可用性、一致性和分区容错性不能同时实现。如果我们放弃 ACID（例如满足 BASE），可能会增加可扩展性。参见这篇文章，例如。用于根据 CAP 对存储方法进行分类。

另一个瓶颈可能是灵活而聪明的类型关系模型本身与 SQL 操作：在许多情况下，具有更简单操作的更简单模型就足够且更有效（如无类型键值存储）。常见的逐行物理存储模型也可能会受到限制：例如，它不是数据压缩的最佳选择。

然而，由于关系数据库技术已经成熟、经过充分研究和广泛使用，因此存在快速且可扩展的符合 ACID 的关系数据库，包括像VoltDB这样的新数据库。我们只需要为给定的问题选择一个合适的解决方案。

Answer 3

举个最简单的例子：用生成的 ID 插入一行。由于 ID 在表中必须是唯一的，因此数据库必须以某种方式锁定某种持久计数器，以便其他 INSERT 不会使用相同的值。所以你有两个选择：要么只允许一个实例写入数据，要么拥有分布式锁。这两种解决方案都是一个主要的瓶颈 - 并且是最简单的例子！