TGViewer
🚀🐳 Летит Кит: SRE и не только 🚀🐳 Летит Кит: SRE и не только @letitkit · 202 subscribers
Post #177 106

Forwarded from Мишка на сервере (Mikhail Savin)

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
  • 👍 4
More from @letitkit
  1. Sep 24, 2026Раздача слонов на Claude AI Привет, киты 🐋! 1. Получить 100$ или $250 бонусных на Сlaude…
  2. Sep 22, 2026Споры про искусственный интеллект в SRE изменились. Мы уже не гадаем, заменит ли агент деж…
  3. Sep 15, 2026Toil в работе SRE. Измерять, или "мы и так знаем что работы дофига“? Привет, киты 🐳. Пора…
  4. Sep 8, 2026О важности отдыха Привет, киты! 🐳 Оказалось я забыл как отдыхать. Перед отпуском делал за…
  5. Sep 3, 2026Важное про безопасность с чужим кодом - еще раз. Привет, киты 🐳! TL; DR; на чужих AI-скил…
  6. Aug 26, 2026Реклама конференции в которой я выступаю. Если вы думали, пойти или нет, а хотели пойти с…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →