Что такое функция Ha sh с минимальным коллизированием для строк с длиной <255 символов и достаточно быстрым?

Question

Мы получаем транзакционные данные с идентификатором транзакции длиной <255 символов и всегда УНИКАЛЬНЫ. </p>

Но здесь есть ограничение: нам не разрешается хранить идентификатор транзакции в нашей базе данных.

Следовательно, чтобы уникально идентифицировать транзакцию, мы думали об использовании ha sh fn для генерации ha sh с использованием идентификатора транзакции в качестве ввода.

Таким образом, мы не сохраняем дубликат транзакции, поскольку это повредит метаданные, которые мы хотим вычислить. Пример: средние значения, стандартные отклонения и т. Д. c.

Для больших объемов данных транзакций, поступающих в систему, что является га sh fn, который вы бы порекомендовали с более низкой вероятностью столкновений и достаточно быстрым?

Под достаточно быстрым я имею в виду , генерировать га sh за <100 нс. </p>

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

Я также посмотрел несколько ответов на StackOverFlow, в которых предполагалось, что SHA-512 работает немного быстрее, чем SHA-256 в 64-разрядных системах.

Кроме того, существует ли лучший подход для решения этой проблемы ?

Спасибо

Answer 1

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

Как уже упоминалось, вероятность коллизий SHA256 бесконечно мала, поэтому вы могли бы делать это с низким риском.

Поскольку функция ha sh не гарантирует (и не может гарантировать) абсолютного отсутствия столкновений, возможны альтернативы.

Вопрос: Можете ли вы хранить метка времени транзакции? - если это так, вы можете связать временную метку с постфиксом цифра c, чтобы получить внутренний идентификатор (отличный от идентификатора транзакции, который у вас был изначально). Это намного лучше, чем ха sh, с точки зрения уникальности. Это приходит с преимуществом того, чтобы быть чрезвычайно быстрым. Но вам нужно будет сохранить этот постфикс с исходным объектом, чтобы иметь возможность воспроизвести этот внутренний идентификатор.

По сути, вам нужна функция для определения (определенно) уникального ключа из объекта транзакции на основе атрибуты, которые вам разрешено хранить. Предполагая, что вам разрешено хранить временную метку и постфикс числового значения c, возможен следующий пример:

Если вы получаете коллизии временных отметок, вы увеличиваете постфикс числового значения c, поэтому вы ' d get:

2020-02-18-14-26-15-420-0 (postfic here is -0)
2020-02-18-14-26-15-420-1 (postfic here is -1)
2020-02-18-14-26-15-420-2 (postfic here is -2)
2020-02-18-14-26-15-423-0 (postfic here is -2)

Здесь некоторые транзакции поступили одновременно. Однако они все еще уникально идентифицируемы.