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

接下来我在网上阅读了一些文章，指出关系数据库存在扩展问题，在大数据方面不好用。特别是在数据较大的云计算中。但我无法找到很好的理由，为什么它不能通过Google搜索来扩展。当涉及到可伸缩性时，您能否向我解释关系数据库的局限性？为什么关系数据库存在可伸缩性问题？

谢谢。

来源

2012-08-31 lahiru madhumal

定义“不可扩展”。大量的Fish和Stack Overflow使用关系型数据库，每天都会有数百万次点击。 – Oded

我的观点与上述相同，许多人认为关系数据库不能扩展的人是不知道如何有效使用它们的人。 – Oded

@Oded是的。我看到你有一个点。像堆栈溢出这样的站点每天可以获得数百万次点击，并且清晰的关系数据库能够处理它。但我试图澄清自己，可能这里的问题是效率或可能是成本等......这就是我想知道的。我只是想保持开放的态度;） –

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

当达到给定的计算机（内存，CPU，磁盘：数据太大，或数据处理过于复杂和昂贵）的限制时，分发服务是一个好主意。许多关系数据库和NoSQL数据库提供分布式存储。然而，在这种情况下，ACID难以满足：CAP theorem的状态有些类似，因此无法同时实现可用性，一致性和分区容错。如果我们放弃ACID（例如满足BASE），可扩展性可能会增加。请参阅this后，例如。根据CAP对存储方法进行分类。另一个瓶颈可能是使用SQL操作的灵活和聪明的类型化关系模型本身：在很多情况下，操作更简单的简单模型就足够和更高效（就像无类型的键值存储）。常见的逐行物理存储模型也可能是有限的：例如，它对于数据压缩并不是最佳的。

然而，由于关系数据库的技术已经成熟，经过深入研究并广泛存在，但是存在快速且可扩展的ACID兼容关系数据库，包括像VoltDB这样的新数据库。我们必须为给定问题选择适当的解决方案。

来源

2012-09-03 09:25:36 csaba

“这些不能关闭”。这是一个公然的谎言。 DB2允许关闭日志（记录）（如果其他任何大型狗在其产品中缺乏相同的功能，我会感到惊讶）。并猜测，如果你这样做，你的更新程序可能会运行两倍的速度。当然，您付出的代价是在更新运行之前进行备份，以及程序失败时需要恢复的时间。当然，这通常没有完成，但要说它“**不能**”只是表现出无知而不是知识。 –

是的，“不能”在这里可能太强大了。我不知道所有的数据库;但是，例如，使用Oracle nologging子句只会减小日志大小，但不会将其关闭。事务处理和写入撤销信息明确无法关闭，或者如果关闭，数据库不再符合ACID标准。我错了吗？还有一个瓶颈：数据模型和SQL。灵活的模型，聪明的算法;在很多情况下，操作更简单的简单模型就足够且更高效（就像无类型的键值存储）。 – csaba

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

来源

2012-08-31 12:07:15

有趣的[阅读]（http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram）关于Instagram如何处理ID生成问题 – Kermit

@Tomasz，...或者只是使用不同的设置用于不同实例的标识符（例如具有不同的前缀代码或不同范围的值）。这在关系数据库中确实不是一个难题！ – sqlvogel

@Tomasz Nurkiewicz。我只想知道NoSQL如何处理这个问题。它的数据模型能够做到这一点？ – nathan

有一点我认为人们并不认为解析SQL有很大的开销。

这是之一准备好的语句的原因是如此有用。但是，在大多数PHP应用程序的CGI风格的应用程序（运行时间短，许多实例）中，准备好的语句仍然需要解析一次。

通常数据库服务器本身实际上足够快，只是在SQL解析中有开销。 Yoshinori Matsunobu有一个精彩的article关于实现handlerSocket，MySQL + InnoDB的noSQL连接器，据称每秒钟可以实现主键查找750,000个查询，这比他为memcached指出的每秒约420,000个查询要好。

来源

2012-08-31 12:19:08

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

一个有交通灯或警察调节交通，十字路口的运动速度有限，有一个看门狗准确地注册了什么时候准确地在十字路口驾驶什么车，以及它发生了什么方向。

另一方面没有这一点，也没有人以任何速度到达十字路口，只是潜入并希望尽快通过。

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

后者是NOACID类型的引擎。

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

然而，前一种十字路口的优点也应该是显而易见的。减少事故发生的机会。在第二种类型的十字路口，只有当交通密度远低于十字路口的理论最大通过量时，才可能发生事故。在翻译成数据管理引擎时，它转化为保证一致和一致的结果，只有前一种交叉路口（传统数据库引擎，无论是关系型还是网络型或分层式）才能提供。

该比喻可以进一步延伸。想象一下，如果事故发生会发生什么。在第二种类型的十字路口，主要担心的可能是尽可能快地清理道路，因此交通可以恢复，并且在完成后，还有什么信息可以调查谁造成了这起事故以及如何？一点都没有。它不会被知道。十字路口正在等待下一次事故的发生。在受管制的十字路口，有警察调查交通情况，看到发生了什么情况并可以作证。有记录说明哪辆车准确地在什么时间进入，准确地在哪个入口点以准确的速度进入，有很多材料可供检查以确定事故的根本原因。但当然没有一个是免费的。

足够丰富的解释？

来源

2012-09-02 23:09:30

在不受管制的道路上，您只需增加道路宽度即可处理更多交通。在规定的道路上，你必须得到一个新的警察，新的交通灯，摄像头e.t.c ......而不是复杂的部分：两名警察和交通灯必须协调工作。 – joshua

+1多彩说明 – FRoZeN

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

回答

相关问题