Обработка случайного хранения идентификаторов - PullRequest
Новая
       43

Обработка случайного хранения идентификаторов

0 голосов
/ 07 сентября 2018

Допустим, у нас есть приложение, такое как YouTube, и мы хотим назначить идентификаторы для видео случайным образом, чтобы пользователи не могли перебирать видео. Например. https://www.youtube.com/watch?v=o4f5G9q_9O4

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

Как хранить эти идентификаторы? Будут ли идентификаторы не являться последовательной индексацией вреда?

PS: я использую MySQL для хранения этих данных

Ответы [ 3 ]

0 голосов
/ 07 сентября 2018

Случайная строка не должна быть первичным ключом. Вы можете иметь первичный ключ AUTO_INCREMENT, который используется в качестве внешнего ключа в других таблицах. Кроме того, у вас может быть столбец unique_id, который содержит случайную строку, которую вы выставляете в URL. Это может иметь уникальный индекс, который сделает поиск эффективным.

Это аналог пользовательской таблицы, где у вас может быть последовательный user_id, а также уникальный столбец user_name, который используется для входа в систему, отправки сообщений, отображения в сообщениях и т. Д.

Для столбца unique_id в идеале вы хотели бы использовать хеш-индекс, а не индекс B-дерева. К сожалению, в MySQL это доступно только в движке хранения MEMORY, а не InnoDB или MyISAM.

0 голосов
/ 20 сентября 2018

Пока что речь идет о том, насколько плохи UUID. Хотя я согласен, я не думаю, что это применимо здесь.

Ваша ситуация такова: учитывая один случайный идентификатор, извлеките одну запись, к которой она относится. Правильный? Вы не беспокоитесь о получении нескольких «последовательных» записей.

Генерация случайного ключа: UUID довольно громоздки; Вы могли бы хотеть что-то более короткое. Возьмите MD5() некоторой уникальной строки - возможно, идентификатор AUTO_INCREMENT, связанный с секретным семенем. Затем конвертируйте в base64, чтобы он не был слишком длинным. (Предостережение: обратите внимание на специальные символы, которые могут испортить URL).

Извлечение: использование этого ключа в качестве ключа PRIMARY KEY или UNIQUE будет стоить чего-то случайным образом. Но я подозреваю, что это будет лишь небольшой процент от накладных расходов в вашем приложении.

0 голосов
/ 07 сентября 2018
  1. Составьте случайную строку.
  2. Попытка вставить в столбец с ограничением UNIQUE.
  3. Если он вставлен, поздравляю, ваш идентификатор.
  4. Если дубликат не удался, вернитесь к шагу 1.

Если у вас достаточно длинная строка и достаточно надежный генератор случайных чисел, то столкновения должны быть редкими. Если вы используете все буквы (заглавные / строчные) и цифры, то вы можете получить ~ 20 жетонов символов, которые вряд ли столкнутся.

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

...