Discussion :

[Memdi]

Bonjour,

Pour info, je suis utilisateur depuis pas mal d'année de FB et par expérience j'ai des applications avec des base de 100 Go dans une centaines de tables.
ça passe mais c'est déjà lent surtout pendant les opérations de DELETE et SELECT, PURGE avec environ 2000 transaction/minute.

Je précise que 80% du volume de données est dans une même table soit entre 80 à 100 millions d'enregistrement(à 150 octet). c'est déjà très lent surtout lors des opérations delete, rollback et recalcul d'index.

Pour un projet particulier je dois prévoir de stocker plus de 2 milliard dans cette table principale soit un volume de plus 300 Go dans la base avec une config matérielle limité type mini serveur Raid 5.

Je sais par avance et par expérience que c'est hors de question avec FB dans la configuration actuelle de mes tables.

J'envisage donc de stocker uniquement dans cette table principale des aggrégat (base d'une heure) et de stocker les données brutes à l'extérieur sous forme de fichier CSV.
ça permet de limite la taille de la base FB tout en utilisant les capacités du disque en fichier beaucoup moins limitée en volume (une sorte de NoSql personnel).

Ensuite à l'exploitation, j'utilise des données aggrégées rapidement accessible dans FB (puisque compressé à 1h) et si j'ai besoin de données brutes j'utilise les fichiers sur disque en ligne de façon transparente pour l'utilisateur.

Je précise que la fragmentation en plusieurs base n'est pas envisageable.

Avez vous été confronter à un nombre si important d'enregistrement dans FB et dans une même table > 2 milliard ?
Y t il des moyens plus "normalisé" de traiter le PB, complément à FB ? bigdata ?

[makowski]

au lieu de fichier csv, tu peux utiliser des fichiers ascii fixe et les utiliser comme table externe dans Firebird tu pourras y faire des INSERT et SELECT

[Memdi]

Merci, je retiens l'idée ça peut effectivement simplifier la lecture mais peut être pas l'écriture quoi que.

Je m'explique, je ne verrai pas l'intérêt de transformer ma grosse Table en un seul fichier ASCII c'est déporté le Pb, voir s'en créer d'autre (taille du fichier ingérable , altération, impossible à lire avec des outils standard donc non tranportable, non archivable, etc.).

Mon idée est de décomposé ma grosse table en une multitude de fichier (ex: pour chaque ID un par jour), ce qui limite à 86400 enregistrements dans mon cas. ça devient transportable, archivable et lisible avec un simple tableur si besoin. Le nommage (automatique) des fichiers ressemblerait à ID.YYYY.MM.DD.txt (ou csv).

Sachant que les données sont produite aléatoirement pour chaque ID (par ordre chronologique quand même), ce qui veut dire un switch permanent pour FB d'un fichier à l'autre.
Il faudra donc vérifier pour FB si le lien de fichiers externes est consommateur de temps (< 5 msec serait l'idéal).