PostgreSQL bytea против smallint []

Я хочу импортировать большие (100 МБ - 1 ГБ) данные многоканальных временных рядов в базу данных PostgreSQL. Данные поступают из файлов формата EDF, которые разделяют данные на «записи» или «эпохи», обычно по несколько секунд каждый. Запись каждой эпохи содержит сигналы для каждого канала данных в виде последовательных массивов коротких целых чисел.

Я уполномочен хранить файлы в базе данных, в худшем случае как BLOB. Учитывая это, я хотел бы изучить варианты, которые позволили бы мне сделать что-то большее с данными в базе данных, например, облегчить запросы, основанные на данных сигнала.

Мой первоначальный план - хранить данные в виде одной строки на запись эпохи. Я пытаюсь взвесить, сохранять ли фактические данные сигнала в виде байтов или smallint [] (или даже smallint [] []). Может ли кто-нибудь рекомендовать один над другим? Я заинтересован в хранении и стоимости доступа. Использование может быть вставлено один раз, время от времени читать, никогда не обновлять. Если бы его было легче обернуть как пользовательский тип, чтобы я мог добавить функции для анализа сравнения записей, то тем лучше.

Без сомнения, у меня мало деталей, поэтому не стесняйтесь добавлять комментарии к тому, что вы хотите, чтобы я разъяснил.

В отсутствие каких-либо ответов я сам изучил проблему.

Похоже, что пользовательские функции могут обрабатывать все базовые типы, включая bytea и smallint[], так что это не сильно влияет на выбор представления.

Я опробовал несколько различных представлений на сервере PostgreSQL 9.4, работающем локально на ноутбуке с Windows 7 с ванильной конфигурацией. Отношения для хранения этих фактических данных сигнала были следующими.

Большой объект для всего файла

CREATE TABLE BlobFile (
    eeg_id INTEGER PRIMARY KEY,
    eeg_oid OID NOT NULL
);

SMALLINT массив на канал

CREATE TABLE EpochChannelArray (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    channel INT,
    signal SMALLINT[] NOT NULL,
    PRIMARY KEY (eeg_id, epoch, channel)
);

BYTEA за канал в каждую эпоху

CREATE TABLE EpochChannelBytea (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    channel INT,
    signal BYTEA NOT NULL,
    PRIMARY KEY (eeg_id, epoch, channel)
);

SMALLINT 2D массив за эпоху

CREATE TABLE EpochArray (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    signals SMALLINT[][] NOT NULL,
    PRIMARY KEY (eeg_id, epoch)
);

Массив BYTEA за эпоху

CREATE TABLE EpochBytea (
    eeg_id INT NOT NULL,
    epoch INT NOT NULL,
    signals BYTEA NOT NULL,
    PRIMARY KEY (eeg_id, epoch)
);

Затем я импортировал выборку файлов EDF в каждое из этих отношений через Java JDBC и сравнивал рост размера базы данных после каждой загрузки.

Файлы были:

• Файл A: 2706 эпох из 16 каналов, каждый канал 1024 выборки (16385 выборок в эпоху), 85 МБ
• Файл B: 11897 эпох из 18 каналов, каждый канал 1024 выборки (18432 выборки в эпоху), 418 МБ
• Файл C: 11746 эпох из 20 каналов, каждый канал от 64 до 1024 выборок (17088 выборок за эпоху), 382 МБ

С точки зрения стоимости хранения, вот размер, занимаемый в МБ для каждого случая:

Относительно исходного размера файла, крупные объекты были примерно на 30-35% больше. Напротив, сохранение каждой эпохи как BYTEA или SMALLINT [] [] было менее чем на 10% больше. Хранение каждого канала в виде отдельного кортежа дает увеличение на 40%, как BYTEA или SMALLINT [], что не намного хуже, чем хранение в виде большого объекта.

Одна вещь, которую я изначально не оценил, заключается в том, что «многомерные массивы должны иметь совпадающие экстенты для каждого измерения» в PostgreSQL . Это означает, что SMALLINT[][]представление работает только тогда, когда все каналы в эпоху имеют одинаковое количество выборок. Следовательно, файл C не работает с EpochArrayотношением.

С точки зрения стоимости доступа, я не играл с этим, но, по крайней мере, с точки зрения вставки данных, изначально самым быстрым было представление, EpochByteaа BlobFileс EpochChannelArrayсамым медленным - примерно в 3 раза больше, чем у первых двух.