UUIDv7 против bigint в primary key. Postgres 18 завёз uuidv7() из коробки и спор у нас вспыхнул заново

[Omegaiv]

Пилим новый сервис, постгрес 18.1. Тимлид требует везде UUID v7 как PK, благо теперь uuidv7() прямо в ядре и расширения не нужны. Его аргументы: id генерится на клиенте до инсерта, не палим объёмы бизнеса через последовательные номера, при шардинге не надо ничего перепридумывать.

Я за bigint identity. 8 байт против 16, причём раздувается не только PK, а все FK и все индексы по ним. На прошлой работе видел, как btree на uuid v4 превращает вставку в random IO и база захлёбывается на ровном месте. v7 за счёт таймстампа в префиксе вроде это лечит, но осадочек остался.

Кто гонял v7 под реальной нагрузкой, а не в бенче на ноуте? Интересует вставка от 5к rps и таблицы от 100 млн строк. Вариант bigint внутри плюс публичный uuid наружу знаю, но это два айдишника на сущность и вечная путаница, в логах один, в тикете другой.

[susanne]

гоняли. сначала на 17-м с расширением pg_uuidv7, с осени на 18-м уже родной uuidv7(). таблица событий 140 млн строк, вставка в пике около 8к rps. индекс по PK: на bigint было 2.6 гига, на uuid стало 4.1. вставка просела процентов на 7, а не на 40-50, как было бы с v4. WAL подрос примерно на 15 процентов. короче жить можно, если 16 байт на ключ не душат тебя религиозно

[dennisdd]

не палим объёмы бизнеса это конечно аргумент века. для этого достаточно отдельного public_id наружу, а вы ради него собрались все джойны в системе гонять по 16-байтовым ключам. тимлид молодец, продал красивое, считать будете потом

[jbentley]

ULID кто-нибудь ещё помнит? года три назад все носились, теперь тишина. v7 его фактически и съел

[ansible777]

Раз пошла такая пьянка, душное уточнение. Это RFC 9562, после 48 бит таймстампа там 74 бита рандома, про коллизии можно не переживать вообще. А вот монотонность внутри одной миллисекунды по умолчанию не гарантируется, так что если у вас где-то сортировка по id вместо created_at, словите сюрпризы.

[svelte88]

Переводили заказы на v7 в одном маркетплейсе, рф, называть не буду. Главный профит оказался вообще не перф. id заказа генерится в мобильном клиенте ДО запроса, и ретраи при отвале сети стали идемпотентными из коробки, дубли заказов умерли как класс. А минус прилетел внезапно от саппорта: продиктовать клиенту по телефону 019808a3-7b2e-7cc3-9f1b и так далее невозможно физически, пришлось прикручивать короткий номер заказа. То есть второй айдишник всё равно появился, лол.

[m3power]

@dennisdd, вы хоть на постгресе, там heap и PK не кластерный, поэтому и терпимо. в мускуле с его кластерным индексом uuid в PK это боль на порядок жирнее, таблица физически раскладывается по ключу. так что советы из статей про mysql на постгрес не тащите, и наоборот

[asynclover]

есть ещё третий путь, snowflake-подобные int64. 8 байт и сортируемые, у вк и яндекса свои генераторы такого типа. но нужен либо сервис генерации, либо раздача worker id по машинам, для 90 процентов проектов оверкилл. так что выбор простой: дорастёте до шардинга (спойлер: нет), v7 окупится. не дорастёте, bigint и не выпендривайтесь