У меня уже есть несколько миллионов строк в моей базе данных. Я не знал о типе данных PostgreSQL UUID, когда проектировал свою схему.
В одной из таблиц имеется 16 миллионов строк (от 3,5 до 4 миллионов записей на шард), число которых увеличивается примерно на 500 тысяч записей в день. Я все еще могу позволить себе отключить производственную систему на несколько часов, если потребуется. У меня не будет этой роскоши через одну или две недели.
У меня вопрос, стоит ли это делать? Меня интересует производительность JOIN, использование дискового пространства (дамп полного gzip'd составляет 1,25 ГБ) и тому подобное.
Схема таблицы:
# \d twitter_interactions
Table "public.twitter_interactions"
Column | Type | Modifiers
-------------------------+-----------------------------+-----------
interaction_id | character(36) | not null
status_text | character varying(1024) | not null
screen_name | character varying(40) | not null
twitter_user_id | bigint |
replying_to_screen_name | character varying(40) |
source | character varying(240) | not null
tweet_id | bigint | not null
created_at | timestamp without time zone | not null
Indexes:
"twitter_interactions_pkey" PRIMARY KEY, btree (interaction_id)
"twitter_interactions_tweet_id_key" UNIQUE, btree (tweet_id)
"index_twitter_interactions_on_created_at" btree (created_at)
"index_twitter_interactions_on_screen_name" btree (screen_name)
Triggers:
insert_twitter_interactions_trigger BEFORE INSERT ON twitter_interactions FOR EACH ROW EXECUTE PROCEDURE twitter_interactions_insert_trigger()
Number of child tables: 9 (Use \d+ to list them.)
postgresql
Франсуа Босолей
источник
источник
Я не слишком посторонний человек, но исходя из того, что я знаю по SQL Server, чем больше строк вы можете разместить на странице данных, тем выше будет производительность (обычно чтение данных с диска самая дорогая операция). Таким образом, переход от 36- разрядного 1- байтового поля к 16-байтовому GUID кажется прямой экономией затрат. Чем меньше операций чтения вы можете выполнить, тем быстрее вы сможете вернуть результаты. Все это, конечно, предполагает, что GUID / UUID удовлетворяет бизнес-требованиям таблицы. Если UUID удовлетворит это, будет ли bigint ? Это еще больше сократит ваши затраты на хранение еще на 8 байт на строку.
Редактировать 1
Для символьных данных в Postgres существует дополнительная стоимость хранения. Короткие строки, до 127 байт, имеют издержки в 1 байт, в то время как у чего-то более длинного - 4 байта, как у второго респондента с 40-байтовой стоимостью для поля в 36 байт. Но есть также опция для сжатия строк, так что, возможно, она не будет стоить полных 40. Я не могу сказать, какова будет конечная стоимость, но основные принципы остаются: что-нибудь более 16 байтов увеличит стоимость хранения, потребуется больше времени для чтения из и потреблять больше памяти.
источник
Помимо проблемы с пространством, имейте в виду, что вам нужно будет изменить каждую таблицу, чтобы использовать правильный тип данных, иначе производительность соединения будет сильно снижаться.
источник
В дополнение к экономии в размере данных и индексов (как говорят другие), которая переводится в экономию ввода / вывода, необходимо учитывать, как вы будете генерировать новые значения
interaction_idи как это повлияет на индексы и условия запроса (объединения).Для индекса - он будет меньше, однако, если во многих ваших запросах используются сканирования индекса, переключение на UUID может сделать сканирование индекса невозможным (в зависимости от того, как вы будете генерировать UUID) и
bigintможет быть гораздо лучшим выбором.Наконец, фактическое влияние на производительность зависит также от ваших моделей использования и распределения данных, вы должны выполнять тесты и иметь среду разработки и тестирования, в которой вы можете тестировать свои изменения.
Это даст вам гораздо более точный ответ о влиянии на производительность.
источник