稍后我在线阅读了一些文章，指出关系数据库存在扩展问题，而且在大数据方面不好用。特别是在数据量很大的云计算中。但是我找不到很好的理由来解释为什么它不具有可扩展性，通过谷歌搜索。在可伸缩性方面，您能否解释一下关系数据库的局限性？
感谢。
答案 0 :(得分：20)
想象一下两种不同的十字路口。
一个人有红绿灯或警察调节交通，十字路口的行动速度有限，并且有一个看门狗准确地记录了什么时候汽车在十字路口开车的方向，以及它走向的方向。
另一个人没有那个，每个人都以他开车的速度到达十字路口，只是潜入并希望尽快通过。
前者是任何传统的数据库引擎。十字路口就是数据本身。汽车是想要访问数据的交易。交通信号灯或警察是DBMS。看门狗保存日志和日记。
后者是NOACID类型的引擎。
两者都有一个饱和点，此时到达的汽车被迫开始在入口点排队。两者都具有最大吞吐量。对于前一种类型的十字路口，这个门槛值较低，原因应该是显而易见的。
然而，前一种十字路口的优点也应该是显而易见的。减少事故发生的机会。在第二种类型的十字路口，只有当交通密度比十字路口的理论最大吞吐量低得多时，才能发生事故。在转换为数据管理引擎时，它转化为保证一致且连贯的结果，只有前一种类型的十字路口（经典数据库引擎，无论是关系型还是网络型或分层式）才能实现。可以进一步拉伸类比。想象一下如果事故发生会发生什么。在第二种类型的十字路口，主要关注的可能是尽快清理道路，以便恢复交通，一旦完成，还有什么信息可以调查谁造成了事故以及如何？什么都没有。它不会被人知道。十字路口正在等待下一次事故发生。在规范的十字路口，有警察管理交通谁看到发生了什么，并可以作证。有记录说明哪辆车准确进入，准确地进入哪个入口点，准确地以什么速度进行检查以确定事故的根本原因。但当然，这些都不是免费的。
足够丰富多彩作为解释？
答案 1 :(得分：13)
关系数据库根据ACID属性提供可靠，成熟的服务。我们获得事务处理，高效日志记录以实现恢复等。这些是关系数据库的核心服务，以及他们擅长的服务。它们很难定制，并且可能被视为瓶颈，特别是如果您在给定的应用程序中不需要它们（例如，提供低重要性的网站内容;例如，在这种情况下，广泛使用的MySQL不提供使用默认存储引擎进行事务处理，因此不满足ACID）。许多“大数据”问题不需要这些严格的约束，例如网络分析，网络搜索或处理移动物体轨迹，因为它们已经包含了不确定性。
当达到给定计算机的限制时（内存，CPU，磁盘：数据太大，或者数据处理过于复杂和昂贵），分发服务是个好主意。许多关系数据库和NoSQL数据库提供分布式存储。然而，在这种情况下，ACID难以满足：CAP theorem状态有些类似，无法同时实现可用性，一致性和分区容差。如果我们放弃ACID（例如，满足BASE），可能会增加可伸缩性。 见this帖子，例如。根据CAP对存储方法进行分类。
另一个瓶颈可能是具有SQL操作的灵活且聪明的类型关系模型本身：在许多情况下，具有更简单操作的更简单模型将足够且更有效（如无类型键值存储）。常见的行式物理存储模型也可能是限制性的：例如，它不是数据压缩的最佳选择。
然而，由于关系数据库技术成熟，研究和广泛，因此有一些快速且可扩展的符合ACID标准的关系数据库，包括VoltDB等新关系数据库。我们只需为给定的问题选择合适的解决方案。
答案 2 :(得分：2)
举一个最简单的例子：插入一个带有生成ID的行。由于ID在表中必须是唯一的，因此数据库必须以某种方式锁定某种持久性计数器，以便其他INSERT不使用相同的值。所以你有两个选择：要么只允许一个实例写入数据，要么分配锁定。这两个解决方案都是一个主要的瓶子 - 并且是最简单的例子！