Discussion :

[Stopher]

Bonjour à tous,

J'ai eu l'occasion de travailler avec des base de données MongoDB durant cette dernière année, et une fonctionnalité m'a interpellé .

en effet MongoDB pré-alloue de l'espace disque pour ses fichiers de données afin d'éviter la fragmentation du fichier qui peut-être volumineux .
( d'ailleurs si quelqu'un peu m'expliquer plus en détail comment Mongo gère son système de fichier au delà de la pre-allocation je suis preneur )

L'idée me semble logique et intéressante, est-il conseillé ou déconseillé d'utiliser un principe similaire pour une base plus standard tel que Mysql Postgres , par exemple avec un système de fichier virtuel à partir d'un fichier ordinaire .

Exemple de mise en place : ftp://ftp.traduc.org/pub/lgazette/ht...9/lg109-A.html

Merci d'avance pour vos lumières.

Ch.

[Mandraxx]

Bonjour,

Je ne connais pas particulièrement MongoDB mais si ce système pré-alloue l'espace disque, c'est que ses concepteurs ont mis au point des algorithmes de gestion spécifiques.

MySQL ou PostgreSQL quant à eux sont faits pour utiliser un système de fichiers. Donc si on crée un fichier dans lequel on initialise une structure ext3, on va se retrouver avec l'empilement suivant : ext3 -> loop -> ext3 -> device alors qu'en standard, on a directement ext3 -> device.

Par conséquent, certes on réduit la fragmentation sur le système de fichiers de bas niveau mais cela ne change en rien l'état de fragmentation du système de fichiers virtuel. Donc, de ce point de vue là, on ne gagnera pas en perfs, voir on va perdre car on empile des couches logicielles et on éloigne donc l'information du hardware.

Toutefois, je vois 2 raisons pour lesquelles cette pratique peut-être intéressante (dont une seule me semble viable) :

1. la sauvegarde : faire un dump d'une base de données peut-être extrêmement consommateur en ressources et pénalisant si on a besoin d'une disponibilité de service importante. La sauvegarde directe des fichiers de données est donc souvent privilégiée lorsqu'on a un environnement industriel puisque on ne change pas de version du SGBD et que donc, les fichiers sont compatibles. Les dumps ne sont alors utilisés que lors de procédures de migration. Dans ce contexte, il n'y a qu'un seul fichier à sauvegarder au lieu de toute une arborescence complexe => possibilité de faire une somme de contrôle globale de la base pour en assurer l'intégrité physique et implantation de sauvegardes différentielles via des outils systèmes comme http://linux.die.net/man/1/rdiff
2. l'exploitation du cache : là, c'est plus du potentiel, je ne sais pas dans quelle mesure on gagne en perfs... à tester donc... Supposons qu'on a pas mal de puissance CPU (vu que le moindre PC de bureautique sort aujourd'hui avec 4 coeurs) et aussi pas mal de mémoire (dans les gros centres, c'est désormais courant de déployer des serveurs avec 24Go de RAM). Le plus gros problème que l'on rencontre avec l'approche Cloud, c'est le canal disque : il toujours trop petit ! On a d'ailleurs introduit le concept de SAN notamment pour multiplier le nombre de têtes et pouvoir utiliser des liens optiques qui permettent des débits disques 3 fois supérieurs au SCSI. La gestion de la mémoire sous Linux étant très performante, notamment en ce qui concerne le cache, il se peut (c'est ça qu'il faudrait tester) que le fait de cacher un gros fichier de plusieurs giga-octets en mémoire (le réceptacle du système de fichiers virtuel) permette de gagner en performances d'accès disque... Cependant, cela pose beaucoup d'autres problématiques (données cachées deux fois, sync difficile à maîtriser, etc.) et je ne pense pas que cela soit vraiment rentable en production.

En conclusion, je dirai que cette pratique ne peut que répondre à des besoins très spécifiques car les SGBD sont généralement optimisés pour gérer leurs fichiers.
Enfin pour la problématique de sauvegarde, la couche LVM propose des options très intéressantes comme le snapshot qui permet de faire une image d'un système de fichier en quelques secondes sans pour autant nécessiter un empilement de deux couches ext3 (puisqu'on travaille directement au niveau bloc).

@+

[Stopher]

Un grand merci à toi pour ta réponse ,

Effectivement Mongo doit avoir une bonne raison pour utiliser ce principe.

Bien que celà à priori n'apporte pas vraiment d'avantages , voir plus d'inconvénients, je vais tenter de "benchmarker" avec et sans l'utilisation d'un fichier de données, juste pour ... ma culture personnelle

Bonne journée,
Ch.

[Katyucha]

D'après ce que je lis, j'ai l'impression de voir les TABLESPACES d'Oracle. Même principe : tu alloues un espace disque (un gros fichier bien vide) que tu remplis après. Un conteneur dans le conteneur filesystem.

[thierry.chich]

Bonjour,
MySQL ou PostgreSQL quant à eux sont faits pour utiliser un système de fichiers. Donc si on crée un fichier dans lequel on initialise une structure ext3, on va se retrouver avec l'empilement suivant : ext3 -> loop -> ext3 -> device alors qu'en standard, on a directement ext3 -> device.

Bonjour,
Ou je ne comprends pas ce que tu veux dire, ou tu es en train de dire qu'un fichier de mysql est une image d'un système de fichier ext3 monté sur une loopback. Les fichiers .myd ? Je suis surpris. Tu as des références ?

A+

[Stopher]

Salut thierry.chich,

En fait, le principe expliqué est le suivant :

1 : Création d'un fichier de donnée à taille fixe
3 : On crée un système de fichier sur ce "disque" virtuel ( loop )
3 : On monte ce dernier.

Puis on y place simplement les fichiers de données de Mysql / PostgreSql


D'ailleurs ça me traverse l'esprit, mais il y a un autre avantage à ce principe, il est possible de l'utiliser comme jail, "chrooter" les applications de notre choix .

[gangsoleil]

Bonjour,

Dans le cas des gros moteurs de base de donnees, il est effectivement possible de leur offrir de travailler sur une partition vierge : c'est le moteur de la base de donnees qui se debrouille avec son format de fichier, sa gestion, ... qui sont adaptes a la base de donnees, pour plus de rapidites.

Dans ton cas, tu veux creer un niveau d'abstraction en plus, via la virtualisation. D'ou une perte de performance obligatoire.

[thierry.chich]

Ok, j'avais mal lu la question initiale. Si le but est de limiter la fragmentation des fichiers de la DB, plutôt que faire un système de fichier sur une loopback, il me semblerai plus logique de réserver une partition directement.
Dans tous les cas, je ne suis pas sûr qu'on y gagne vraiment de manière significative. D'autant que les technos de SSD sont en train de rendre la question de la fragmentation totalement accessoires.