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

最近，我在网上读到一些文章，指出关系数据库存在可伸缩性问题，在涉及大数据时不适合使用。特别是在数据量大的云计算领域。但我找不到充分的理由来解释为什么谷歌的可扩展性不强。你能解释一下关系数据库在可伸缩性方面的局限性吗

---

谢谢。

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

想象两种不同的十字路口

一个有交通灯或警察控制交通，在十字路口的运动速度是有限的，有一个看门狗精确地记录了什么车在什么时间在十字路口行驶，它朝什么方向行驶

另一个没有这些，每个以任何速度到达十字路口的人，只要潜入，想尽快通过

前者是任何传统的数据库引擎。十字路口是数据本身。cars是希望访问数据的事务。交通灯或警察是DBMS。看门狗保管日志和日志

后者是一种无酸型发动机

两者都有一个饱和点，在这个饱和点，到达的车辆被迫开始在入口排队。两者都有最大吞吐量。对于前一种类型的十字路口，该阈值处于较低的值，原因应该是显而易见的

然而，前一种十字路口的优势也应该是显而易见的。事故发生的机会大大减少。在第二种类型的十字路口，只有当交通密度远低于十字路口的理论最大通行能力时，你才能预期事故不会发生。在转化为数据管理引擎的过程中，它转化为对一致性和一致性结果的保证，而只有前一种类型的十字路口（经典的数据库引擎，无论是关系型、网络型还是层次型）才能提供这种保证

这一类比可以进一步延伸。想象一下，如果事故真的发生了会发生什么。在第二种类型的十字路口，首要的问题可能是尽快清理道路，以便恢复交通。完成后，还有什么信息可用于调查谁造成了事故以及如何造成事故？什么都没有。它不会被知道。十字路口敞开着，等待着下一次事故的发生。在受管制的十字路口，有一名警察在管制交通，他看到了发生的事情，可以作证。有记录显示哪辆车准确地在什么时间进入，在什么入口点准确地进入，在什么速度准确地进入，有很多材料可供检查，以确定事故的根本原因。当然，这些都不是免费的

---

足够丰富多彩的解释？

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

当达到给定计算机的极限（内存、CPU、磁盘：数据太大，或者数据处理太复杂和昂贵）时，分发服务是一个好主意。许多关系数据库和NoSQL数据库提供分布式存储。然而，在这种情况下，ACID很难满足：状态有些相似，不能同时实现可用性、一致性和分区容差。如果我们放弃酸（例如，满足要求的碱），可伸缩性可能会增加。 关于根据CAP对储存方法的分类，请参见帖子

另一个瓶颈可能是具有SQL操作的灵活而聪明的类型化关系模型本身：在许多情况下，具有简单操作的简单模型就足够了，而且效率更高（如非类型化键值存储）。常见的按行物理存储模型也可能有局限性：例如，它不适合数据压缩

---

然而，随着关系数据库技术的成熟、深入研究和广泛应用，存在快速且可扩展的符合ACID的关系数据库，包括新的数据库，如。我们只需为给定的问题选择合适的解决方案。

定义“不可扩展”。大量的Fish和Stack溢出使用关系数据库，它们每天获得数百万次点击。我的观点是，许多人说关系数据库不能扩展，但他们也不知道如何有效地使用它们。@Oded是的。我看你说得对。像stack overflow这样的网站每天都会收到数百万次点击，显然关系数据库有能力处理它。但我想澄清的是，这里的问题可能是效率问题，也可能是成本问题等等。。。这就是我想知道的。我只是想保持开放的心态；）回答你的问题。关系数据库支持-这是昂贵的。许多NoSQL解决方案消除了ACID施加的一个或多个约束（因此，需要权衡）