Антипаттерн: UUID как PK без учёта последствий
Выглядит красиво: глобально уникальный идентификатор, можно генерировать на клиенте, удобно в распределённых системах. Но...
Проблемы:
– Большой размер (16 байт vs 4 байта у INT)
– Плохая локальность: индекс B-Tree фрагментируется
– Медленнее вставки, особенно при высоких нагрузках
– Нагружает сеть, если часто передаёшь PK
В PostgreSQL это особенно заметно: индекс на UUID-ключе может вести себя гораздо хуже, чем на BIGSERIAL.
Как делать правильно:
1. Если всё в одной БД: используй BIGINT или BIGSERIAL
2. Если нужен UUID:
– генерируй UUID v7 (появился в 2022, содержит компонент времени → лучше упорядочен)
– либо UUID v1 (временной, но с оговорками по безопасности)
– или комбинируй автоинкремент + случайный суффикс
3. Храни UUID как UUID, а не как VARCHAR(36) — это экономит место и CPU
UUID — мощный инструмент, но не серебряная пуля. Прежде чем делать его PRIMARY KEY, подумай: что ты реально выигрываешь?
Выглядит красиво: глобально уникальный идентификатор, можно генерировать на клиенте, удобно в распределённых системах. Но...
Проблемы:
– Большой размер (16 байт vs 4 байта у INT)
– Плохая локальность: индекс B-Tree фрагментируется
– Медленнее вставки, особенно при высоких нагрузках
– Нагружает сеть, если часто передаёшь PK
В PostgreSQL это особенно заметно: индекс на UUID-ключе может вести себя гораздо хуже, чем на BIGSERIAL.
Как делать правильно:
1. Если всё в одной БД: используй BIGINT или BIGSERIAL
2. Если нужен UUID:
– генерируй UUID v7 (появился в 2022, содержит компонент времени → лучше упорядочен)
– либо UUID v1 (временной, но с оговорками по безопасности)
– или комбинируй автоинкремент + случайный суффикс
3. Храни UUID как UUID, а не как VARCHAR(36) — это экономит место и CPU
UUID — мощный инструмент, но не серебряная пуля. Прежде чем делать его PRIMARY KEY, подумай: что ты реально выигрываешь?
