选择分区键
虽然在某些情况下记录用户 ID 对于区分可能同时发生的不同用户的事件可能很重要，但用户 ID 可能不是分区键的最佳选择。也就是说，除非您打算分析特定用户的行为。
您可能更关心热图如何随时间而变化，特别是涉及页面的哪些区域。对于您的分区键，这些可能是更好的考虑因素，尽管可能不存储为时间戳或 X/Y 坐标，我稍后会介绍。
您通常希望选择具有 (1) 大量值分布的分区键，以在整个集群中创建均匀的负载，并且 (2) 由相对“众所周知”的值组成。我所说的“众所周知”是指您事先知道的东西，或者可以轻松且确定地计算的东西。例如，您将拥有许多用户，并且会在很多天里收集统计数据。虽然可以根据已知的开始/结束日期范围或查询输入轻松确定具体的日期（例如编码为 YYYY-MM-DD 字符串），但所有有效用户 ID 的集合（假设 UUID 或其他非如果不扫描整个集群，就很难确定增量值或哈希值。避免进行分区键扫描；旨在“精确”随机访问您的分区。
分区键格式
在许多示例中，分区键传统上显示为单列，但您可以拥有多列分区键。这在使用日期/时间信息作为全部或部分密钥时很有用。您的目标是使每列的唯一值尽可能少，以便您需要枚举的值集尽可能小，但需要尽可能多的值（或附加列）来平衡 I/O 负载和数据在整个集群中分布。
例如，如果您要使用时间戳作为分区键，在 64 位 Java 时间戳格式中，每秒有 1,000 个可能的分区。即使您可以在技术上对它们进行迭代，也可能比您需要或想要的更精细。另一方面，如果您的分区键只是 4 位数的年份，那么该年的 所有 事件将转到同一分区（使其非常大）和同一组副本节点（热点，集群使用效率低下）。通过选择在这些极端情况之间取得平衡的键，您可以控制分区的大小以及为满足查询而必须访问的分区数。
还要考虑当您想要删除旧数据时会做什么。最简单的方法（在单个列族/表中）是删除整个分区，因为这有助于避免累积单个列墓碑。如果您曾经想要运行“删除所有早于 2013 年的数据”之类的操作，那么您肯定不想将日期深深地埋在数据中，而是希望将其作为分区的一部分键。
选择行（集群）键
主键中不属于分区键的任何附加列成为分区内的行键，并且这些行由集群（排序）这些列中第一列的排序顺序。
集群/排序很重要，因为它通常是您使用 Cassandra 获得的唯一原生排序。即使分区键下降到特定日期的特定小时或分钟级别，您也可以选择按毫秒时间戳或时间 UUID 对行进行聚类，以使该分区中的所有内容按时间顺序排列。
您仍然可以在行键中添加其他列，例如您的 X/Y 坐标或用户 ID——以防听起来我建议您将时间（仅）放在 both分区和集群键。
使用 X/Y 坐标
这部分与 Cassandra 无关，但如果您要对页面进行热映射，请注意人们以不同的分辨率使用不同的屏幕和设备。除非您在您的网站上进行像素完美的布局（并且希望您使用的是流畅的响应式布局），否则一个用户的 X/Y 坐标不会与另一个用户的 X/Y 坐标相匹配。如果同一用户切换设备，它们甚至可能不匹配。
考虑映射的不是鼠标的 X/Y 坐标，而是 DOM 中元素的 ID。为您的“侧边栏”、“主菜单”、“主体 div”和您想要映射的任何特定元素设置一个 ID。这些将是字符串键，而不是坐标对，虽然它们仍会在鼠标进入/离开/单击时触发，但记录的信息不依赖或假定任何特定的屏幕几何形状。
也许您也决定将元素 ID 作为行键或分区键的一部分。