Задумывались ли вы когда-нибудь об эффективности UUIDv4?
Часто при выборе уникального ключа для записи разработчики предпочитают UUIDv4.
Из преимуществ:
1. Глобальная уникальность ID
2. Нет необходимости хранить состояние
3. Быстрая генерация уникального ID
Это важные свойства, если мы работаем с уникальными объектами. Но в один момент эта конструкция ломается.
UUIDs используются как primary key в таблицах, а значит автоматически индексируются.
И вот тут начинаются проблемы. UUIDv4 - это случайные 128 бит. Случайность означает отсутствие локальности данных: новые записи попадают в произвольные места индекса, а не дописываются последовательно в конец, как это происходит с автоинкрементным bigint. Из-за этого при вставке приходится постоянно читать диск.
Как тогда быть, если хочется использовать uuid? Ответ UUIDv7.
UUIDv7 устроен просто: первые 48 бит - это временная метка в миллисекундах, остальная часть также случайна. Из-за этого значения генерируются приблизительно по возрастанию во времени. Это даёт локальность записи «бесплатно»: новые строки физически ложатся рядом друг с другом в индексе. При этом все три исходных преимущества UUID сохраняются.
Также нашел интересную статью, где один разработчик сделал бенчмарк в сравнении разных primary keys на вставку в базу данных где производительность UUIDv7 на 30% выше чем у UUIDv4
https://ardentperf.com/2024/02/03/uuid-benchmark-war/
Часто при выборе уникального ключа для записи разработчики предпочитают UUIDv4.
Из преимуществ:
1. Глобальная уникальность ID
2. Нет необходимости хранить состояние
3. Быстрая генерация уникального ID
Это важные свойства, если мы работаем с уникальными объектами. Но в один момент эта конструкция ломается.
UUIDs используются как primary key в таблицах, а значит автоматически индексируются.
И вот тут начинаются проблемы. UUIDv4 - это случайные 128 бит. Случайность означает отсутствие локальности данных: новые записи попадают в произвольные места индекса, а не дописываются последовательно в конец, как это происходит с автоинкрементным bigint. Из-за этого при вставке приходится постоянно читать диск.
Как тогда быть, если хочется использовать uuid? Ответ UUIDv7.
UUIDv7 устроен просто: первые 48 бит - это временная метка в миллисекундах, остальная часть также случайна. Из-за этого значения генерируются приблизительно по возрастанию во времени. Это даёт локальность записи «бесплатно»: новые строки физически ложатся рядом друг с другом в индексе. При этом все три исходных преимущества UUID сохраняются.
Также нашел интересную статью, где один разработчик сделал бенчмарк в сравнении разных primary keys на вставку в базу данных где производительность UUIDv7 на 30% выше чем у UUIDv4
https://ardentperf.com/2024/02/03/uuid-benchmark-war/