【发布时间】:2010-11-12 15:11:36
【问题描述】:
这是我要解决的问题:我最近完成了数据层重新设计,允许我跨多个分片对数据库进行负载平衡。为了保持分片平衡,我需要能够将数据从一个分片迁移到另一个分片,这涉及从分片 A 复制到分片 B,然后从分片 A 中删除记录。但是我有几个非常大的表,并且有许多外键指向它们,因此从表中删除一条记录可能需要一秒钟以上的时间。
在某些情况下,我需要从表中删除数百万条记录,但这需要太长时间才能实用。
禁用外键不是一种选择。删除大批量的行也不是一种选择,因为这是一个生产应用程序,大删除锁定了太多资源,导致失败。我正在使用 Sql Server,并且我知道分区表,但是分区限制(以及企业版的许可费用)是如此不切实际,以至于无法实现。
当我开始研究这个问题时,我认为最困难的部分是编写算法来计算如何删除从叶级到数据模型顶部的行,这样就不会违反外键约束大大地。但解决这个问题对我没有好处,因为删除需要一夜之间消失的记录需要数周时间。
我已经构建了一种将数据标记为虚拟删除的方法,因此就应用程序而言,数据已经消失了,但我仍在处理大型数据文件、大型备份和较慢的查询,因为桌子的大小。
有什么想法吗?我已经在这里阅读了较早的相关帖子,但没有发现任何有用的信息。
【问题讨论】:
-
为什么不能暂时禁用外键?您能否在维护期间不运行它并禁用对系统的访问?
-
是否可以选择完全不需要执行此复制过程?通过某种算法确保从 go 开始就在分片之间平均分配记录,而不是在创建记录后移动记录以平衡它们。
-
@AdaTheDev,对于新分片,这不是问题,但我最初的部署是备份-恢复,并且在每个副本上,将一半数据标记为虚拟删除。所以这两个碎片是巨大的。 @Mitch,分片的重点是使用更便宜的设备,所以我不会花钱解决问题。 @ck,我不确定 FK 是真正的问题。我认为花费最多的时间是聚集索引删除。
-
你能在这里发布一个执行计划吗?要获得一个,请在 SSMS 中加载查询时按 Control-L,然后截取屏幕截图(假设它都适合一个屏幕)。如果它太大,请查看您是否可以获得基于文本的计划副本。
-
我不想发布实际计划,但我可以很容易地描述它:一个聚集索引在最右边以 66% 删除,然后在 29 下以每个大约 1% 的速度寻找 FK .
标签: sql-server database scalability sharding