2016-10-22 1 views
3

У меня будут таблицы C *, которые будут очень широкими. Чтобы они не стали слишком широкими, я столкнулся с такой стратегией, которая могла бы мне хорошо подойти. Он был представлен в этом видео. Bucket Your Partitions WiselyСгенерируйте хэш харда с * от многофазного первичного ключа

Хорошая вещь с этой стратегией заключается в том, что нет никакой необходимости в «просмотровом стол» (это быстро), плохая часть является то, что нужно знать максимальное количество ведер и в конечном итоге положить конец (без масштабирования). Я знаю свой максимальный размер ковша, поэтому я попробую это.

Вычисляя хэш из первичных ключей таблиц, он может использоваться как часть ведра вместе с остальными первичными ключами.

У меня есть следующий метод, чтобы быть уверенным (я думаю?), Что хэш всегда будет одинаковым для определенного первичного ключа.

Использование Guava хеширования:

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 * и всегда производить тот же результат?

Пожалуйста, я не хочу обсуждать моделирование данных для конкретной таблицы, я просто хочу иметь стратегию ведра.

EDIT:

дорабатываться и придумал это так длина строки может быть произвольным. Что вы скажете об этом?

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); 
} 

ответ

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) Предполагается, что вам нужен весь ПК?

Я не уверен, что вам нужно использовать весь первичный ключ, так как ожидание состоит в том, что ваша часть раздела вашего первичного ключа будет одинаковой для многих вещей, поэтому вы являетесь bucketing. Вы могли бы просто хэш-биты, которые предоставят вам хорошие ведра для использования в вашем разделе. В нашем случае мы просто используем некоторые из кластерных ключевых частей ПК для генерации идентификатора bucket, который мы используем как часть ключа раздела.

+0

Я как раз собирался отредактировать свой «вопрос» с лучшим решением, и он очень похож на – nicgul

+0

oops, hit enter ... посмотреть мое обновление и рассказать мне, что вы думаете. – nicgul

+0

BTW, отличный ответ, дает мне больше уверенности! – nicgul

Смежные вопросы