问可扩展的跟踪用户活动的方法

EN

如果您认为每个招聘人员可能会查看每个应聘者一次，那么您所指的是最多6万*200万行。这是一个很大的数字，但它们不是很宽的行；正如ErikE解释的那样，每个页面上都可以得到许多行，所以即使是表扫描，总的I/O也不会像听起来那么糟糕。

尽管如此，出于维护的原因，只要您不使用CandidateID进行搜索，您可能希望在RecruiterID上对此表进行分区。例如，您的分区方案可以在1到2000之间为RecruiterID有一个分区，为2001年-> 4000提供一个分区，这样可以使每个分区的行数最大化，并相应地规划文件空间(您可以将每个分区放在自己的文件组中，分离I/O)。

另一点是:如果你想要运行诸如“对这个候选人有多少看法(我们不关心哪个招聘人员)”之类的查询？或者“这个招聘人员看了多少个应聘者(我们不在乎哪个应聘者)？”然后，您可以考虑索引视图。例如。

CREATE VIEW dbo.RecruiterViewCounts
WITH SCHEMABINDING
AS
  SELECT RecruiterID, COUNT_BIG(*)
    FROM dbo.tablename;
GO
CREATE UNIQUE CLUSTERED INDEX pk_rvc ON dbo.RecruiterViewCounts(RecruiterID);
GO

CREATE VIEW dbo.CandidateViewCounts
WITH SCHEMABINDING
AS
  SELECT CandidateID, COUNT_BIG(*)
    FROM dbo.tablename;
GO
CREATE UNIQUE CLUSTERED INDEX pk_cvc ON dbo.CandidateViewCounts(CandidateID);
GO

现在，这些聚集索引的维护成本很高，因此您需要针对它们测试您的写工作负载。但是，他们应该非常、非常快地进行这两个查询，而不必为非常繁忙的招聘人员或非常受欢迎的候选人查找您的大表，并可能读取多个页面。

如果您的表聚集在RecruiterID上，您将有一个非常快的搜索，在我看来，根本没有性能问题。

在你所描述的这样一个狭窄的表格中，找出任何一个招聘人员查看的个人资料应该需要一个单一的阅读99+%。(假设填充因子= 80，页面分割最小；行宽假设两个int列= 16字节+开销，调用20字节；每页8040个左右字节；假设每个招聘人员平均获得4次查看，平均2.5行=每个数据页大约128个招聘人员)。表中的行总数与此无关，因为它可以查找聚集索引。是的，它必须穿过这棵树，但它还是会很快的。只要每个候选人的意见必须计算一次，就没有更好的办法了。如果它只是总的视图，则可以进行计数。

我觉得你没什么好担心的。如果你担心系统每秒会增加到数以万计的请求，你会得到某种有限的活动热点，只要在任何一个时间点访问的招聘人员没有偶然地给他们分配顺序ID，你就会没事的。

这里的大原则是，你想要避免任何需要从上到下扫描桌子的东西。只要您总是通过RecruiterID或RecruiterID, CandidateID进行搜索，就可以避免这种情况。当您想单独通过CandidateID进行搜索时，如果没有额外的索引，您就会遇到麻烦。在CandidateID上添加一个非聚集索引将使表占用的空间翻一番(一半用于集群，一半用于非聚集)，但这并不是什么大不了的事情。然后CandidateID的搜索将同样快，因为非聚集索引将正确覆盖查询，并且不需要书签查找。

更新

这是对您在更新您的问题中提供的大量新信息的答复。

首先，CandidateViewCounts表的命名不正确。它更像是CandidateFirstViewedByRecruiterAtCompany。它只能间接地回答您的问题，即关于公司的问题，而不是招聘人员的问题，所以在我看来，您所描述的场景确实需要一个CompanyCandidateViewed表：

CompanyID int FK
CandidateID int FK
PRIMARY KEY CLUSTERED (CompanyID, CandidateID)

存储查看候选人的招聘人员的CompanyID和CandidateID。很简单！现在，我最初的答案仍然适用于您，只需将RecruiterID与CompanyID交换即可。

如果您确实希望跟踪哪些招聘人员查看了哪些候选人，请在RecruiterCandidateViewed表中这样做(并存储所有招聘人员->候选人视图)。可以稍后查询或在数据仓库中查询。但是，您的实时OLTP需求将由上面描述的表来满足。

此外，我想提到的是，您有可能在不需要标识列的表中放置标识列。您应该避免使用标识列，除非该列将被用作另一个表中的FK (而且有时也不会像在适当的数据建模中那样，因为为了防止可能的反正规化，必须在FKs中使用复合键)。例如，在我看来，您的ViewsAssigner_Identifier表似乎需要一些帮助(当然，我这里没有所有的信息，而且可能不在基础上)。如果Company和Date是该表最重要的部分，那么将它们放在集群PK中，并尽可能地去掉identity列。