Начиная с 2018 года, есть ли разница в производительности при использовании bigint вместо int в качестве первичного ключа в Postgres?

Question

Я хочу иметь случайные первичные ключи во многих моих таблицах (таблица пользователей, таблица публикаций и т. Д.), Так же как и дизайн medium.com (посмотрите на идентификатор статьи в URL или в API-интерфейсе). это строка из 12 случайных шестнадцатеричных символов, которая, скорее всего, соответствует 64-разрядному целому числу), благодаря этой схеме я получаю гораздо больше места, и это также немного более безопасный дизайн, чем использование последовательных первичных ключей для противодействия автоматическим запросам, информация о веб-сайте, например, общее количество сообщений, общее количество пользователей или соскоб

Поскольку различие в хранении не так уж важно в наши дни, будет ли существенное различие в производительности, особенно для извлечения запросов, или оно будет очень незначительным в 2018 году, особенно если Postgres размещается на чем-то вроде RDS?

Answer 1

Есть ли какая-либо разница в производительности?Да.Серийные ключи будут 4 байта, а ваши ключи - 8 байтов.Это больше места и, следовательно, больше работы.

Имеет ли это значение?Возможно нет.Некоторые базы данных будут кластеризовать (т.е. сортировать) данные по первичному ключу.Postgres не делает этого.Такая кластеризация является проблемой, потому что она немедленно приводит к фрагментации для случайно сгенерированных ключей.

У вас, кажется, есть хороший вариант использования для структуры ключа, которую вы предлагаете.Хотя я не вижу проблемы a priori , вы можете проверить разницу, чтобы увидеть, имеет ли это значение для вашего приложения.