Первичный ключ UUID в Postgres, какое влияние на производительность вставки?
Мне интересно, как влияет на производительность использование непересекающегося UUID в качестве первичного ключа в таблице, которая станет довольно большой в PosgreSQL.
в СУБД, которые используют кластеризованное хранилище для записей таблиц, указано, что использование UUID увеличит стоимость вставок из-за необходимости чтения с диска, чтобы найти страницу данных, в которую выполнить вставку, как только таблица слишком велика для хранения в памяти. Насколько я понимаю, Postgres не поддерживает row кластеризация на вставках, поэтому я полагаю, что в Postgres использование UUID PK не повредит производительности этой вставки.
но я бы подумал, что это делает вставку в индекс, что ограничение первичного ключа создает намного дороже, когда таблица большая, потому что ее придется постоянно читать с диска, чтобы обновить индекс при вставке новых данных. В то время как с последовательным ключом индекс будет обновляться только на кончике, который всегда будет в память.
предполагая, что я правильно понимаю влияние производительности на индекс, есть ли способ исправить это или UUIDs просто не является хорошим ПК на большой, неразделенной таблице?
1 ответов
Как я понимаю, Postgres не поддерживает кластеризацию строк на вставках
правильным на данный момент. К сожалению.
поэтому я полагаю, что в Postgres использование UUID PK не повредит производительности этой вставки.
он по-прежнему имеет стоимость производительности из-за необходимости поддерживать PK и потому, что вставленный кортеж больше.
uuid в 4 раза шире типичный 32-битный целочисленный синтетический ключ, поэтому строка для записи на 12 байт больше, и вы можете поместить меньше строк в заданный объем ОЗУ
индекс b-дерева, реализующий первичный ключ, будет в 4 раза больше (против 32-битного ключа), что займет больше времени для поиска и потребует больше памяти для кэширования. Он также нуждается в более частых разделениях страниц.
записи, как правило, будут случайными в индексах, а не добавляются в горячие, недавно доступные строки
есть ли способ исправить [влияние производительности на индекс] или UUIDs просто не является хорошим ПК на большой, неразделенной таблице?
Если вам нужен ключ UUID, вам нужен ключ UUID. Вы не должны использовать его, если он вам не нужен, Но если вы не можете полагаться на центральный источник синтетических ключей и нет подходящего естественного ключа для использования, это все еще путь.
разделение не поможет, если вы не можете ограничьте запись в один раздел. Кроме того, вы не сможете с пользой использовать исключение ограничений для поиска ключа при записи только в один раздел за раз, поэтому вам все равно придется искать ключ во всех индексах разделов при выполнении запросов. Я вижу, что это полезно, только если ваш UUID является частью составного ключа, и вы можете разбить на другую часть составного ключа.