Journal FS pour stocker plusieurs millions de docs

Posté par  (site web personnel) .
Étiquettes : aucune
0
8
jan.
2004
Bonjour Journal,

A ton avis quel est le meilleur FS pour stocker des millions de documents sur des disques et quelle est pour toi la meilleure repartition (un seul repertoire avec plein de fichiers, ou plein de repertoires avec un peu de fichiers, ou un gros fichiers rassemblant tous les fichiers)

C'est pour le stockage de documents d'un systeme de Gestion Electronique de Documents....

Merci Journal....

  • # Re: FS pour stocker plusieurs millions de docs

    Posté par  . Évalué à 3.

    Et pourquoi pas une base de donneés tout simplement ?

    SAP-DB ou PostreSQL devraient tenir la charge pour ce genre de choses. En plus, tu peux ajouter quelques colonnes d'indexage, ce qui est toujours utile, par exemple:

    - auteur
    - date parution
    - date dernière modif
    - nb fois consulté
    - liste de mots clefs
    - le doc lui meme (blob)

    Ca t'évite ainsi à maintenir des meta-datas "ailleurs". Tu as tout au même endroit.

    Mes 30 centimes d'euro...

    Eric.

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  (site web personnel) . Évalué à 2.

      Merci pour tes conseils.

      Les index de mes documents sont deja dans une base SQL.

      Le probleme est que si je stocke les fichiers images (d'une taille moyenne de 70 ko) dans la base SQL elle va vite faire plusieurs Go et les sauvegardes vont pas mal m'embeter car j'ai pour objectif de faire de faire un module de sauvegarde sur CD de 650Mo autonome. C'est a dire que chaque CD de 650 mo contiendra ses index et ses images et pourra etre utilise independamment des autres cd.

      Donc le stockage dans une base de donnees ne m'arrange pas trop je crois. Mais je peux me tromper et suis pret a suivre tout bon conseil.

      Merci

      • [^] # Re: FS pour stocker plusieurs millions de docs

        Posté par  . Évalué à 5.

        Comment tu backup et comment tu stockes me semblent des soucis orthogonaux. A priori, le problème de "découper" ton archive en blocks de 650 Mo se posera aussi avec tes fichiers sur un FS.

        Ce que tu pourrais faire:
        - Stocker qqpart le numéro du CD courant et la place occupée dessus
        - Lorsqu'un doc est ajouté, tu lui attribue le numéro du CD courant, sauf si sa taille ferait dépasser les 650 Mo, auquel cas, tu passe d'abord au CD suivant
        - Dans la table qui stocke les docs, tu as donc une nouvelle colonne "CD"

        Pour faire une sauvegarde du CD numero X, un simple SELECT ... WHERE CD=X suffit pour retrouver toutes les données, les écrires dans le format qui te convient dans un répertoire temporaire, puis lancer le gravage.

        Tout ça se script très bien.

        ***

        Maintenant, si la taille de ton archive est de plusieurs Go, peut être que la sauvegarde sur CDs n'est tout simplement pas adaptée, à part comme archive finale. Parce que si ton disque crash, pour fare un restore tu n'est pas arrivé... :-)

      • [^] # Re: FS pour stocker plusieurs millions de docs

        Posté par  . Évalué à 1.

        Les index de mes documents sont deja dans une base SQL.

        Le probleme est que si je stocke les fichiers images (d'une taille moyenne de 70 ko) dans la base SQL elle va vite faire plusieurs Go

        J'ai déjà utilisé une méthode intermédiaire, qui est de stocker les fichiers images (ou binaires quels qu'ils soient) dans le filesystem, et de garder dans la base SQL le chemin vers le fichier. Comme ça on a le meilleur des 2 mondes, les méta-données dans la base SQL (comme le propose Nicolas Eric plus haut http://linuxfr.org/comments/325699.html(...)), sans la lourdeur associée à l'utilisation de BLOB (Binary Large OBject).

        • [^] # Re: FS pour stocker plusieurs millions de docs

          Posté par  (site web personnel) . Évalué à 1.

          Il n'y a pas que le meilleur des deux mondes là dedans :
          - Le coup de la base de données mixte (SGBRD / filesystem) c'est intéressant pour chercher un fichier via des métadonnées, mais si ce n'est pas le cas (recherche en texte intégral, par exemple), ça n'apporte pas grand chose.
          - Dans le même ordre d'idée, ça n'amène pas de solution quand à la vitesse d'accès au fichier en lui même ou encore aux problèmes de limitation du nombre de fichier par répertoire : tu dois quand même trouver un schéma d'organisation de tes fichiers sur le FS.
          - Le dernier problème de taille est le problème de la cohérence : tu ne peux plus t'appuyer sur le SGBDR pour t'assurer qu'il existe bien un fichier là où tu l'indiques dans la BDR et tu es obligé de faire des scripts à éxécuter régulièrement pour chercher les fichiers non référencés par le SGBDR.

  • # Re: FS pour stocker plusieurs millions de docs

    Posté par  (site web personnel) . Évalué à 10.

    N'importe lequel, ca dépend surtout (à mon avis) de la taille de chacun des fichiers (touts petits, tres gros ...) mais surtout de la fiabilité que tu veux en donner :

    - ext2 => probleme de fsck en cas de crash, mais système TRES connu et donc TRES facile à déboguer en cas de crash majeur. Nécessite de répartir les fichiers dans des dossiers / sous-dossiers (pas plus de 1000 à 2000 entrée par répertoire, après ca commence à ramer)

    - ext3 => plus de probleme de fsck, grâce au journal, même probleme qu'ext2 : il faut répartir les fichiers. J'ai eu (no-log) (ainsi qu'altern.org) 2 serveurs sous ext3 (debian woody) qui ont perdu un gros bout de leur partition comme ca tout à coup, et crash + reboot => j'ai tout perdu, retour au snapshot de la veille... ca refroidit...

    - reiserfs -> pas de probleme de fsck, (journalisé) mais en plus il gère très bien les tous petits fichiers et les dossiers contenant pleins de fichiers (grâce à un système d'arbre). Sachant que pour l'humain lui-même, il vaut mieux toujours répartir les fichiers sur plusieurs dossiers histoire de s'y retrouver. Même probleme qu'avec ext3 : j'ai eu plusieurs crash de partition, ca ne pardonne généralement pas.

    - xfs -> ressemble assez à ext3, avec quelques petits plus, mais comme reiserfs, en cas de crash majeur, il est très peu connu donc difficile à déboguer. J'utilise xfs depuis 2 ans sur des serveurs de fichiers, 0 soucis.

    Dans tous les cas, je conseille d'utiliser des systèmes de snapshoting ou de backup propre pour pouvoir être parapluie/parasol/paratonnerre et BunkeR

    - rsync est ton ami

    - inter-mezzo est pas mal pour synchroniser un disque en quasi temps-réel et disposer ainsi d'un système de secours

    - Les cartes scsi ou ide raid marchent bien aujourd'hui, mais si tu n'as pas le budget, le raid logiciel linux c'est tout aussi bien en terme de sécurité. (et pas loin en terme de perf, tout dépend de ton chipset ide/scsi)

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  . Évalué à 1.

      Salut,

      >> - inter-mezzo est pas mal pour synchroniser un disque en quasi temps-réel et disposer ainsi d'un système de secours

      Tu t'es servi d'intermezzo en production ?
      Dans le cas de deux FS distants, sais-tu s'il peut y avoir modification des données des deux côtés, et, y a-t-il un mecanisme de lock des fichiers d'un côté pour les fichiers ouverts de l'autre ?

      Je suis en train de RTFM mais je ne trouve pas cette information.

      Merci d'avance

    • [^] # RAID logiciel & matériel

      Posté par  . Évalué à 1.

      Les cartes scsi ou ide raid marchent bien aujourd'hui...
      Côté budget, on trouve assez facilement des cartes controlleurs IDE RAID 0, 1, 0+1 à base de chipset Silicon Image 680 ou apparentés pas cher du tout.
      A titre d'exemple : http://www.monsieurprix.com/listing/gen/J000024811.html(...) , entre 20 et 60 €
      Un peu plus cher : les cartes IDE RAID Promise depuis longtemps supportées.
      Sinon du SCSI mais la note devient plus salée...

      Depuis la version 2.4.20, le noyau supporte le chipset SI680 pour donner accès à un RAID matériel (même si je n'ai pas encore trouvé comment... faute de temps).

      le raid logiciel linux c'est tout aussi bien en terme de sécurité
      Tout à fait...
      Avec une carte controlleur SI 680 sur une vieille carte mère (ABIT BP6), j'ai 2x2 disques en RAID 1 à l'origine de 5 partitions RAID logiciel (j'avoue, c'est un poil dommage avec un controlleur RAID matériel mais bon...), elles-mêmes partiellement partagées en NFS & Samba pour +/-5 postes : c'est une véritable tranquilité d'esprit.
      Même si les synchronisations complètes (rares et uniquement dûes à reboot en court de reconstructions antérieures, sinon fait en temps réel) consomme de 20 à 25 % de CPU (ça reste tout de même de l'IDE), les utilitaires d'administration *raid* sont particulièrement complets : mkraid, raidhottadd ...

      Une documentation de sensibilisation pratique pour débuter : http://www.lea-linux.org/admin/raid.php3(...)

      Dernier point, un reproche concernant ce RAID : on en arrive à négliger les sauvegardes... ;o+

      < toulouse >
      Si ça intéresse qqu'un, on trouve des controlleurs SI680 en magasin chez European Computer, pas cher...
      < /toulouse >

      • [^] # Re: RAID logiciel & matériel

        Posté par  . Évalué à 2.

        "Dernier point, un reproche concernant ce RAID : on en arrive à négliger les sauvegardes... ;o+"

        Et pourtant, pour avoir vu passer moult ordinateurs de clients foudroyés un soir d'orage, je peux te dire que le RAID ne serait certainement d'aucun secours dans ces cas là, puisque en général, ce sont tous les composants qui crament (si si, c'est assez impressionnnant à voir, un éclair, une tite surtension, et plop, adieu alimentation, carte mère, processeur, barettes mémoire, disques durs, lecteur de CD-Rom, etc, la totale).

        Evidemment, ce n'est pas hyper fréquent, cela n'arrivait que 2 fois par an sur un fichier de 5000 clients, mais en production, si tu n'as pas de sauvegardes sur bande, ton SI est mort...

        Sinon, j'ai aussi vu des alimentations qui au moment où elles terminent leur vie (dans un plop infâme encore une fois), balancent un grand coup de jus dans les périphériques connectés, et encore une fois, adieu le matériel :(

        • [^] # Re: RAID logiciel & matériel

          Posté par  (site web personnel) . Évalué à 1.

          Un raid ne protège que d'une chose : la mort d'un disque. Ce qui est en faite assez rare.

          Pour boussiller la partition : tu as les problèmes élèctrique due aux alims de merde et/ou non protégé de la foudre, plus d'un disque meurt et le raid ne sert à rien.

          Il y a le crash du FS. Ce qui arrive vu qu'ils sont assez rescent finalement. Ils y aussi la coupure de courant un peu trop brutal (fausse manip, inconscience...)

          Y'a le programme fou, ce n'est pas lier au kernel mais cela mettre le bazar.

          Et puis, il y a "l'erreur fatal" (tm) le rm -rf avec un blanc de trop...

          La sauvegarde style rsync + cp -ia à l'air pas mal. Sinon l'idée serait de dupliquer les serveurs. Genre la base dupliqué par la réplication interne et un rsync ou intermezzo entre 2 serveurs de fichier. Tu gagnes des perfs et si l'un meurt tu as toujours tes données. Mais dans ce cas les 2 machines sont "liés" et un rsync "dans le mauvais sens" peut tout casser.

          Cela peut être mieux que de passer des Go de donné par le lan tout les soirs.

          "La première sécurité est la liberté"

        • [^] # Gestion du risque...

          Posté par  . Évalué à 1.

          ce sont tous les composants qui crament
          [snip]
          des alimentations qui au moment où elles terminent leur vie (dans un plop infâme encore une fois), balancent un grand coup de jus dans les périphériques connectés, et encore une fois, adieu le matériel
          Tu as vraiment le verbe pour rassurer toi... ,o)
          Mais en ce qui me concerne, ce ne sont que des données persos, partiellement restaurables et abritées derrière une prise "anti-foudre garantie" et une alim' avec un fusible. Quelque part, je reste (partiellement) serein... mais je finirai par ne plus repousser à demain la mise en place d'une solution de sauvegarde adaptée.

          Pour des données sensibles, les sauvegardes périodiques complètes et incrémentales restent effectivement incontournables, idéalement sur un support externe, stocké sur un autre site (en n'oubliant pas des tests réguliers de restauration).
          Pour la continuité de service, il est nécessaire aussi d'envisager du matériel haute disponibilité avec une redondance totale du matériel, de l'alim' au disque dur, et synchronisation en temps réel; l'une des solutions n'excluant pas l'autre.

          Mais tout cela s'adresse plus au monde professionnel. A mon niveau, la gestion du risque se heurte à mes moyens...

      • [^] # Re: RAID logiciel & matériel

        Posté par  . Évalué à 1.

        Côté budget, on trouve assez facilement des cartes controlleurs IDE RAID 0, 1, 0+1 à base de chipset Silicon Image 680 ou apparentés pas cher du tout.
        Encore faudrait -il avoir un driver correct (y en a un en 2.4 mais je suis pas certain qu'il soit tres efficace)....

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  . Évalué à 1.

      - ext3 => plus de probleme de fsck, grâce au journal, même probleme qu'ext2 : il faut répartir les fichiers. J'ai eu (no-log) (ainsi qu'altern.org) 2 serveurs sous ext3 (debian woody) qui ont perdu un gros bout de leur partition comme ca tout à coup, et crash + reboot => j'ai tout perdu, retour au snapshot de la veille... ca refroidit...
      Dans le 2.6, les htree permete une gestion plus efficace des repertoire contenant beaucoup de fichier.

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  . Évalué à 1.

      Pour les performances d'un système devant supporter un grand nombre de fichiers, il y a peut-être des choses intéressantes du côté de Lustre (http://www.lustre.org(...) ), un projet GPL de la société ClusterFS (qui peut fournir un support commercial).

      Le projet est passé en version 1.0 le mois dernier.

      En gros, les données peuvent être réparties sur plusieurs serveurs. Il y a également moyen d'avoir des "snapshots" des données. Pleins de trucs intéressant, je trouve... Je n'ai jamais eu l'occasion de le tester mais il va falloir que je m'y mette un de ces jours...

  • # Re: FS pour stocker plusieurs millions de docs

    Posté par  . Évalué à 2.

    J' ai eu à réfléchir sur ce genre de problème, en fait il y a une limite plutôt basse (quelques milliers) pour la plupart des fs au nombre de fichiers par répertoire. On peut en fait avoir beaucoup de fichiers par répertoire, mais souvent avec une augmentation du temps d'accés rédibitoire.

    Il est donc judicieux de classer les fichiers dans plusieurs sous-rep, avec un moyen rapide de les retrouver - par ex année/mois/jour, ou tout autre système de classement. Là on se rapproche des pbs de cléfs dans les tables de hash, il faut essayer de répartir le plus uniformément les fichiers (ie ne pas avoir 90 % des fichiers dans 10 % des répertoires).

    Concernant les temps d'accés, je pense qu'un fs comme reiserfs devrait mieux supporter la charge que ext2/3 ; il utilise un sytème d'arbre balancé pour atteindre les données rapidement. D'autres fs sont sûrement équivalent, cf les nombreux benchs dispo...

    Reste aussi la solution sus-mentionné d'une base de données ; je pense que le choix dépend de la taille de fichiers, de leur nombre, du nombre d'accés, le mieux est de faire des tests ;-)

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  . Évalué à 1.

      Pour la plupart des vieux systèmes de fichiers (ou basés sur des vieux) (ext2, ext3, ...) il est effectivement peu judicieux de mettre beaucoup de fichiers dans un même repertoire.

      Pour les système de fichiers modernes (reiserfs, xfs, jfs, hfs+, ...) qui fonctionnement quasiment tous avec des arbres la difference entre une mise a plat et une arborescence est négligeable, c'est donc selon l'utilisation que tu choisis.

    • [^] # Re: FS pour stocker plusieurs millions de docs

      Posté par  . Évalué à 2.

      Il y un truc qui se fait; c'est de creer des repertoires suivant la 1er, 2eme, ... lettre du fichier et de le mettre là. Mais je ne sais pas ce que ça vault.

      Ex: le fichier toto.xml est dans ./t/o/toto.xml

      • [^] # Re: FS pour stocker plusieurs millions de docs

        Posté par  . Évalué à 2.

        tous les hebergeurs que j'ai pu voir stockent les comptes de cette maniere ...
        ce n'est efficace que si ti ne fait qu'une recherche alphabetique des documents. (normalisation des noms ?)

        Dam

        • [^] # Re: FS pour stocker plusieurs millions de docs

          Posté par  . Évalué à 1.

          Et si la répartition des noms est a peu prés uniforme. C'est le pb de clefs de table de hache que j'évoquais plus haut.

        • [^] # Re: FS pour stocker plusieurs millions de docs

          Posté par  (site web personnel) . Évalué à 1.

          Dans mon cas c'est plus simple car pour visualiser un document je me refere aux index qui sont stockes dans une base de donnees et qui contiennent le chemin de l'image a voir.

          Donc pour le stockage en repertoires multiples je peux m'inspirer par exemple du module proxy de apache qui fait un truc tu genre [A[ABCD[ABCDEF]],B,C]

          • [^] # Re: FS pour stocker plusieurs millions de docs

            Posté par  (site web personnel) . Évalué à 1.

            C'est pas forcément idéal : si tu as beaucoup de documents commençant par a e i u o ;) ou d r l n m et pas du tout par k x w y z q ...

            Squirrelmail utilise une méthode bien plus "hash compliant" : il ont réparti les dossiers selons les 1er, 2nd, 3e (selon la profondeur configurée) lettre du md5sum du nom du fichier. C'est rapide à faire, et comme tu le dis, l'index étant en base, ca va tout aussi vite.

            • [^] # Re: FS pour stocker plusieurs millions de docs

              Posté par  (site web personnel) . Évalué à 1.

              Non ce que je voulais dire c'est par exemple (suivant le nombre de document) je decide que chaque repertoire contient 256 repertoires et je decide que je peux par exemple mettre mille documents par repertoire final....

              Mais la repartition n'est nullement alphabetique.

              Ca donnerai (dans le cas ou je configure 2 repertoires)


              Racine
              / \
              A B
              / \ / \
              A B A B
              Fic 1 Fic 500 Fic 900 Fic 1300
              Fic 2 Fic 501 Fic 901 Fic 1301
              ... ... ... ...

              Et l'index de la base me donne par exemple :
              ID_Doc=501
              Libelle=Test DLFP
              Type=X
              Img=../A/B/Fic501
              ...

  • # Quel systeme de gestion ?

    Posté par  . Évalué à 1.

    Je sais que ce n'est pas la question, mais tu utilises quel systeme pour gerer tes documents ? Tout fait maison ou tu es parti de quelque chose qui existe ?

    Et deuxieme question: qu'est-ce qui existe dans le domaine ?

    Zorglub

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.