М
Мишка на сервере
@jtprogru_channel1.2K подп.
1.1Kпросмотров
92.4%от подписчиков
27 марта 2026 г.
questionScore: 1.2K
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
1.1K
просмотров
2328
символов
Нет
эмодзи
Нет
медиа

Другие посты @jtprogru_channel

Все посты канала →
UUID v4 vs UUID v7 — почему это важно для SRE? Привет, %user — @jtprogru_channel | PostSniper