代码之家 › 专栏 › 技术社区 › Ólafur Waage

如何解决软删除项目的缩放问题?

soft-delete scaling mysql

3

Ólafur Waage · 技术社区 · 15 年前

我有一个数据库,其中大多数表都有表的删除标志。因此,系统软删除项目(例如,除非由管理员访问,否则无法再访问这些项目)

我担心的是,几年后,当表格大得多的时候,系统的整体速度将会降低。

我能做些什么来抵消这种影响呢?

是否索引删除字段?
是否将删除的数据移到相同的删除表中,并在取消删除时移回?
我是否会随着时间的推移将数据分布在几个MySQL服务器上?(基于增长)

我很感激你的建议和故事。

更新:

所以分区似乎是实现这一点的关键。但是分区不会只创建两个“表”,一个带有已删除项,另一个不带有已删除项。

因此,随着时间的推移,删除的分区将变大,并且偶尔从中提取数据将变慢(并且随着时间的推移会变慢)。

速度差是我应该担心的吗?因为我通过某个键值获取大多数(如果不是全部)数据(有些是搜索,但对于这个设置,它们可能会很慢)

3 回复 | 直到 15 年前

1

4

Quassnoi 15 年前

我会把桌子分成两半 DELETE 旗帜。

删除的行将实际保留在其他位置,但从 SQL 的视角表保持不变。

2

4

chaos 15 年前

哦,见鬼,是的,索引删除字段。你会一直在质疑它,对吧?与您经常查询的其他字段(如父ID)组合索引也是一个好主意。

3

1

protoscript 15 年前

可以说,只有在性能问题实际出现的情况下,才可以稍后做出此决定。这在很大程度上取决于以什么速率添加多少行、您的框规格等。显然,应用程序中的抽象级别(以及您使用的任何库的限制)将有助于确定这种更改的难度。

如果出现问题,或者您确定会出现问题,那么首先对两个表之间的已删除标志进行分区,一个表保存当前数据,另一个表保存历史/已删除数据。如您所说,如果“已删除”的数据只对管理员可用,则可以合理地假设(在大多数应用程序中)用户总数(此处仅限于管理员)不足以引起问题。这意味着您的管理员在搜索特定表时可能需要等待更长的时间,但您的用户群(在大多数应用程序中可能更重要)将体验到更少的延迟。如果管理员无法接受性能,您可能希望索引您访问已删除记录的用户ID(或事务ID或其他)字段(我通常索引访问表的每个字段,但在一定程度上,可以权衡哪些索引最值得)。

根据数据的访问方式,还可以使用其他简单的技巧。如果管理员大部分时间都在查找特定记录(而不是读取用户活动的“历史记录”或“日志”),则通常可以假定最近的记录比旧记录更经常被查看。一些DBS包括使最近的记录比旧记录更容易找到的优化选项,但您必须在特定的数据库中查找它。如果失败,您可以手动执行。最简单的方法是建立一个包含所有比 n 天、周或月,取决于您的限制条件和可疑的使用模式。然后,新的数据存储在一个小得多的表中。即使管理员要“浏览”所有记录,而不是搜索特定的记录,也可以从显示第一个记录开始。 n 天,并且有一个链接可以查看所有天,如果他们找不到他们要查找的内容(例如,大多数在线银行应用程序允许您浏览交易,但仅显示历史的前30天,除非您另有要求)。

希望您可以避免进一步,以及共享用户ID或其他类似方案。根据应用程序其余部分的规模,您可能无论如何都必须这样做。除非你肯定你需要这样做,否则我强烈建议首先使用垂直分区(例如,将论坛帖子放在单独的机器上,而不是放在销售记录上),因为这样设置和维护起来要容易得多。如果你最终需要分享用户ID,我建议你使用google;-]

祝你好运。顺便说一句,我不是DBA,所以拿这个加一点盐。