关系型 DBMS 真的很难扩展吗？答案

【问题标题】：Are Relational DBMS actually difficult to scale?关系型 DBMS 真的很难扩展吗？
【发布时间】：2021-02-18 14:10:26
【问题描述】：

我知道关于 SO 有类似的问题，但有些问题已有十年之久，而其他问题则没有有用的答案。

我是系统设计领域的新手。我在创建一些小型项目的关系 DBMS 方面有一些经验。

“关系型与非关系型 DBMS”上的每篇文章都指出，由于 ACID 事务、参考完整性约束和一致性，关系型 DBMS 难以扩展。但另一方面，像 Amazon 和金融服务这样的巨头继续使用关系型 DBMS，而且它们似乎在可扩展性方面没有任何问题。

我只是想从理论上了解关系型 DBMS 是否真的难以扩展？如果是，这些公司如何使用它处理数 TB 的数据？

谢谢！

【问题讨论】：

标签： database database-design relational-database consistency non-relational-database

【解决方案1】：

只要数据是第三范式，并且应用了适当的索引，应该没有问题。这需要知道要存储哪些数据以及需要如何访问这些数据。

在一定规模下（例如，我有一个系统每天向 1 个表添加多达 1800 万行），您可能希望有一个流程来将新数据传输到分析数据库（OLAP - 例如 SQL Server 分析数据库, MSAS)。 OLAP 的设计相对容易，但是如果没有经验，即使每天都保持最新状态的过程也很难设计和管理。对 OLAP 数据库的查询针对报告进行了优化；我不相信对我提到的系统的任何查询平均需要超过 3 秒才能完成。

【讨论】：

但是假设我不规范化数据并且也使用索引，如果我要对分片数据执行 ACID 事务，在某个点之后性能会受到影响，对吗？
Normalizing 和 ACID 没有任何关系。如果您不对基础数据进行规范化，那么查询将从一开始就表现不佳并且变得更糟。但是，如果一组非规范化表是从规范化数据派生的，则可以提高报告性能 - OLAP 数据库基本上就是这样。
是的 Normalizing 和 ACID 彼此无关。我的意思是，即使我采取措施通过不规范化数据（这意味着没有连接，但是写入操作会很慢）并应用索引来提高性能，但如果我对数据进行分片，关系数据库将无法扩展由于 ACID 事务，超出了某个点。我说的对吗？
从未听说过 ACID 在标准化数据库中导致性能问题。在我确信非规范化是必要的情况下，我确实遇到了它。我错了。
不管我是否规范化，无论如何分片数据都会影响性能，因为 ACID 事务？此外，如果相关的表存储在不同的机器上（可能是因为存储空间的限制），连接将变得非常昂贵。这让我回到了同一点，这些大公司如何能够在不损失性能的情况下扩展他们的关系数据库。