ПЕРВИЧНЫЕ КЛЮЧИ MySQL: UUID / GUID vs BIGINT (timestamp + random)
tl; dr: Назначает идентификаторы строк {unixtimestamp} {randomdigits} (например, 1308022796123456) как BIGINT - хорошая идея, если я не хочу иметь дело с UUID ?
Просто интересно, есть ли у кого-нибудь представление о производительности или других технических соображениях / ограничениях в отношении ID / PRIMARY KEY, назначенных для записей базы данных на нескольких серверах.
Мое приложение PHP + MySQL работает на нескольких серверах, и данные необходимо объединять. Так что я перерос стандартный метод определения строк с помощью целочисленных последовательностей / auto_increment.
Мои исследования решения привели меня к концепции использования UUID / GUID. Однако необходимость изменить мой код для преобразования строк UUID в двоичные значения в MySQL кажется небольшой болью / работой. Я не хочу хранить UUID как VARCHAR по соображениям хранения и производительности.
Еще одно возможное раздражение, связанное с UUID, хранящимся в двоичном столбце, заключается в том, что идентификаторы строк не очевидны при просмотре данных в PhpMyAdmin - хотя я могу ошибаться в этом, - но прямые числа в целом кажутся намного проще и являются универсальный для любого типа системы баз данных без необходимости преобразования.
В качестве компромисса я пришел к идее сделать столбцы идентификаторов BIGINT и назначать идентификаторы с использованием текущей временной метки unix, за которой следует 6 случайных цифр. Итак, предположим, что мое случайное число оказалось 123456, мой сгенерированный сегодня идентификатор выглядел бы как: 1308022796123456
Меня устраивает вероятность конфликта один из 10 миллионов для строк, созданных за одну секунду. Я не занимаюсь массовым созданием строк быстро.
Одна проблема, о которой я читал со случайно сгенерированными UUID, заключается в том, что они плохи для индексов, поскольку значения не являются последовательными (они разбросаны повсюду). Функция UUID () в MySQL решает эту проблему, генерируя первую часть UUID из текущей метки времени. Поэтому я скопировал идею наличия временной метки unix в начале моего BIGINT. Мои индексы будут медленными?
Плюсы моей идеи BIGINT:
- Дает мне преимущества UUID с несколькими серверами / слиянием
- Требует очень небольшого изменения в коде моего приложения (все уже запрограммировано на обработку целых чисел для идентификаторов)
- Половина хранение UUID (8 байт против 16 байт)
Минусы:
- ??? - Пожалуйста, дайте мне знать, если вы что-нибудь придумаете.
Несколько дополнительных вопросов, связанных с этим:
Должен ли я использовать больше или меньше 6 случайных цифр в конце? Будет ли это иметь значение для индексации производительности?
Является ли один из этих методов «случайным»?: Заставить PHP сгенерировать 6 цифр и объединить их вместе -VS- заставить PHP сгенерировать число в диапазоне 1 - 999999, а затем заполнить нулями, чтобы гарантировать 6 цифр.
Спасибо за любые советы. Извините за стену с текстом.