В отсутствие каких-либо ответов я сам изучил проблему.
Похоже, что пользовательские функции могут обрабатывать все базовые типы, включая 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 раза больше, чем у первых двух.