PostgreSQL bytea vs. smallint[]

Question

Ich möchte große (100 MB – 1 GB) Mehrkanal-Zeitreihendaten in eine PostgreSQL-Datenbank importieren.Die Daten stammen von EDF-Format Dateien, die die Daten in „Datensätze“ oder „Epochen“ von typischerweise jeweils wenigen Sekunden aufteilen.Der Datensatz jeder Epoche enthält die Signale für jeden Datenkanal als sequentielle Arrays kurzer Ganzzahlen.

Ich bin verpflichtet, die Dateien in der Datenbank zu speichern, im schlimmsten Fall als BLOBs.Vor diesem Hintergrund würde ich gerne Optionen untersuchen, die es mir ermöglichen würden, mehr mit den Daten in der Datenbank zu tun, beispielsweise die Erleichterung von Abfragen auf der Grundlage der Signaldaten.

Mein ursprünglicher Plan besteht darin, die Daten als eine Zeile pro Epochendatensatz zu speichern.Was ich abzuwägen versuche, ist, ob die tatsächlichen Signaldaten als Bytea- oder Smallint[]-Typ (oder sogar Smallint[][]) gespeichert werden sollen.Könnte jemand das eine dem anderen empfehlen?Ich interessiere mich für Speicher- und Zugriffskosten.Die Verwendung erfolgt wahrscheinlich einmal, wird gelegentlich gelesen und nie aktualisiert.Wenn es einfacher wäre, einen benutzerdefinierten Typ zu erstellen, sodass ich Funktionen zum Analysieren oder Vergleichen von Datensätzen hinzufügen könnte, umso besser.

Zweifellos gehe ich nicht ins Detail, Sie können also gerne Kommentare dazu hinzufügen, was ich klarstellen soll.

Answer 1

Da es keine Antworten gab, habe ich das Problem selbst weiter untersucht.

Es sieht aus wie benutzerdefinierte Funktionen kann alle Basistypen verarbeiten, einschließlich bytea Und smallint[], daher hat dies keinen großen Einfluss auf die Wahl der Darstellung.

Ich habe mehrere verschiedene Darstellungen auf einem PostgreSQL 9.4-Server ausprobiert, der lokal auf einem Windows 7-Laptop mit einer Vanilla-Konfiguration läuft.Die Beziehungen zum Speichern dieser tatsächlichen Signaldaten waren wie folgt.

Großes Objekt für die gesamte Datei

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

SMALLINT-Array pro Kanal

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 pro Kanal in jeder Epoche

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-Array pro Epoche

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

BYTEA-Array pro Epoche

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

Anschließend habe ich über Java JDBC eine Auswahl von EDF-Dateien in jede dieser Beziehungen importiert und das Wachstum der Datenbankgröße nach jedem Upload verglichen.

Die Dateien waren:

• Datei A:2706 Epochen von 16 Kanälen, jeweils Kanal 1024 Proben (16385 Proben pro Epoche), 85 MB
• Datei B:11897 Epochen mit 18 Kanälen, jeder Kanal 1024 Samples (18432 Samples pro Epoche), 418 MB
• Datei C:11746 Epochen mit 20 Kanälen, jeder Kanal 64 bis 1024 Samples (17088 Samples pro Epoche), 382 MB

In Bezug auf die Speicherkosten ist hier die jeweils belegte Größe in MB aufgeführt:

Im Verhältnis zur ursprünglichen Dateigröße waren große Objekte etwa 30–35 % größer.Im Gegensatz dazu war die Speicherung jeder Epoche als BYTEA oder SMALLINT[][] weniger als 10 % größer.Das Speichern jedes Kanals als separates Tupel ergibt eine Steigerung von 40 %, entweder als BYTEA oder SMALLINT[], also nicht viel schlechter als das Speichern als großes Objekt.

Eine Sache, die mir anfangs nicht klar war, ist, dass „mehrdimensionale Arrays für jede Dimension übereinstimmende Ausmaße haben müssen“ in PostgreSQL.Dies bedeutet, dass die SMALLINT[][] Die Darstellung funktioniert nur, wenn alle Kanäle in einer Epoche die gleiche Anzahl an Samples haben.Daher funktioniert Datei C nicht mit EpochArray Beziehung.

Was die Zugriffskosten angeht, habe ich damit noch nicht herumgespielt, aber zumindest was das Einfügen der Daten angeht, war die Darstellung zunächst die schnellste EpochBytea Und BlobFile, mit EpochChannelArray die langsamste, die etwa dreimal so lange dauert wie die ersten beiden.