3

我将拥有非常宽的 C* 表。为了防止它们变得太宽，我遇到了一个非常适合我的策略。它在此视频中进行了介绍。 明智地存储分区

这种策略的好处是不需要“查找表”（它很快），坏处是需要知道桶的最大数量并最终没有更多桶来使用（不可扩展）。我知道我的最大桶大小，所以我会试试这个。

通过从表的主键计算散列，这可以与其余的主键一起用作存储桶部分。

我想出了以下方法来确保（我认为？）哈希对于特定的主键总是相同的。

使用番石榴散列：

public static String bucket(List<String> primKeyParts, int maxBuckets) {

    StringBuilder combinedHashString = new StringBuilder();
    primKeyParts.forEach(part ->{
        combinedHashString.append(
            String.valueOf(
                Hashing.consistentHash(Hashing.sha512()
                    .hashBytes(part.getBytes()), maxBuckets)
            )
        );
    });
    return combinedHashString.toString();
}

我使用 sha512 的原因是能够拥有最大字符数为 256（512 位）的字符串，否则结果将永远不会相同（根据我的测试似乎）。

我远不是哈希大师，因此我要问以下问题。

要求：在不同节点/机器上的不同 JVM 执行之间，对于给定的 Cassandra 主键，结果应该始终相同吗？

  1. 我可以依靠上述方法来完成这项工作吗？
  2. 有没有更好的散列大字符串的解决方案，所以它们总是会为给定的字符串产生相同的结果？
  3. 我是否总是需要从字符串中进行哈希处理，或者是否有更好的方法来为 C* 主键执行此操作并始终产生相同的结果？

拜托，我不想讨论特定表的数据建模，我只想有一个存储桶策略。

编辑：

进一步阐述并提出了这一点，因此字符串的长度可以是任意的。你对这个有什么看法？

public static int murmur3_128_bucket(int maxBuckets, String... primKeyParts) {

    List<HashCode> hashCodes = new ArrayList();
    for(String part : primKeyParts) {
        hashCodes.add(Hashing.murmur3_128().hashString(part, StandardCharsets.UTF_8));
    };
    return Hashing.consistentHash(Hashing.combineOrdered(hashCodes), maxBuckets);
}
4

1 回答 1

2

我目前在生产中使用类似的解决方案。因此，对于您的方法，我将更改为：

public static int bucket(List<String> primKeyParts, int maxBuckets) {
  String keyParts = String.join("", primKeyParts);
  return Hashing.consistentHash(
                     Hashing.murmur3_32().hashString(keyParts, Charsets.UTF_8),
                     maxBuckets);
}

所以差异

  1. 一次将所有 PK 部分发送到哈希函数中。
  2. 实际上，我们将最大存储桶设置为代码常量，因为只有最大存储桶保持不变时才会产生一致的哈希。
  3. 我们使用 MurMur3 哈希，因为我们希望它快速而不是密码强。

对于您的直接问题 1）是的，该方法应该可以完成工作。2）我认为你应该设置上面的调整。3）假设你需要整个PK？

我不确定您是否需要使用整个主键，因为期望您的主键的分区部分对于许多事情都是相同的，这就是您要分桶的原因。您可以只对将为您提供良好存储桶以在分区键中使用的位进行哈希处理。在我们的例子中，我们只是散列了 PK 的一些集群键部分，以生成我们用作分区键一部分的存储桶 id。

于 2016-10-22T12:52:24.200 回答