PostgreSQL bytea vs smallint []

Sto cercando di importare dati di grandi serie multicanale (100 Mb - 1 GB) in un database PostgreSQL. I dati provengono da file in formato EDF che li raggruppano in "record" o "epoche" in genere di pochi secondi ciascuno. Il record di ogni epoca contiene i segnali per ciascun canale di dati come matrici sequenziali di interi corti.

Ho il compito di archiviare i file all'interno del database, nel peggiore dei casi come BLOB. Detto questo, mi piacerebbe studiare le opzioni che mi permetterebbero di fare qualcosa di più con i dati all'interno del database, come facilitare le query basate sui dati del segnale.

Il mio piano iniziale è quello di archiviare i dati come una riga per record di epoca. Quello che sto cercando di valutare è se memorizzare i dati del segnale effettivo come bytea o smallint [] (o anche smallint [] []). Qualcuno potrebbe raccomandare uno sopra l'altro? Sono interessato ai costi di archiviazione e di accesso. È probabile che l'utilizzo venga inserito una volta, letto occasionalmente, non aggiorni mai. Se uno fosse più facilmente racchiuso in un tipo personalizzato in modo da poter aggiungere funzioni per l'analisi del confronto dei record, tanto meglio.

Non ho dubbi sui dettagli, quindi sentiti libero di aggiungere commenti su ciò che vorresti che chiarissi.

In assenza di risposte ho approfondito il problema da solo.

Sembra che le funzioni definite dall'utente possano gestire tutti i tipi di base, incluso bytea e smallint[], quindi ciò non influisce molto sulla scelta della rappresentazione.

Ho provato diverse rappresentazioni su un server PostgreSQL 9.4 eseguito localmente su un laptop Windows 7 con una configurazione vanilla. Le relazioni per memorizzare i dati del segnale effettivo erano le seguenti.

Oggetto di grandi dimensioni per l'intero file

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

Matrice SMALLINT per canale

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 per canale in ogni epoca

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

Matrice 2D SMALLINT per epoca

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

Matrice BYTEA per epoca

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

Ho quindi importato una selezione di file EDF in ciascuna di queste relazioni tramite Java JDBC e ho confrontato la crescita delle dimensioni del database dopo ogni caricamento.

I file erano:

• File A: 2706 epoche di 16 canali, ogni canale 1024 campioni (16385 campioni per epoca), 85 MB
• File B: 11897 epoche di 18 canali, ogni canale 1024 campioni (18432 campioni per epoca), 418 MB
• File C: 11746 epoche di 20 canali, ogni canale da 64 a 1024 campioni (17088 campioni per epoca), 382 MB

In termini di costi di archiviazione, ecco la dimensione occupata in MB per ogni caso:

Rispetto alle dimensioni del file originale, gli oggetti grandi erano circa il 30-35% più grandi. Al contrario, la memorizzazione di ogni epoca come BYTEA o SMALLINT [] [] era inferiore di oltre il 10%. La memorizzazione di ciascun canale come tupla separata aumenta del 40%, come BYTEA o SMALLINT [], quindi non molto peggio della memorizzazione come oggetto di grandi dimensioni.

Una cosa che inizialmente non avevo apprezzato è che "gli array multidimensionali devono avere estensioni corrispondenti per ogni dimensione" in PostgreSQL . Ciò significa che la SMALLINT[][]rappresentazione funziona solo quando tutti i canali di un'epoca hanno lo stesso numero di campioni. Quindi il file C non funziona con la EpochArrayrelazione.

In termini di costi di accesso, non ci ho giocato, ma almeno per quanto riguarda l'inserimento dei dati inizialmente la rappresentazione più veloce era EpochByteae BlobFile, con EpochChannelArrayla più lenta, impiegava circa 3 volte più delle prime due.