Не все правила такие уж железные, но львиная доля хорошо написана и всегда актуальна. Ну может кроме DWH, но там у нас свои миры конечно

25 железных правил проектирования баз данных в PostgreSQL / Хабр https://share.google/igQdwSo9BN1tilCbP

UUID v4 vs UUID v7 — почему это важно для SRE?

Привет, %username%! Сегодня поговорим о вещи, которая на первый взгляд кажется мелкой деталью — выборе версии UUID. Но если ты работаешь с высоконагруженными системами, эта "мелочь" влияет на производительность БД, I/O и даже на читаемость логов во время инцидентов.

Что под капотом?

UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.

UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.

Почему это критично для нас с тобой?

Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:

- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.

SRE-профит от перехода на v7

- ORDER BY created_at становится менее актуальным — можно сортировать прямо по PK;
- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.

Когда v4 всё ещё ок?

- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.

Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку uuidv7() из коробки.

Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?

#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering