为啥将写入扩展到关系数据库几乎是不可能的？

Posted 2023-02-24

【中文标题】为啥将写入扩展到关系数据库几乎是不可能的？

【英文标题】：why is scaling writes to a relational database virtually impossible?为什么将写入扩展到关系数据库几乎是不可能的？

【发布时间】：2011-10-03 20:17:24

【问题描述】：

来自 Cassandra 的演示幻灯片（幻灯片 2）link 1、alternate link：

几乎不可能扩展对关系数据库的写入

我无法理解这句话。因为当我对数据库进行分片时，我正在扩展写入，不是吗？他们似乎反对这一点.. 有谁知道为什么不分片数据库扩展写入？

【问题讨论】：

什么类型的缩放也很重要。

@pst 请解释您的评论。缩放意味着在面对更多数据时具有更高的可用性？

Scalability -- Cassandra 是围绕分布式（水平扩展）模型明确设计的。 “标准”关系数据库通常倾向于垂直扩展。基本方法和保证是不同的。见Drop ACID and Think About Data。

是的，sharding 是水平缩放的一种形式。然而，它的功能不同——考虑如何手动实现它，例如：在不同的服务器上运行许多不同的数据库实例，并确定连接到哪一个作为连接时间。

【参考方案1】：

显然这是他们的观点，这里的 *** 是一个简单的证据，证明您可以有效地将关系写入扩展到繁忙的站点。

像 Cassandra 这样的 NoSQL 提供商确实让更容易扩展到多台服务器，但这对于传统数据库并非不可能，而且很少需要扩展到多台数据库服务器。

【讨论】：

我并不是要关闭***，但这里的流量大约是facebook流量的0.0001倍

@tosum - 你不是 facebook。如果您在这里获得 0.001 倍的流量，那就是成功了。

我是不是伤到神经了？

我想知道 *** 是否对他们如何设法扩展关系 DB..或一些演示文稿有任何建议？

@gyre 如果您阅读旧博客文章和早期元文章，您会得到一个想法：一些 小心 非规范化，一个 大/快 i> 服务器，世界级的 DBA，具有良好性能意识的开发人员和系统管理员，以及手写 sql（无 ORM）。

【参考方案2】：

在尝试扩展数据库以服务大量并发写入者时，物理磁盘子系统的缓慢通常是要克服的最大挑战。但优化对关系数据库的写入并非“几乎不可能”。可以办到。然而有一个权衡：当您优化写入时，选择逻辑相关数据的大子集通常会更慢。

将主要数据写入磁盘和重新平衡索引树可能是磁盘密集型的。聚集索引的维护，即逻辑上属于一起的行在磁盘上物理上连续存储，也是磁盘密集型的。这样的索引使选择（读取）更快，同时降低了写入速度。因此，索引过多的表无法很好地扩展，并且索引的基数越低，它的扩展性就越差。

旨在提高并发写入器速度的一项优化是使用具有散列主键和最少索引的稀疏表。这种方法消除了对主键值的索引的需要，并允许立即查找行所在的磁盘位置，“立即”是指不需要索引读取的中介。散列主键算法使用主键值本身返回行的物理地址——一个不需要磁盘访问的简单计算。

稀疏表与存储逻辑相关数据完全相反，因此它们在物理上是连续的。在一张稀疏的桌子上，作家们不会互相踩脚，可以这么说。写作就像雨滴落在广阔的田野上，不像地铁站台上的一群人试图通过几扇敞开的门进入火车。稀疏表有助于消除写入瓶颈。

但是，由于逻辑上相关的数据在物理上不是连续的，而是分散的，所以收集某个邮政编码中的所有行的行为，比如说，代价高昂。因此，只有当主要活动是插入记录、更新单个记录以及一次查找与单个实体相关的数据而不是与大量实体相关的数据时，这种稀疏表哈希 pk 优化才是最佳的，例如，订单输入系统。一家在电视上销售商品并且必须同时为数以万计的同时下订单的呼叫者提供服务的公司，可以通过使用带有散列主键的稀疏表的系统来很好地服务。这种方法也可以很好地服务于依赖链表的国家安全数据库。许多社交网络应用程序也可以利用它。

【讨论】：

虽然仍然如此，但在给定的占用空间/价格点下，就纯 IOPS 吞吐量而言，位于主轴之上的 SSD 是一种革命性的变化。

好吧，分片有它的局限性。那么您建议的更好的选择是什么？

【参考方案3】：

分片数据库实际上与普通的 SQL 数据库完全不同。在很多方面，它更像是一个定制的 NoSQL 系统，只是碰巧使用数据库进行存储。除非您的数据集包含大量完全不连贯的子集，否则大多数比通过 ID 获取更复杂的查询不会像在单节点数据库上那样工作。

另一个原因是，由于需要立即保持一致性，SQL 写入往往相当昂贵 - 在大型数据库上获得良好读取性能所需的索引会作为写入操作的一部分进行更新，并且会检查各种约束.在为水平可扩展性而设计的系统中，这些额外的操作通常要么完全跳过，要么与写入分开执行。

【讨论】：

换句话说：NoSQL 有时会更快，因为您允许它经常返回陈旧（错误！）数据。

【参考方案4】：

事实并非如此。幻灯片是错误的（或者至少在做出如此明显的大胆声明时应该更仔细地限定声明）。

这意味着某些基于 SQL 的产品不适合某些高可扩展性场景。假设任何或所有“关系数据库”都会有同样的问题，这将是一个严重的过度概括。不幸的是，这只是 No-SQL 营销人群臭名昭著的那种过度概括。