1

对大量分层数据进行分区是否有任何最佳实践/模式或一般建议？

比如说，一个特定国家/地区所有人的数据库，并跟踪谁与谁共事过。孤立地考虑“人”实体，如果要保存有关每个人的大量数据，那么一种自然的方法似乎是将总体划分为多个水平分区。然而，关系（谁与谁一起工作）可以（并且将）跨越分区a。随着数据变得越来越交叉链接，随着时间的推移，对这些关系进行聚类（例如，使用雇主作为分区键以最小化交叉分区引用）将不可行。这种集群还会导致不平衡的分区，这会妨碍可扩展性。

我现在很困惑，所以对于提供的任何帮助都会非常感激。

谢谢。

4

1 回答 1

1

看来你有三个问题：

  1. 存储有关员工的数据（不包括关系/层次结构）
  2. 雇主到员工的层次结构（可能会随着时间而改变）
  3. 员工到员工的工作历史（同样，随着时间的推移而变化）

依次解决每个问题：

  1. 员工数据：可以使用唯一的 id 进行分区，并使用姓氏+给定姓名+出生日期的备用键。通过 id 或其他信息（例如区域/区域）均匀分布进行分区（尽管这意味着某些分区会比其他分区更热）

  2. 雇主/雇员层次结构：需要一个辅助表来定义它，允许随时间变化。例如。Employee id, Employer id, start date, end date并以另一种方式键入employee id + employer id并返回employer id + employee id。我建议阅读以下内容： http ://www.slideshare.net/billkarwin/sql-antipatterns-strike-back ，它可能有适合您数据大小的想法。

  3. 员工/员工工作历史：需要另一个辅助表，与#2 非常相似，交叉引用员工和他们一起工作的时间。例如。employee1 id, employee2 id, start date, end date，它至少会被每个 id 索引。

这里的关键是不要尝试将关系/层次结构放在员工数据表中 - 这会很慢并且会限制您需要的链接（尤其是随着时间的推移链接会发生变化）。

于 2009-11-26T21:46:21.073 回答