database - 在 scylla db 中使用 IP 地址作为主键是一个好习惯吗？

Question

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

我想知道是因为我使用 IP 地址作为主键，并且某些 IP 地址比其他 IP 地址更热(比如这些 IP 的更多更新)？

Answer 1

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

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

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

它是"is"，因为 Scylla 没有将 IP 地址作为 key 的特定问题 - 它随机将不同的 IP 地址分配给不同的节点(使用“murmur3”哈希函数)，因此 IP 地址聚集这一事实没有特别的问题在一起(例如，来自同一子网的多个客户端不只是被发送到相同的集群节点)。

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

哦，还有最后一点:

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