Mysql 为什么将写操作扩展到关系数据库几乎是不可能的？

从卡桑德拉的演示幻灯片（幻灯片2）中可以看出：

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

---

我不能理解这种说法。因为当我切分我的数据库时，我正在缩放写入，不是吗？他们似乎对此提出了抗议。。有人知道为什么不切分一个数据库来扩展写操作吗？

显然这是他们的观点，这里的StackOverflow可以简单地证明您可以有效地将关系写操作扩展到繁忙的站点

---

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

当试图扩展数据库以服务于大量并发写入程序时，物理磁盘子系统的速度缓慢通常是要克服的最大挑战。但优化对关系数据库的写入并非“几乎不可能”。这是可以做到的。但也有一个权衡：当您优化写入时，选择逻辑相关数据的大型子集通常会比较慢

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

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

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

---

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

切分数据库实际上与普通SQL数据库大不相同。在很多方面，它更像是一个定制的NoSQL系统，只是碰巧使用数据库进行存储。除非您的数据集由许多完全断开连接的子集组成，否则大多数比get by ID更复杂的查询不会像在单个节点数据库上一样工作

---

另一个原因是，由于对即时一致性的要求，SQL写操作往往相当昂贵—在写操作中更新大型数据库上良好读取性能所需的索引，并检查各种约束。在为水平可伸缩性而设计的系统中，这些附加操作通常要么完全跳过，要么与写操作分开执行。

事实并非如此。这张幻灯片是错误的（或者至少在提出如此大胆的主张时，应该更仔细地限定这一陈述）

---

这意味着，一些基于SQL的产品并不适合某些高可伸缩性场景。假设任何或所有“关系数据库”都会有相同的问题，这是一种严重的过度概括。不幸的是，这只是一种过度概括，而非SQL营销人群正是因为这种过度概括而臭名昭著。

什么样的扩展同样重要。@pst请解释您的评论。缩放意味着在面对更多数据时具有更高的可用性？--Cassandra是围绕分布式（水平缩放）模型明确设计的。“标准”关系数据库通常倾向于垂直扩展。基本方法和保证是不同的。是的，这是水平缩放的一种形式。但是它的功能不同——考虑它是如何手动实现的，例如：在不同的服务器上运行许多不同的DB实例，并确定作为连接时间连接哪个DB实例。但是这里的交通量是现在的0.0001倍facebook@tosum-你不是facebook。如果你在这里获得了.001倍的流量，这是一个成功。我是不是碰到了神经什么的？我想知道StackOverflow是否对他们如何扩展关系数据库有什么建议…或者一些演示文稿？@gyre如果你读过旧的博客帖子和早期的元帖子，你会得到一个想法：一些仔细的非规范化，一个大/快的服务器，世界一流的DBA、注重性能的开发人员和系统管理员，以及手写的sql（无ORM）。虽然仍然如此，但就给定占用空间/价位的纯IOPS吞吐量而言，轴上的SSD是一个革命性的变化。Ok