云数据库管理之数据删除的实现与技术替代方案

发布于: Aug 9, 2022

在云数据库管理方面，我们探索并评估了多种实现方案，意识到不同的方案各有所长、也都在某些方面有所妥协，包括实现方式的简单性、执行效率、关键数据合规性以及功能完整性等等：

扫描数据文件中的每条记录以创建索引 — 每次上传文件时，我们都会遍历其记录并生成元组（包含 userid, s3Uri, row_number），而后将其插入至我们的元数据存储层内。在删除请求时，我们将获取所请求的用户 ID 的元数据记录，下载相应的 S3 对象，就地执行删除，而后重新上传经过更新的对象以覆盖现有对象。这是最为灵活的实现方法，因为其支持通过单一对象存储多个用户的数据，也成为目前最为常见的普遍实现方法。但灵活性也有其代价，由于过程中需要下载并重新上传对象，因此删除操作往往会带来网络瓶颈。用户活动数据集（例如客户产品评论）就特别适合使用此种方法，因为各个分区（例如日期分区）中几乎很少出现同一用户发布多条记录的情况，且最好是将多个用户的活动合并到单一文件当中。
将元数据存储为文件名前缀 — 在按查询模式定义的不同分区之下，将用户 ID 设定为上传对象的名称前缀，能够帮助我们减少删除请求所需要的搜索操作。元数据处理实用程序能够从文件名中直接查找用户 ID，并相应执行索引维护操作。这种方法能够带来极高的资源清除效率，但每个对象只能对应一个用户，且要求我们将用户 ID 存储在文件名当中，这有可能与信息安全要求相违背。这套方案特别适合管理点击流数据，在此类数据流中，会话期间单一日期分区上的单一用户将产生多个点击事件。
使用元数据文件 — 除了上传新对象之外，我们还可以上传可供索引工具使用的元数据文件，借此创建并维护最新索引。根据删除请求，我们可以查询索引、借此将我们指向需要清除的记录位置。此方法最适合在上传新对象时，同步上传对应元数据文件的情况（例如上传多媒体数据）。在其他场景下，在每一次上传对象时都同时上传元数据文件，可能给资源容量带来沉重压力。
使用亚马逊云科技服务的标签功能 — 每当有新文件被上传至 Amazon S3 时，我们都会使用 Put Object Tagging Amazon S3 操作为用户标识添加键值对。而每当出现用户数据删除请求时，即可使用该标签获取对象并将其删除。使用现有 Amazon S3 API 即可轻松实现这套方案，整个过程相当轻松易行。但这套方案也面临着诸多限制，其假定 Amazon S3 对象与用户之间始终为 1：1 的关系（每个对象仅包含单一用户的数据）；此外，基于标签进行对象搜索的方法效率不高，且将用户标识存储为标签形式的作法也可能有违组织内的信息安全要求。
使用 Apache Hudi — Apache Hudi 已经成为 Amazon S3 之上实现记录层级数据删除功能的一种非常流行的选择。Hudi 的最新版本仅限于 Amazon EMR 使用，因此只适合从零开始构建数据湖的用户，即要求您在创建过程中将数据存储为Hudi数据集形式。Hudi 项目本身相当活跃，预计其后续还将迎来更多功能，并与更多亚马逊云科技服务实现集成。

在具体方法的选择当中，我们始终要求将数据存储层与元数据存储层区分开来。因此，这里提出的各种设计方案具备良好的通用性，能够直接插入任何现有数据管道当中。与选择数据存储层相似，大家在选择存储索引方案时也需要考虑到以下重要因素：

请求并发性 — 如果不打算同时插入过多请求，您甚至可以考虑直接将 Amazon S3 这类简单存储方案作为初始索引选项。但如果需要面向众多用户处理多项并发写入，则最好选择那些具备更强事务处理能力的服务。
考虑团队的现有专业知识与基础设施 — 在本文中，我们演示了如何使用 DyanmoDB 与 RDS Postgres 存储及查询元数据索引。如果您的团队在这方面没有任何经验，而且对 Amazon ES, Amazon DocumentDB (兼容 MongoDB)或者其他存储层的效果基本满意，不妨直接使用。另外，如果您已经拥有一套具备冗余容量的 MySQL 数据库，也可以将其作为索引实现方案以节约运营成本。
索引大小 — 元数据的体量往往要比实际数据低几个量级。但是，随着数据集规模的显著增长，您可能需要考虑采用具备强大可扩展能力的分布式存储解决方案，借此替换传统的关系数据库管理系统。