mysql - 关系数据库架构设计: Versioning properties on a large scale

Question

我在设计具有版本控制的动态属性模式时遇到一些问题。假设以下用例:

我有一个名为 Actor 的表，其中包含 id 和 name (为了简单起见)。我的情况的上限是，该表包含大约 100 万个条目。

此外，每个 Actor 都会获得分配给他们的属性。因为当时不知道属性，所以需要一个表来管理属性。我想到了一个Property表。生成的 n:m 关系将通过 Actor 和 Property 之间的表进行解析，其中包含它们的主键和属性值(类型？)。

目前这似乎很容易处理。如果有 100 万个条目，每个条目有 10 个属性，则 ActorProperty 表将有 1000 万个节点。我相信使用 btree 索引 (log2(n)) 这应该没有问题。

现在是我正在努力解决的部分。应该以某种方式跟踪这些属性。随着时间的推移，这些属性会发生变化，但历史不应丢失。最有可能的是它会通过时间戳来完成。请注意，多个属性会同时更新。一个例子是:我每天都会为所有 Actor 拍摄快照，如果有变化，我将同时更新所有更改的属性。这会产生每年 365 个时间戳。

如果我使用另一个表来管理版本(时间戳)并向 ActorProperty 表添加另一个外键，我将获得 365 * 1000 万个条目。这应该是我能得到的最大值。大多数时候，数据集会小得多。

我现在的问题更多的是解决性能问题。我阅读了以下有关索引的答案:How does database indexing work 。查询具有这么多条目的表不是很慢吗？一个示例查询是:前 100 个参与者及其所有属性在给定时间戳 id=x 处。我也觉得我正在考虑的模式可能不是最好的。有人对具有更高可扩展性的模式有任何建议或想法吗？

顺便说一句，我目前也在评估 NoSql 方法，所以我想暂时专注于关系方法。我的目标是收集不同技术的优点和缺点，然后为所描述的用例建立一个理论架构或模型。我似乎很难评估或找到关系数据库上最佳模型的性能。

谢谢!

Answer 1

The properties should somehow be tracked

准确地如何跟踪它们是这里的重要事情。以最简单的情况为例，您希望在任何给定时间查询状态 - 因此解决方案是在分解表中包含多个与时间相关的记录:

create table actor_property (
  actor_id INT NOT NULL,
  property_id INT NOT NULL,
  starttime DATE NOT NULL,
  endtime DATE NOT NULL DEFAULT 99991231
  PRIMARY KEY (actor_id, property_id, starttime, endtime) 
);

这样做的结果是，当您尝试将参与者链接到属性并且该链接已存在于表中时，您需要处理这种情况(您无法在触发器中更新表，但可以检查冲突并强制异常(exception))。然后您可以随时查询数据的状态......

SELECT a.name, property.name
FROM actor a
INNER JOIN actor_property ap
   ON a.id=ap.actor_id
INNER JOIN property p
   ON p.property_id
WHERE $snapshot_date >= ap.starttime
AND $snapshot_date <= ap.endtime

在上面使用 actor_property 中当前记录的物化 View 会稍微快一些 - 取决于关系更改的频率。

Is it not awfully slow to query a table with that amount of entries?

并非如此，除非您需要经常分析整个数据集，否则大多数操作仅查看行的一小部分，并且通常数据库会发展热数据区域 - 读取缓存比 mysql 的查询缓存(这是非常具体)。