Cinder DB 归档

https://blueprints.launchpad.net/cinder/+spec/db-archiving

我们实际上并没有从数据库中删除行，只是将其标记为已删除（我们有一个特殊的列）。因此数据库会越来越大，这导致性能问题。

问题描述

数据库中大量未使用的的数据会导致各种性能和维护问题

  • 需要在每个查询中过滤掉“标记为已删除”的行

  • 数据库的每个表中都包含大量未使用的的数据，如果操作员在紧急情况下直接使用数据库，则需要对其进行过滤

  • 存储使用率利用率（低优先级）

用例

提议的变更

为每个表创建影子表，并将“已删除”的行从主表复制到影子表。

我们需要提供几种数据归档方法

  • 每个表中归档不超过 N 个“已删除”的行

  • 归档比指定日期更早的“已删除”行

  • 归档所有“已删除”的数据

影子创建可以作为周期性任务或管理员管理工具启动。

备选方案

创建基于事件的解决方案，以便操作员可以订阅“删除”事件并将已删除的数据存储在某个地方。

数据模型影响

  • 创建影子表

  • 实施迁移以将当前“已删除”的行存储在影子表中

  • 影子表可以具有 blob 字段来存储一些“已删除”的数据，并且不施加对数据库模式更改的限制。

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

在每个查询中过滤掉潜在的大量已删除记录不会造成性能损失。

其他部署者影响

  • 操作员或部署者可以使用周期性任务或 Cinder 管理工具来归档“已删除”的数据。

开发人员影响

开发人员应该关心影子表的迁移，就像关心原始表一样

  • 表创建或删除需要创建或删除相应的影子表

  • 当表被修改时，影子表也必须被修改

  • 当一个或多个列移动到新表时，影子表中的列也应该移动到新的影子表，并进行数据迁移

  • 也应该为影子表实现降级：新的表必须被删除，并且迁移的列必须被还原

实现

负责人

主要负责人

Ivan Kolodyazhny (e0ne)

其他贡献者

Boris Pavlovich (boris-42)

工作项

无

依赖项

无

测试

将实施 API 和 Tempest 的单元测试

文档影响

Cloud Administration Guide 将更新，以介绍新的 cinder-manage 命令

参考资料