Почему сайты используют случайные буквенно-цифровые идентификаторы, а не идентификаторы базы данных для идентификации контента?
Почему сайты, такие как YouTube, Imgur и большинство других, используют случайные символы в качестве идентификаторов контента, а не просто последовательные числа, как те, которые создаются с помощью автоматического увеличения в MySQL?
Чтобы объяснить, что я имею в виду:
В URL: https://www.youtube.com/watch?v=QMlXuT7gd1I
QMlXuT7gd1I в конце указывает конкретное видео на этой странице, но я предполагаю, что у видео также есть уникальный числовой идентификатор в базе данных. Почему они создают и используют эту буквенно-цифровую строку, а не просто используют идентификатор базы данных видео?
Я создаю сайт, который идентифицирует контент в URL, как указано выше, но в настоящее время я использую только идентификатор БД. Я рассматриваю возможность перехода на случайные строки, потому что все основные сайты делают это, но я хотел бы знать, почему это делается, прежде чем я это реализую.
Спасибо!
Решение
Некоторые сайты делают это из-за шардинга.
Когда у вас есть только один процесс (один сервер), можно создать идентификатор с автоматическим приращением без дубликатов идентификаторов, но если у вас есть несколько серверов (с несколькими процессами), пишущих контент, например YouTube, использование автоинкремента невозможно Я больше. Затраты на синхронизацию, чтобы избежать дублирования, были бы огромными.
Например, если вы читаете документация к mongodb Вы можете увидеть эту структуру для идентификатора:
4-байтовое значение, представляющее секунды с начала эпохи Unix,
3-байтовый идентификатор машины,
двухбайтовый идентификатор процесса и
3-байтовый счетчик, начиная со случайного значения.
В конце всего 12 байт. Дело в том, что когда вы представляете в шестнадцатеричном формате, это выглядит как 24 байта, но это только когда вы показываете это.
Еще одним преимуществом этой системы является то, что временная метка включена в идентификатор, так что вы можете отделить идентификатор, чтобы получить временную метку.
Другие решения
Во-первых, это не случайная строка, это базовое вычисление, которое зависит от идентификатора. Они идут по этому пути, потому что буквенно-цифровой имеет большую базу
Что-то вроде 99999999 может быть 1NJCHR
Взглянуть Вот, и играть с основами, и узнать больше об этом.
Вы увидите, что это намного короче. Это единственная причина, по которой я могу представить, что кто-то пойдет по этому пути, и это имеет смысл, если у вас есть идентификаторы типа 54389634589347534985348957863457438959734
Как сам а также Cameron В комментариях / ответах есть шансы (особенно для youtube), что есть дополнительные параметры безопасности, такие как время и длина, которые каким-то образом вычисляются в нем, поэтому вы не можете угадать идентификатор.
В дополнение к ответу Кристиана, приведенному выше, использование базовых вычислений, хэшированного значения или другого нечислового идентификатора имеет преимущество в скрытии размера вашей базы данных от конкурентов.
Даже если вы оставались с числовым значением и установили для auto_increment значение 50 000, увеличение на 50 и т. Д., Можно сделать обоснованные предположения о размере и росте БД. Нечисловые параметры не исключают эту возможность, но в некоторой степени сдерживают ее.
есть большие шансы для злонамеренного ввода со стороны конечных пользователей, и, не используя идентификаторы, пользователи не могут угадать идентификаторы и, следовательно, не могут угадать, насколько большой дБ. Однако ответы других на базовый расчет хорошо объясняют.