Зачем в сервисах типа github или jsfiddle у записи генерируется не порядковое число, а хеш?

Question

[accountnujen]

При создании gist.github генерируется вот такая ссылка

https://gist.github.com/akhilanandbv003/fd4f3898bb7b9c36f7b9a8c198e01548

При создании jsfiddle такая:
https://jsfiddle.net/vu9tsmd2/

В первом случае виден md5. Во втором возможно часть хеша. Либо что-то другое короткое.

Вот хотелось бы понять, с какой целью делаются такие ухищрения? Почему бы просто не выдавать id записям, как условно здесь: vk.com/id1? От чего можно защититься таким образом, если в любом случае все эти данные хранятся в общем доступе, а в случае с github, если gist будет секретным, то знание его md5 ссылки никаким образом не сможет помочь в его открытии.

Для меня это выглядит, как какая-то лишняя энергозатрата. В начале захешировать, затем искать по хешу... Она мизерная, разумеется, но зачем? Плюс коллизии...А учитывая такой короткий размер в jsfiddle - они необратимы. То есть теперь придётся перед записью ещё проверять БД, а нет ли ещё записей с таким же именем и здесь энергозатраты по более будут, чем просто с хешированием.

Comments

[Алексей Дубровин]

"vu9tsmd2" * 4 = "vu9tsmd2vu9tsmd2vu9tsmd2vu9tsmd2"
"fd4f3898bb7b9c36f7b9a8c198e01548" ~ "vu9tsmd2vu9tsmd2vu9tsmd2vu9tsmd2"

Answer 1

[Михаил]

Это зависит от того как организована система хранения. Может получиться так, что искать по хэшу она будет быстрее чем по обычному числу т.к., например, может использоваться quad tree или octree. Если использовать число, то старшие биты будут плюс-минус одинаковы, что приведет к тому что данные скопятся в одной из веток дерева, а другие будут пустыми. А если дерево еще и распределенное - это будет означать что данные неравномерно распределены по нодам. Хэш такую проблему решает сразу. Для гита вероятность коллизий хэша пренебрежимо мала, практически нулевая.

В случае гитхаба, вероятно, данные хранятся в гит-репозитории. Поэтому хэш коммита в ссылке - естественное и логичное решение. Насчет фиддла сказать не могу - но в принципе тоже, скорее всего, что-то аналогичное, только закодировано не в 16-ричную систему, а в 32-ричную (5 * 8 = 40 бит)

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

Comments

[accountnujen]

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

хеш коммита - это риск коллизии. Даже с солью в виде времени.

Спасибо за ответ

[Михаил]

accountnujen, как я уже написал, шанс коллизии по хэшу в случае гита ничтожно мал.

[accountnujen]

Михаил, https://habr.com/ru/post/113127/

[Михаил]

accountnujen, ну и? MD5, обратите внимание. А этот алгоритм хэширования уже давно считается далеко не лучшим, в том числе из-за вот такого. Гит использует хэш SHA-1 (устаревший) или SHA-256 (новый)

[accountnujen]

не подумал, что там не md5. Прошу прощения.

Подскажите, а данных в случае использования php pdo может быть только такая?

$pdo->prepare("SELECT data FROM db_main WHERE hash = ?");

Или можно как-нибудь оптимизировать поиск по хешу?

Я погуглил quad tree и octree, но там ничего с php pdo не нашлось...

[Михаил]

accountnujen, создайте в БД индекс по полю hash - вам этого на миллион записей в таблице хватит. Когда будет больше - тогда и придет время о чем-то думать.

Answer 2

[Армянское Радио]

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

Comments

[accountnujen]

забавно, что в случае парсингом jsfiddle - метрики будут иметь бессмысленное значение, а вот в vk.com как раз всё наоборот. Но тщеславие Павла - получить id1 - сильнее, чем неизбежный риск парсинга vk))) Если бы был md5 - хрен бы мы получили эти базы пользователей)))