Php самый быстрый хэш

Обновлено: 05.07.2024

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

Я предполагаю, что MD5 довольно медленно обрабатывает более 100 000 запросов, поэтому я хотел бы знать, какой будет лучший способ для хеширования фраз, возможно, развертывание моей собственной хэш-функции или использование hash('md4', '. ' в конечном итоге будет быстрее?

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

NullUserException: Вы правы, я попробую их со фразами произвольной длины. Просто хотел понять, что будет нормой, если таковая будет иметь дело с такими вещами. Вы уверены, что функция хеширования является узким местом всего приложения? Я сомневаюсь в этом Это очень хороший вопрос, и комментарии, подразумевающие, что это не так, или не важны, и / или должны быть очевидными и / или интуитивными, разочаровывают и расстраивают. (И тоже не совсем неожиданно.)

Но вы должны знать, что CRC32 будет иметь больше коллизий, чем MD5 или даже хэши SHA-1, просто из-за уменьшенной длины (32 бита по сравнению со 128 битами и 160 битами соответственно). Но если вы просто хотите проверить, не повреждена ли сохраненная строка, вам подойдет CRC32.

Ничего себе, только требуемый тип данных - это целое число без знака, это будет ЗНАЧИТЕЛЬНО быстрее, чем другое хеширование. @ Джон: или нет. CRC32 оказывается медленнее, чем MD4, и не намного быстрее, чем MD5, на процессорах ARM. Кроме того, CRC32 использует 32-разрядный целочисленный тип без знака, что является именно тем, что нужно MD5 .

И код, используемый для генерации это:

Ах, спасибо за это понимание на самом деле, просто укрепляет мое использование CRC32, будучи самым быстрым. Спасибо за ваш код. Я немного улучшил это. Я не думаю, что мы должны сравнивать такие функции, как md5 (), которые обрабатывают всю строку, и циклы, которые делают побайтно, как вы сделали с помощью xor. В PHP эти циклы очень медленные и даже медленнее, чем сам md5. Мы должны сравнить одну шляпу с другой, все реализованные как функции. Просто небольшое замечание - я попробовал это с гораздо более длинной строкой (

5000 символов), а CRC32 был медленнее, чем MD5 и SHA1 на моей машине (i7-6650U, 16 ГБ). CRC32 - 1,7 с, MD5 - 1,4 с, SHA1 - 1,5 с. Всегда проверяйте себя.

@Quamis тест хорош, но может вводить в заблуждение - как заметил @samTolton, результаты отличаются и md5 быстрее. Лучшим тестом будет рандомизировать содержимое и длину строк. Таким образом, мы получаем лучшее представление о реальной производительности в реальном мире. Это также позволит избежать кеширования. Посмотрите: производительность контрольной суммы хэширования php

Ранжированный список, в котором каждый цикл разделяет одно и то же для шифрования, как и все остальные.

В конце есть минимальная ошибка. strlen($characters) должно быть strlen($characters) - 1 :)

На сайте xxhash есть сравнение скорости. Скопируйте его здесь:

Похоже, что xxHash является самым быстрым, в то время как многие другие используют более старые хеши, такие как CRC32, MD5 и SHA.

Обратите внимание, что это порядок 32-битной компиляции. На 64-битной компиляции порядок производительности, вероятно, очень отличается. Некоторые из хэшей основаны на 64-битных умножениях и выборках.

Обновление 2019 года: этот ответ является наиболее актуальным. Библиотеки для поддержки ропота в основном доступны для всех языков.

В настоящее время рекомендуется использовать семейство Murmur Hash (см., В частности, варианты murmur2 или murmur3 ).

Хэши Murmur были разработаны для быстрого хеширования с минимальными коллизиями (намного быстрее, чем CRC, MDx и SHAx). Он идеально подходит для поиска дубликатов и очень подходит для индексов HashTable.

Фактически он используется многими современными базами данных (Redis, ElastisSearch, Cassandra) для вычисления всевозможных хэшей для различных целей. Этот конкретный алгоритм стал основным источником многих улучшений производительности в текущем десятилетии.

Это также используется в реализациях Bloom Filters . Вы должны знать, что если вы ищете «быстрые хэши», вы, вероятно, сталкиваетесь с типичной проблемой, которая решается фильтрами Блума. ;-)

Примечание : шум - это хэш общего назначения, означающий НЕ криптографический. Это не мешает найти исходный «текст», сгенерировавший хеш. НЕ подходит для хэширования паролей.

Существует открытый запрос здесь , чтобы добавить murmurhash на PHP, который вы можете проголосовать.

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

На гораздо меньших архитектурах, где скорость хеширования может стать несколько уместной, вы можете использовать MD4. MD4 подходит для не криптографических целей (и для криптографических целей вы не должны использовать MD5 в любом случае). Сообщалось, что MD4 даже быстрее, чем CRC32 на платформах на основе ARM.

Там есть точка для рассмотрения. MD5 занимает 128 бит вместо 32. Это означает, что хранилище базы данных занимает в 4 раза больше места и, следовательно, в 4 раза медленнее ищет сравнение хэшей (я думаю ). Что меня беспокоит (для моего использования), так это то, как быстро будет выполняться запрос к базе данных позже, когда она заполнена хешами. Если вы не используете достаточно широкий вывод, вы получите случайные коллизии, которые будут плохими, поскольку цель состоит в том, чтобы запросить базу данных, чтобы узнать, известна ли данная «фраза»; столкновения здесь превращаются в ложные срабатывания. С 32 битами вы начнете видеть столкновения, как только у вас будет 60000 или около того фраз. Это верно для всех хеш-функций, криптографических или нет. При этом вы всегда можете взять выходные данные хеш-функции и обрезать их до любой длины, которую считаете нужной, в рамках ограничений, описанных выше. @ThomasPornin Если мы пойдем по усеченному пути, разве он не столкнется с проблемой столкновения, я имею в виду, что единственная причина, по которой md5 не может получить легкое столкновение, это лишнее количество символов, которые он имеет по сравнению с CRC32, верно?

Предостережение

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

Если вы хотите ослабить требование использования хэш-функции , читайте дальше .

Оригинальный ответ

Я предлагаю urlencode () или base64_encode () по этим причинам:

Вам не нужна криптография
Вы хотите скорость
Вы хотите, чтобы способ идентифицировать уникальные строки при очистке "неправильно сформированных" строк

И код, используемый для генерации это:

Ранжированный список, в котором каждый цикл разделяет одно и то же для шифрования, как и все остальные.

На сайте xxhash есть сравнение скорости. Скопируйте его здесь:

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

На гораздо меньших архитектурах, где скорость хеширования может становится несколько уместной, вы можете использовать MD4. MD4 подходит для не криптографических целей (и для криптографических целей, вы все равно не должны использовать MD5). Сообщалось, что MD4 даже быстрее, чем CRC32 на платформах на основе ARM.

В настоящее время рекомендуется использовать семейство Murmur Hash (см. Конкретно murmur2 или murmur3 варианты).

Он также используется в реализациях Bloom Filters . Вы должны знать, что если вы ищете "быстрые хэши", вы, вероятно, сталкиваетесь с типичной проблемой, которая решается фильтрами Блума. ;-)

Примечание : шум - это хэш общего назначения, означающий НЕ криптографический. Это не мешает найти исходный "текст", сгенерировавший хеш. НЕ подходит для хэширования паролей.

Я предлагаю urlencode () или base64_encode () по этим причинам:

Вам не нужна криптография
Вы хотите скорость
Вы хотите, чтобы способ идентификации уникальных строк при очистке "искаженных" строк

Шаг первый: Установите libsodium (или убедитесь, что вы используете PHP 7.2+)

Шаг второй: используйте одно из следующего:

sodium_crypto_generichash() , которая BLAKE2b , хеш-функция более безопасна, чем MD5, но быстрее, чем SHA256. (Ссылка имеет ориентиры и т.д.)
sodium_crypto_shorthash() , который SipHash-2-4 , который подходит для хеш-таблиц, но не следует полагаться на сопротивление коллизиям.

_shorthash примерно в 3 раза быстрее, чем _generichash , но вам нужен ключ, и у вас небольшой, но реалистичный риск коллизий. С _generichash вам, вероятно, не нужно беспокоиться о коллизиях, и вам не нужно использовать ключ (но может понадобиться в любом случае).

Adler32 работает лучше всего на моей машине. И md5() оказался быстрее, чем crc32() .

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

Я предполагаю, что MD5 довольно медленно обрабатывает более 100 000 запросов, поэтому я хотел знать, какой метод будет лучшим для хеширования фраз, возможно, развертывание моей собственной хеш-функции или использование hash('md4', '. ' в конечном итоге будет быстрее?

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

Но вы должны знать, что CRC32 будет иметь больше коллизий, чем хэши MD5 или даже SHA-1, просто из-за уменьшенной длины (32 бита по сравнению со 128 битами, соответственно, 160 бит). Но если вы просто хотите проверить, не повреждена ли сохраненная строка, вам подойдет CRC32.

И код, используемый для его создания:

Ранжированный список, в котором каждый цикл использует то же самое, что и все остальные.

Обновление 2019: этот ответ самый последний. Библиотеки для поддержки ропота в основном доступны для всех языков.

В настоящее время рекомендуется использовать семейство Murmur Hash Family (см., в частности, варианты murmur2 или murmur3 ).

Хеши Murmur были разработаны для быстрого хеширования с минимальными коллизиями (намного быстрее, чем CRC, MDx и SHAx). Он идеально подходит для поиска дубликатов и очень подходит для индексов HashTable.

Фактически, он используется многими современными базами данных (Redis, ElastisSearch, Cassandra) для вычисления всевозможных хэшей для различных целей. Этот конкретный алгоритм стал основным источником многих улучшений производительности в текущем десятилетии.

Он также используется в реализациях фильтров Bloom. Вы должны знать, что если вы ищете «быстрые хэши», вы, вероятно, столкнетесь с типичной проблемой, которую решают фильтры Блума. ;-)

Примечание : шепот - это хеш общего назначения, то есть НЕ криптографический. Это не мешает найти исходный «текст», сгенерировавший хеш. НЕ подходит для хеширования паролей.

Предупреждение

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

Если вы хотите ослабить требование использования хеш-функции , читайте дальше .

Исходный ответ

Я предлагаю urlencode () или base64_encode () по следующим причинам:

Вам не нужна криптография
Вы хотите скорости
Вам нужен способ идентифицировать уникальные строки при очистке `` искаженных '' строк

Adler32 лучше всего работает на моей машине. И md5() оказался быстрее, чем crc32() .

Шаг 1. Установите libsodium (или сделайте конечно, вы используете PHP 7.2+)

Шаг второй: используйте одно из следующих:

sodium_crypto_generichash() , то есть BLAKE2b, хеш-функция и др. безопаснее, чем MD5, но быстрее, чем SHA256. (По ссылке есть бенчмарки и тд)
sodium_crypto_shorthash() , то есть SipHash-2-4, который подходит для хеш-таблиц, но не должен полагался на сопротивление столкновению.

_shorthash примерно в 3 раза быстрее, чем _generichash , но вам нужен ключ, и у вас есть небольшой, но реалистичный риск столкновения. С _generichash вам, вероятно, не нужно беспокоиться о коллизиях, и вам не нужно использовать ключ (но вы все равно можете захотеть это сделать).

CRC32 быстрее, но менее безопасен, чем MD5 и SHA1. Между MD5 и SHA1 нет такой большой разницы в скорости.

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

На гораздо меньших архитектурах, где скорость хеширования может стать в некоторой степени актуальной, вы можете использовать MD4. MD4 подходит для некриптографических целей (и для криптографических целей вы в любом случае не должны использовать MD5). Сообщалось, что MD4 даже быстрее, чем CRC32 на платформах на базе ARM.

Реализация md5 внутри хеша немного быстрее, чем md5 (). Так что это может быть вариант или что-то еще, попробуйте:

Мне нужна очень быстрая функция хеширования строк, которая хорошо подходит для веб-приложений, написанных на PHP.

Проблема, которую я пытаюсь преодолеть, заключается в назначении идентификаторов разрешениям в системе контроля доступа. Я думаю об использовании хэшированных строк для представления идентификаторов разрешений. Таким образом, я смогу проверить разрешения следующим образом:

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

Решение

Первый хотя был почему он не использует простой md5 функционировать?.

Пытаюсь написать хеш самостоятельно

Один из наиболее часто упоминаемая функция простой хеш Функция Бернштейна также упоминается как Times 33 with Addition , Используется в php Зендом сделать хеши для ключей ассоциативного массива . В php это может быть реализовано следующим образом:

Проблема в том, что когда это реализовано таким образом, это довольно медленно. Тесты показывают, что это

В 3 раза медленнее, чем md5 , Таким образом, мы должны найти самый быстрый внутренняя реализация hash функция .

Поиск лучшего внутреннего хэша

Просто возьмите все алгоритмы и измерьте время, чтобы хэшировать миллион строк.

Мои результаты были:

Что следует выбрать?

Вы можете взять любую из 8 функций из приведенных выше: $hash = hash('crc32', $string); , На самом деле широко используется md5 Функция всего в 1,7 раза медленнее, чем у лидеров.

бонус

Есть и другие функции, такие как SuperFastHash , которые не реализованы в php код, но они в 4 раза быстрее, чем crc32 ,

Другие решения

использование xxHash . Используется PrestoDB также. Реализация PHP на GitHub

Время обработки хеш-функции в большинстве случаев можно считать незначительным.
Если вам нужен небольшой хеш (8 символов), вы можете просто использовать функцию crc32.

Читайте также: