Discussion :

[Zugg]

Bonjour,

J'ai une question sur la structure d'une table sous Oracle 10g et 11g, mon application stocke nativement des fichiers en base comme blob dans une table tab_file:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE tab_file
(
     m_INDEX VARCHAR2 (10) DEFAULT 'IGNORE' NOT NULL       
    ,m_FILE BLOB DEFAULT empty_blob()
);

Un projet prévoit d'importer 21 000 000 de fichiers (donc autant d'entrées dans cette table).
Chaque fichier aura une taille de moins de 500Ko en moyenne.

La question est de savoir si Oracle tiendra la charge ?
Et surtout faut-il modifier le stockage des fichiers blobs en passant par des BFILE, si oui, quel est impact en terme de performance, requêtage, indexation, sauvegarde, etc ...

Merci pour vos avis

[Pomalaix]

Avec le BFILE se pose le problème de la synchronisation entre les métadonnées (chemins stockés en base) et les données réelles, notamment lors des sauvegardes, mais aussi à tout moment. Si un fichier est supprimé/déplacé au niveau de l'OS, la base n'en sait rien.

Le BFILE peut être au contraire une exigence si vos fichiers ont un contenu qui doit évoluer, et qui est modifié par des moyens externes à la base.

Le BLOB a un véritable intérêt à mon sens si la table comporte d'autres colonnes que le BLOB, qui vont être demandées lors du SELECT, alors que le BLOB ne sera la plupart du temps pas sélectionné. Comme le BLOB est un segment autonome, il n'est chargé en mémoire que s'il fait partie des colonnes appelées dans le SELECT.
(Par exemple, une table EMPLOYE dans laquelle il y aurait de nombreuses colonnes, dont une PHOTO qui est un BLOB).

Or vous semblez être dans le cas contraire : en dehors du BLOB, il n'y a rien dans votre table.

Chaque fichier aura une taille de moins de 500Ko en moyenne.
La question est de savoir si Oracle tiendra la charge ?

La question pourrait aussi être de savoir si l'OS tiendra la charge... Sauvegarder 21 millions de petits fichiers, ça n'est pas forcément une sinécure pour un OS, et ça prend généralement un temps démesuré par rapport au volume.


Voilà, en espérant que ces réflexions vous aident à choisir...

[Zugg]

Merci Pomalaix,
Sur la table j'ai d'autres colonnes et en effet si aucune requête ne demande la BLOB, le temps de requêtage ne devrait pas être impacté par cette volumétrie.

Je suis tout à fait d'accord sur le problème d'accès aux fichiers dans le cas d'utilisation de BFILE, on peut les supprimer sans que la base ne soit au courant.

Par contre concernant l'utilisation de BLOB, faut-il mieux ajouter une contrainte de stockage pour les stocker dans un tablespace à part ? Faut-il découper le tablespace en plusieurs datafiles ?
Déjà niveau stockage, un BIGFILE me semble obligatoire, non ?

Merci

[Pomalaix]

Compte tenu de vos chiffres, on est dans une volumétrie de l'ordre de 10 To.

Il faut trouver le découpage bien dosé pour que les fichiers gardent une taille raisonnable permettant de les sauvegarder/restaurer en un temps acceptable, et un nombre de fichiers total n'excédant pas, je dirais, 2 ou 300.

Dans l'absolu, 10 To peuvent tenir à l'aise dans l'unique fichier d'un tablespace BIGFILE, mais je doute qu'un tel fichier soit aisément manipulable.
Vous allez probablement avoir du partitionnement qui va déjà conduire à un premier découpage des tablespaces. Il faudra voir si la taille individuelle de ces tablespaces permet que chacun soit constitué d'un fichier unique ou non.

[Zugg]

Merci Promalaix pour ces avis.

Je vais en effet voir pour du partionnement et faire une évaluation de la volumétrie pour trouver le bon découpage pour les fichiers de données.

Mais en effet tout mettre dans un seul fichier BIGFILE ne semble pas être la meilleure solution en ce qui concerne les sauvegardes et restaurations.

[laurentschneider]

Mais en effet tout mettre dans un seul fichier BIGFILE ne semble pas être la meilleure solution en ce qui concerne les sauvegardes et restaurations.

Et pourquoi pas? Idée préconcue ou non-connaissances des nouvelles fonctionnalités?

Le blockrecover (10g) et le backup multisection (backup ... section size..., 11g) permettent restauration partielles et parallèles d'une partie d'un fichier.

[laurentschneider]

Il y a une différence fondamentale entre le bfile et le blob. Avec le bfile, tu ne passes pas de temps de chargement. Donc si tu charges 21 millions de doc en format bfile, tu en as pour quelques secondes. En format Blob, tu en as pour des jours. Après ça dépendra ce que tu veux en faire (les lire, les modifier, les indexer, etc)

[Zugg]

Dans l'application, aucune requête ne sollicite la colonne contenant le LOB si elle n'est pas nécessaire. Donc il n'y aura aucune lenteur sur cette partie.

Et lorsqu'une requête va lire ou mettre à jour le LOB, elle le fera que pour 1 seul enregistrement donc 1 seul LOB.
Avec ce fonctionnement, il ne devrait pas y avoir de ralentissement des traitements.