我正在使用 scylla db 并有一个使用 IP 地址作为主键的表。集群的 RF 为 3。
我发现即使owns 统计数据接近（31% ~ 35%），有些节点的负载（占用更多磁盘空间）也比其他节点多。
我想知道是因为我使用 IP 地址作为主键，并且某些 IP 地址比其他 IP 地址更热（比如对这些 IP 进行更多更新）？
【问题讨论】：
您可能是对的，最好添加另一个字段以更好地传播数据
【讨论】：
在 scylla db 中使用 IP 地址作为主键是一种好习惯吗？
单独回答您的问题，假设 IP 地址均匀分布并且您的访问模式均匀分布，那么对于任何具有数据分片的数据库来说都是完全可以的。在很多情况下，当您的分布不是很均匀时，它也会很好。例如您的访问模式对某些 IP 的影响比其他 IP 多。
根据数据库分片策略，如果您摄取单调递增的值（例如顺序 IP）（MongoDB、Spanner、DataStore 等），则会有所不同。但在 ScyllaDB 的情况下，默认情况下，Scylla 使用 MurMurHash3 对每个分区键进行哈希处理，因此您可以假设您的数据摄取均匀分布在令牌环中。
无论如何，如果您需要通过 Key == IP 进行读/写，您别无选择。不过，这可能取决于您的任务的具体情况。
发现一些节点比其他节点负载更多（占用更多磁盘空间），即使拥有的统计数据接近（31% ~ 35%）
负载通常以吞吐量衡量，即磁盘 IOPS 或应用程序请求/秒，或以百分比为单位的利用率。如果您考虑磁盘空间利用率，情况就完全不同了。
如果您的意思是相对吞吐量节点利用率，那么它可以是例如：
如果你指的是磁盘空间，除了我提到的还有很多其他因素：
我想知道是因为我使用IP地址作为主键
没有。
并且某些 IP 地址比其他 IP 地址更热（比如这些 IP 的更多更新）？
这取决于上述因素以及负载的含义。如果您指的是磁盘空间，则您的读取访问不会影响它。写可以。
【讨论】：
由于这些原因，将 IP 地址作为主键是一种不好的做法。
【讨论】：
某些 IP 地址比其他 IP 地址更热（读取或写入更多）这一事实通常不是一个大问题，而且很常见。 Scylla 会在不同节点（以及每个节点上的核心）之间随机分配它们，只要您的热分区比集群中的核心多得多，负载和磁盘使用量就应该相当平衡。
在极端情况下情况可能会有所不同，例如每次更新增长一个分区（即向其中添加一行），并且只有少数分区非常热。例如，你可以想象一个用来记录请求的数据库，除了一百万个普通客户端每天有 10 个请求之外，它还有 10 个“攻击者”每天发出一百万个请求。在这种极端情况下，您会发现一些节点承载的负载和/或磁盘空间比其他节点多得多。这种极端情况也可能导致其他问题：虽然最近 Scylla 对大分区的支持有所改进，但仍不完美，如果能避免这种极端情况，那就更好了。
最后，如果我回到你原来的问题，“在 scylla db 中使用 IP 地址作为主键是一种好习惯吗？”，答案是“是的，但是”：
这是“是”，因为 Scylla 没有将 IP 地址作为密钥的具体问题 - 它随机地将不同的 IP 地址分配给不同的节点（使用“murmur3”哈希函数），因此 IP 地址没有特别的问题地址聚集在一起（例如，来自同一子网的多个客户端不只是被发送到同一个集群节点）。
这是“但是”，因为问题不在于将 IP 地址本身作为密钥，而在于您打算为其存储的分区的内容，以及不同的更新频率和大小的偏差程度分区。
哦，还有最后一点：
如果您使用 Size Tierd Compaction Strategy (STCS)，则任何特定时刻的最大磁盘空间使用量都可能远高于实际存储的数据量。如果您的工作负载覆盖率很高（没有添加数据，而是替换、删除等），那么在压缩完成其工作之前，磁盘上的数据很可能是实际数据量的两倍。如果是这种情况，如果您在某个随机时间检查系统，您会注意到某些节点在磁盘上的数据比其他节点多，这取决于您执行此操作时它们在压缩工作中的随机位置测量。您可以做一些事情来验证这是否是您所看到的，即在所有节点上调用“主要压缩”，然后测量磁盘使用情况 - 期望在节点之间看到更加统一的磁盘空间使用情况。
【讨论】：