在scylla db中，将IP地址用作主键是一种好习惯吗？

Question

我正在使用scylla db，并且有一个使用IP地址作为主键的表。群集的RF为3。我发现有些节点的负载（占用更多磁盘空间）比其他节点多，即使owns统计数据接近（31％〜35％）

我想知道是因为我使用IP地址作为主键，并且某些IP地址比其他IP地址更热（例如，对这些IP进行更多更新）吗？

Answer 1

您可能是对的，最好添加另一个字段以更好地传播数据

Answer 2

事实上，某些 IP 地址比其他 IP 地址更热（获得更多的读取或写入）通常不是一个大问题，而且很常见。Scylla 会将它们在不同节点（以及每个节点上的核心）之间随机划分，只要您的热分区比集群中的核心多得多，负载和磁盘使用情况就应该相当平衡。

在极端情况下，情况可能会变得不同，例如当每次更新都会增加一个分区（即向其中添加一行），并且只有少数分区非常热时。例如，您可以想象一个用于记录请求的数据库，除了每天发出 10 个请求的 100 万个正常客户端之外，它还有 10 个每天发出 100 万个请求的“攻击者”。在这种极端情况下，您可能会发现某些节点比其他节点承载更多的负载和/或磁盘空间。这种极端情况还会导致其他问题：虽然Scylla对巨大分区的支持最近有所改善，但仍然不够完美，如果能避免这种极端情况就更好了。

最后，如果我回到你原来的问题，“在 scylla db 中使用 IP 地址作为主键是一个好的做法吗？”，答案是“是的，但是”：

之所以说“是”，是因为 Scylla 在将 IP 地址作为密钥时没有具体问题 - 它会将不同的 IP 地址随机分配到不同的节点（使用“murmur3”哈希函数），因此 IP 地址聚集这一事实并不存在特殊问题在一起（例如，来自同一子网的多个客户端不仅仅被发送到相同的集群节点）。

这是“但是”，因为问题不在于 IP 地址本身作为密钥，而在于您打算为其存储的分区的内容，以及不同分区的更新频率和大小的偏差程度。

哦，最后一点：

如果您使用大小分层压缩策略(STCS)，则任何特定时刻的最大磁盘空间使用量可能远高于实际存储的数据量。如果您的工作负载覆盖率很高（数据没有被添加，而是被替换、删除等），那么在压缩完成工作之前，磁盘上的数据很可能是实际数据量的两倍。如果是这种情况，如果您在某个随机时间检查系统，您会注意到某些节点在磁盘上比其他节点拥有更多数据，具体取决于执行此测量时它们在压缩工作中的随机位置。为了验证这是否是您所看到的，您可以执行以下操作：在所有节点上调用“主要压缩”，然后测量磁盘使用情况 - 期望看到节点之间的磁盘空间使用情况更加统一。