PostgreSQL bytea Первичный ключ

Question

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

log_id, log_date, primary_system_source, sub_system_source, values

Где log_id, primary_source и sub_source - целые числа, а значения - байтовый массив переменной длины (тип данных: bytea).

В большинстве случаев комбинация полей log_id, log_date, primary_system_source и sub_system_source будет достаточной в качестве первичного ключа. К сожалению, в результате разрешения отметки времени в системе регистрации в некоторых строках единственным различием между рядами является то, что значения датчиков также добавляются к первичному ключу.

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

Есть какие-нибудь подсказки, какое решение лучше?

Answer 1

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

Я бы порекомендовал просто добавить поле SERIAL PK для ссылок на другие отношения и не беспокоиться об уникальности ваших записей, поскольку вы все равно не можете разумно применять его. Вы можете определить дублированные записи журнала, если у вас есть большее количество записей в течение определенного периода времени, чем вы ожидали. Я не уверен в влиянии на производительность, но использование SELECT DISTINCT может быть более разумным, чем попытка обеспечить уникальность.