Индекс вместо первичного ключа для типа UUID в PostgreSQL

Question

Во-первых, я прочитал несколько сообщений об этом, как этот: Postgresql: UUID или SEQUENCE для первичного ключа?

Мой вопрос довольно прост: мои идентификаторы в моей таблице - UUID v4 (созданный в Rails или из приложения iOS). Поскольку UUID по умолчанию является уникальным, могу ли я удалить первичный ключ для идентификатора и просто добавить индекс для него? Основная (и uniq?) Цель - сэкономить время (несколько мс) при вставке (PostgreSQL не нужно проверять, используется ли уже идентификатор) при каждой вставке.

Это хороший выбор? Или я оставляю PK, чтобы добавить еще одну проверку уникальности перед вставкой?

Для справки, таблица может обрабатывать 10 миллионов записей.

Answer 1

Оба ключа, которые вы описываете, по-видимому, используются в качестве суррогатных ключей. Суррогатное значение, означающее, что они не являются производными от входящих данных и, следовательно, не имеют к ним никакого отношения, кроме обеспечения уникальности.

Вам не нужны 2 ключа для обеспечения уникальности, поэтому ответ на ваш вопрос заключается в том, что вы можете выбросить один или другой из ключей. Размер таблицы здесь не имеет большого значения, так как uuid_v4 () обеспечит уникальность для значительно больших наборов данных, чем 10M строк.

Наличие 2 ключей для уникальности не просто ненужно, но и является узким местом. Оба значения должны быть созданы во время вставки, и оба должны быть проверены на уникальность. Удаление одного из них является явно лучшей практикой.

Answer 2

Во-первых: UUID не являются действительно уникальными. Но вероятность генерирования двойных значений действительно очень мала ( Насколько уникален UUID? ).

Но есть некоторые другие проблемы с UUID. UUID сделаны для обмена данными между различными точками. Так что, если вы подумаете о двух базах данных, которые взаимодействуют, они будут использовать одни и те же наборы данных с одинаковым UUID. Теперь подумайте об архиве, где хранятся наборы данных из многих источников. Вы можете иметь наборы данных с тем же UUID из некоторых старых сообщений.

Так что это зависит от ваших текущих (и, возможно, будущих) вариантов использования, если это может создать какие-либо проблемы.

Кроме того, я не уверен, создает ли это какие-либо преимущества перед простым целочисленным значением, касающимся пространства вашего индекса первичного ключа. Обратите внимание, что каждый первичный ключ автоматически создает внутренний индекс по умолчанию (поэтому, тем не менее, нет необходимости создавать отдельный индекс). Поэтому индекс первичного ключа для целочисленного столбца может быть меньше и быстрее.