PostgreSQL bytea vs smallint []

Je cherche à importer des données de séries temporelles multicanaux volumineuses (100 Mo - 1 Go) dans une base de données PostgreSQL. Les données proviennent de fichiers au format EDF qui fragmentent les données en «enregistrements» ou «époques» de généralement quelques secondes chacun. L'enregistrement de chaque époque contient les signaux de chaque canal de données sous forme de tableaux séquentiels d'entiers courts.

Je suis mandaté pour stocker les fichiers dans la base de données, dans le pire des cas comme BLOBs. Compte tenu de cela, je voudrais étudier les options qui me permettraient de faire quelque chose de plus avec les données de la base de données, comme faciliter les requêtes basées sur les données de signal.

Mon plan initial est de stocker les données sur une ligne par enregistrement d'époque. Ce que j'essaie de peser, c'est de savoir s'il faut stocker les données de signal réelles sous forme de bytea ou smallint [] (ou même smallint [] []). Quelqu'un pourrait-il recommander l'un sur l'autre? Je m'intéresse aux coûts de stockage et d'accès. L'utilisation est susceptible d'être insérée une fois, lue occasionnellement, jamais mise à jour. Si l'un était plus facilement présenté comme un type personnalisé, de sorte que je pourrais ajouter des fonctions d'analyse de la comparaison des enregistrements, alors tant mieux.

Je ne doute pas de détails, alors n'hésitez pas à ajouter des commentaires sur ce que vous souhaitez que je clarifie.

En l’absence de réponses, j’ai moi-même approfondi la question.

Il semble que les fonctions définies par l'utilisateur puissent gérer tous les types de base, y compris bytea et smallint[], donc cela n'affecte pas beaucoup le choix de la représentation.

J'ai essayé plusieurs représentations différentes sur un serveur PostgreSQL 9.4 fonctionnant localement sur un ordinateur portable Windows 7 avec une configuration vanille. Les relations pour stocker ces données de signal réelles étaient les suivantes.

Grand objet pour tout le fichier

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

Réseau SMALLINT par canal

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 par canal à chaque époque

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

Tableau 2D SMALLINT par époque

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

Tableau BYTEA par époque

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

J'ai ensuite importé une sélection de fichiers EDF dans chacune de ces relations via Java JDBC et comparé la croissance de la taille de la base de données après chaque téléchargement.

Les fichiers étaient:

• Fichier A: 2706 époques de 16 canaux, chaque canal 1024 échantillons (16385 échantillons par époque), 85 Mo
• Fichier B: 11897 époques de 18 canaux, chaque canal 1024 échantillons (18432 échantillons par époque), 418 Mo
• Fichier C: 11746 époques de 20 canaux, chaque canal 64 à 1024 échantillons (17088 échantillons par époque), 382 Mo

En termes de coût de stockage, voici la taille occupée en Mo pour chaque cas:

Par rapport à la taille du fichier d'origine, les gros objets étaient environ 30 à 35% plus grands. En revanche, le stockage de chaque époque en tant que BYTEA ou SMALLINT [] [] était inférieur de 10%. Le stockage de chaque canal en tant que tuple séparé donne une augmentation de 40%, soit BYTEA soit SMALLINT [], donc pas pire que le stockage en tant que grand objet.

Une chose que je n'avais pas appréciée au départ est que "les tableaux multidimensionnels doivent avoir des extensions correspondantes pour chaque dimension" dans PostgreSQL . Cela signifie que la SMALLINT[][]représentation ne fonctionne que lorsque tous les canaux d'une époque ont le même nombre d'échantillons. Par conséquent, le fichier C ne fonctionne pas avec la EpochArrayrelation.

En termes de coûts d'accès, je n'ai pas joué avec cela, mais au moins en termes d'insertion des données, la représentation la plus rapide était au départ EpochByteaet BlobFile, avec EpochChannelArrayla plus lente, cela prenait environ 3 fois plus longtemps que les deux premières.