为什么缩放写入关系数据库实际上是不可能的?

tot*_*sum 8 mysql database sql-server cassandra nosql

来自Cassandra的演示幻灯片(幻灯片2)链接1,备用链接:

缩放写入关系数据库实际上是不可能的

我无法理解这句话.因为当我对我的数据库进行分片时,我正在缩放写入不是吗?而且他们似乎反对这一点..有谁知道为什么不分片数据库缩放写入?

Tim*_*Tim 6

物理磁盘子系统的缓慢通常是在尝试扩展数据库以服务大量并发写入器时要克服的最大挑战.但优化写入关系数据库并非"几乎不可能".可以办到.然而,需要进行权衡:当您优化写入时,选择逻辑相关数据的大型子集通常会更慢.

将主数据写入磁盘以及索引树的重新平衡可能是磁盘密集型的.群集索引的维护(逻辑上属于逻辑的行)在磁盘上物理连续存储,也是磁盘密集型的.这样的索引使得选择(读取)更快,同时减慢写入.因此,重度索引的表不能很好地扩展,并且索引的基数越低,它的扩展性越差.

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

稀疏表与存储逻辑相关的数据完全相反,因此它们在物理上是连续的.在一个稀疏的表格中,作家不会踩到彼此的脚趾,可以这么说.写作就像落在大场上的雨滴,不像地铁站台上的人群,试图通过几扇敞开的门进入火车.稀疏表有助于消除写入瓶颈.

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


Tom*_*son 5

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

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