UUIDv4 - это 122 бита чистого рандома, отличный тип для уникального идентификатора. Но, обычно мы работаем с этим типом в базах, часто поле с этим типом помечается как primary key, и минус его в том, что он, при вставке в базу в индексируемом поле, дает хаотичный порядок.
Простыми словами: при вставке в базу UUIDv4 попадает в случайное место индекса, из-за чего таблица постоянно разрывается на куски, индекс разрастается и вставки начинают работать медленее.
Посмотрим на примере с b-tree индексами.
Как работает b-tree:
- индекс - это дерево, в котором данные упорядочены по ключу
- листовые страницы хранят отсортированные значения PK
- новые ключи вставляются так, чтобы порядок сохранялся
Что происходит, когда мы вставляем в индекс UUIDv4:
- новая вставка попадает в происзвольное место середины b-tree
- это чаще провоцирует page split - деление страниц дерева пополам и перенос записей в новую страницу
- это дорогие операции, они увеличивают глубину дерева
Получается, что b-tree, который должен быть плотным и последовательным, превращается в хаотичный набор частично заполненных страниц из-за случайного порядка ключей.
Как это решить? Использовать UUIDv7.
Во-первых, этот тип хранит в себе не только рандомный ключ, но и время:
- первые 48 бит - timestamp
- остальные - рандомный ключ + секвенс, чтобы избежать коллизий
Во-вторых, все значения монотонно возрастают из-за включенного в ключ timestamp.
Что умеет v7, чего не умеет v4:
- когда мы сортируем по uuid - фактически, мы сортируем по времени
- когда мы вставляем в индекс - новые записи всегда будут добавляться в конец b-tree дерева, а не в рандомное место
Получается, что используя UUIDv7 мы автоматически оптимизируем вставку в индекс уменьшая оверхед уменьшением количества page split.
Вывод: используйте UUIDv7, он лучше, стабильней, и можно писать
order by id desc и получать очень быструю сортировку по времени 😎dev notes | golang digest