最近，我在网上读到一些文章，指出关系数据库存在可伸缩性问题，在处理 Big Data 时不适合使用.特别是在云计算中，那里的数据量很大.但是，通过谷歌搜索，我找不到很好的可靠理由来解释为什么它没有多少可伸缩性.您能给我解释一下关系数据库在可伸缩性方面的局限性吗？
谢谢
最近，我在网上读到一些文章，指出关系数据库存在可伸缩性问题，在处理 Big Data 时不适合使用.特别是在云计算中，那里的数据量很大.但是，通过谷歌搜索，我找不到很好的可靠理由来解释为什么它没有多少可伸缩性.您能给我解释一下关系数据库在可伸缩性方面的局限性吗？
谢谢
关系数据库根据这ACID个属性提供可靠、成熟的服务.我们获得了事务处理、高效的日志(log)记录以实现恢复等.这些都是关系数据库的核心服务，也是它们擅长的服务.它们很难定制，可能会被认为是一个瓶颈，特别是如果您在给定的应用程序中不需要它们的话(例如，提供重要性较低的网站内容；例如，在这种情况下，广泛使用的MySQL不提供默认存储引擎的事务处理，因此不满足ACID).许多" Big Data "问题不需要这些严格的约束，例如网络分析、网络搜索或处理移动对象轨迹，因为它们本质上已经包含了不确定性.
当达到给定计算机的极限(内存、CPU、磁盘:数据太大，或者数据处理太复杂且成本太高)时，分发服务是个好主意.许多关系数据库和NoSQL数据库都提供分布式存储.然而，在这种情况下，ACID很难满足:CAP theorem个状态有点相似，不能同时实现可用性、一致性和分区容错.如果我们放弃酸(例如，令人满意的碱)，可伸缩性可能会增加. 参见this帖子，例如.用于根据CAP对存储方法进行分类.
另一个瓶颈可能是具有SQL操作的灵活且智能的类型化关系模型本身:在许多情况下，具有更简单的操作的更简单的模型就足够并且更高效(如非类型化的键值存储).常见的行式物理存储模型可能也有局限性:例如，它对于数据压缩并不是最佳的.
然而，随着关系数据库技术的成熟、充分研究和广泛应用，有快速且可扩展的符合ACID的关系数据库，包括像VoltDB这样的新数据库.我们只需要为给定的问题 Select 合适的解决方案.