在锡拉数据库中使用ip地址作为主键是一种好的做法吗？
单独回答您的问题，假设ip地址分布均匀，访问模式分布均匀，这对于任何具有数据分片的数据库都是完全正确的。在很多情况下，当你的分布不是很均匀时，它也会很好。e、 g.您的访问模式比其他模式更能触及某些IP。
根据数据库分片策略，如果您摄取单调递增的值（例如顺序IP）（mongodb、panner、datastore等），则会产生不同的效果。但是在scylladb的情况下，默认情况下，scylla会使用hash3散列每个分区键，因此您可能会假设您的数据摄取是均匀分布在令牌环上的。
不管怎样，如果您需要按key==ip读/写，您没有太多选择。但这取决于你任务的具体情况。
发现有些节点比其他节点有更多的负载（占用更多的磁盘空间），即使拥有的数据很接近（31%~35%）
负载通常以吞吐量来衡量，即磁盘iops或应用程序请求/秒，或以%来衡量利用率。如果考虑磁盘空间利用率，情况就完全不同了。
如果您指的是相对吞吐量节点利用率，那么它可以是，例如：
数据的分发
您的负载（访问）在键空间中的分布，读写之间的关系
节点令牌的分布，仅能给出%方差
如果你指的是磁盘空间，除了我提到的，还有很多其他因素：
提示
未修复示例，修复计划
墓碑、gc、压实
我想知道是不是因为我用ip地址作为主键
不。
而且有些ip地址比其他地址更热（比如那些ip上有更多更新）？
这取决于上述因素和你所说的负荷。如果您是指磁盘空间，那么您的读取访问不会影响它。写作可以。

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

事实上，有些ip地址比其他地址更热，读写次数更多，这通常不是什么大问题，而且是很常见的。scylla将在不同的节点（以及每个节点上的核心）之间随机划分它们，只要您的热分区比集群中的核心多得多，负载和磁盘使用就应该相当平衡。
在极端情况下，情况可能会有所不同，例如每次更新都会增加一个分区（即向其中添加一行），并且只有少数分区非常热。例如，您可以想象一个用于记录请求的数据库，除了每天有10个请求的100万个普通客户端之外，它还有10个每天发出100万个请求的“攻击者”。在这种极端情况下，您会发现有些节点比其他节点承载的负载和/或磁盘空间要大得多。这种极端情况还可能导致其他问题：虽然最近scylla对巨大分区的支持有所改进，但它仍然不够完美，如果您可以避免这种极端情况，那就更好了。
最后，如果我回到您最初的问题“在锡拉数据库中使用ip地址作为主键是一种好的做法吗？”，答案是“是的，但是”：
之所以选择“是”，是因为“锡拉”没有将ip地址作为密钥的具体问题—它将不同的ip地址随机分配给不同的节点（使用“murruL3”散列函数），因此ip地址聚集在一起（例如。，来自同一子网的多个客户端不只是被发送到同一个群集节点）。
这是“但是”，因为问题不是作为密钥的ip地址本身，而是您打算为它存储的分区的内容，以及不同分区的更新频率和大小有多不一致。
哦，还有最后一句话：
如果您使用的是大小分层压缩策略（stcs），那么任何特定时刻的最大磁盘空间使用量都可能远远高于实际存储的数据量。如果您的工作负载覆盖率很高（数据没有被添加，而是被替换、删除等），在压缩完成工作之前，磁盘上的数据很可能是实际数据量的两倍。如果是这种情况，如果您在某个随机时间检查系统，您将注意到某些节点在磁盘上的数据比其他节点多，这取决于您进行此测量时它们在压缩工作中的随机位置。要验证这一点，您可以在所有节点上调用“主要压缩”，然后测量磁盘使用情况—期望在节点之间看到更均匀的磁盘空间使用情况。

由于这些原因，将ip地址作为主键是一种不好的做法。
ip地址可能会更改。如果发生这种情况，我不知道如何使用旧的ip地址查询。
如果您有保留的ip地址（静态且不更改），那么，如果您从少数ip收到更多请求，那么您就不会创建均匀分布的节点。
添加另一个字段可以让事情变得更好，但是，除非我知道访问模式，否则我不能推荐它。