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

Question

接下来,我在网上阅读了一些文章,这些文章表明关系数据库存在扩展问题,而且在涉及大数据时并不好用.特别是在数据量很大的云计算中.但是我找不到很好的理由来解释为什么它不具有可扩展性,通过谷歌搜索.在可伸缩性方面,您能否解释一下关系数据库的局限性？

谢谢.

Answer 1

想象一下两种不同的十字路口.

一个人有交通信号灯或警察调节交通,十字路口的行动速度有限,并且有一个看门狗准确记录了什么时候汽车在十字路口开车,以及它走向的方向.

另一个没有那个,每个人都以他开车的速度到达十字路口,只是潜入并希望尽快通过.

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

后者是NOACID类型的引擎.

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

然而,前一种十字路口的优点也应该是显而易见的.减少事故发生的机会.在第二种类型的十字路口,只有当交通密度比十字路口的理论最大吞吐量低得多时,才能发生事故.在转换为数据管理引擎时,它转化为保证一致且连贯的结果,只有前一种类型的十字路口(经典数据库引擎,无论是关系型还是网络型或分层式)才能提供.

类比可以进一步拉伸.想象一下如果事故发生会发生什么.在第二种类型的十字路口,主要关注的可能是尽快清理道路,以便恢复交通,一旦完成,还有什么信息可以调查谁造成了事故以及如何？什么都没有.它不会被人知道.十字路口正在等待下一次事故发生.在规范的十字路口,有警察管理交通谁看到发生了什么,并可以作证.有记录说明哪辆车准确进入,准确地进入哪个入口点,准确地以什么速度进行检查以确定事故的根本原因.但当然,这些都不是免费的.

足够丰富多彩的解释？

Answer 2

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

当达到给定计算机的限制时(内存,CPU,磁盘:数据太大,或者数据处理过于复杂和昂贵),分发服务是个好主意.许多关系数据库和NoSQL数据库提供分布式存储.然而,在这种情况下,ACID难以满足:CAP定理有些类似,无法同时实现可用性,一致性和分区容差.如果我们放弃ACID(例如,满足BASE),可能会增加可伸缩性.看这篇文章,例如.根据CAP对存储方法进行分类.

另一个瓶颈可能是具有SQL操作的灵活且聪明的类型关系模型:在许多情况下,具有更简单操作的更简单模型将足够且更有效(如无类型键值存储).常见的行式物理存储模型也可能是限制性的:例如,它不是数据压缩的最佳选择.

然而,随着关系数据库技术的成熟,研究和广泛应用,存在快速且可扩展的ACID兼容关系数据库,包括VoltDB等新关系数据库.我们只需为给定的问题选择合适的解决方案.