Journal Une base de données pour /home ?

Posté par .
Tags : aucun
0
27
oct.
2004
En regardant l'evolution des applications récentes, je trouve une certaines similitude :

kaspaliste (gestion de documents) utilise postgreSQL
Mythtv (tivo like) utilise mySQL
Kimdaba (gestion photos) utilise une base de données
Amarok (gestion audio) utilise lui aussi une base de donées
La future gestion des bookmarks de konqueror aussi

Plutot que de chercher de nouvelles solutions pour gérer ses documents sous linux, est ce que l'on ne pourrait pas stocker les donnees de /home dans une base de donnée genre mySQL ?

/home/TOTO contient des fichiers de configuration qui n'y ont peut etre pas leur place, mais on peut imaginer que /home/TOTO/Documents soit lui entièrement une base de donées...
  • # fs VS db

    Posté par (page perso) . Évalué à 3.

    Pour faire une recherche, la base de données sera toujours plus rapide.

    mais pour cracher de l'info brute, je pense que le bon vieux filesystem sera toujours le plus performant.

    C'est pour cela que l'on voit apparaître des solutions mixtes. un FileSystem pour stocker les fichiers et une base de données pour indexer les informations clefs des fichiers (nom, taille, date de création, etc...)

    --
    bozozo
    • [^] # Re: fs VS db

      Posté par . Évalué à 3.

      pour cracher de l'info brute, je pense que le bon vieux filesystem sera toujours le plus performant.

      Ce n'est pas aussi évident que tu sembles le croire. Par exemple une base de données peut très bien (et d'ailleurs le fait dans la plupart des SGBDR) maintenir des statistiques d'accès sur les objets. Ce qui permet une gestion plus intelligente du chache, ou bien de la stratégie d'accès.

      Par exemple, si je (moi le SGBD) sais que le document X dont on me demande les 512 premiers octets a été lu entièrement et séquentiellement dans 90% des cas, je vais faire du read-ahead pour anticiper les demandes suivantes. De même, comme je sais qu'il a été lu séquentiellement dans 90% des cas, et qu'il n'est lu qu'une fois de temps en temps, je ne vais pas encombrer le cache avec.

      A contrario, si je sais que le fichier Y, les blocs en sont généralement lus de manière aléatoire, je ne vais pas faire du read-ahead. Par contre, si je sais que dans 90% des cas le bloc qu'on m'a fait lire, on me le redemande peu de temps après, je vais le mettre dans le cache avec une forte durée de vie...

      Un SGBDR est aussi très avantageux pour tout ce qui est références croisées. Par exemple, sur un FS, si tu veux avoir la liste des liens symboliques qui pointent sur un fichier donné, c'est une coûteuse recherche exhaustive. Alors qu'avec un SGBDR, c'est tout simplement une recherche de clef étrangère...
      • [^] # Re: fs VS db

        Posté par . Évalué à 2.

        Est-ce que les systèmes de fichiers ne font pas la même chose ?

        BeOS le faisait il y a 15 ans !

        • [^] # Re: fs VS db

          Posté par . Évalué à 2.

          Non, aucunes statistiques n'est maintenue sur un FS. Ce n'est tout simplement pas prévu.
          • [^] # Re: fs VS db

            Posté par . Évalué à 3.

            Faut voir. Reiser4, en plus d'avoir un notion objet du fs, permet la mise en place de plugins pour ajouter des foctions au fs, en utilisant entre autre la notion objet. Je pense donc qu'il est possible de rajouter cela, à voir, et si cette volonté d'avoir une db perdure et se répend, un tel plugin sortira.
      • [^] # Re: fs VS db

        Posté par (page perso) . Évalué à 2.

        Par exemple, si je (moi le SGBD) sais que le document X dont on me demande les 512 premiers octets a été lu entièrement et séquentiellement dans 90% des cas, je vais faire du read-ahead pour anticiper les demandes suivantes.

        T'es sur que c'est pas le noyau qui s'occupe de faire le read-ahead et de gerer un cache des fichiers deja ouvert ?
        • [^] # Re: fs VS db

          Posté par . Évalué à 3.

          Dans le cas du filesystem, c'est le noyau qui s'en charge (ou plutôt le module qui gère le FS utilisé), mais dans le cas d'un SGBDR c'est le moteur du SGBD qui s'occupe de cela.

          C'est bien pour ça que pendant longtemps, pour améliorer les perfs d'un SGBDR, au lieu de mettre les bases dans un gros fichier on utilisait des raw devices, c'est à dire des partitions non formattées, sur lesquelles le SGBD écrit directement ses propres données, organisées différemment d'un FS. C'était pour éviter que le noyau ne foute la grouille dans les perfs en faisant du read-ahead inutileou ce genre de choses. Le truc c'était de bypasser l'O/S qui en sait beaucoup moins que le SGBD sur la façon de manipuler les données.

          Depuis, ça se fait moins, parce que les O/S ont des mécanismes qui permettent à un logiciel de dire "t'occupes pas du cache pour ce fichier, c'est moi qui m'en charge".
  • # Moins violent

    Posté par . Évalué à 3.

    Sans aller jusque-là, on pourrait imaginer un système qui déplace l'indexation des fichiers vers une base de données (ce que propose WinFS et consorts, si je ne m'abuse), les fichiers restant sur le disque.

    Une petite couche logicielle (remplaçant les appels systèmes open, opendir, stat et lstat, par exemple) pourrait se charger de l'execution et de la presentation (sous forme de répertoire) des recherches dans la base. Une fois le "bon" fichier trouvé, la base nous donne son path et permet aux outils standards de s'en sortir. L'intérêt étant qu'on peut aisément demander à la couche logicielle en question de ne lancer ce genre d'"usine à gaz" que pour certains répertoires.

    Reste que l'idéal serait quand même un FS spécifique, mounté là ou il faut.
    • [^] # Re: Moins violent

      Posté par . Évalué à 2.

      Est-ce qu'un démon d'indexation ne serait pas tout aussi performant ?

      Avec les bons outils (kio/gnome-vfs/bash adaptés), on pourrait avoir une "vue" BD de ses fichiers et laisser aux applications l'accès arborescent classique pour retrouver les documents.

      Un peu comme ce que faisait BeOS avec ses requêtes dynamiques en fait (que l'on pourrait qualifier d'équivalent des "vues" des SGBDR pour les systèmes de fichier).

      Apparament Freedesktop ne propose rien à ce sujet pour l'instant. J'espère que ça va se faire bientot.

      BeOS le faisait il y a 15 ans !

      • [^] # Re: Moins violent

        Posté par . Évalué à 2.

        Un peu comme ce que faisait BeOS avec ses requêtes dynamiques en fait (que l'on pourrait qualifier d'équivalent des "vues" des SGBDR pour les systèmes de fichier).

        En parlant de ça...

        Il y a quelques temps, des gens (d'une ML gnustep) se posaient la question de l'utilisation des attributs étendus dans les systèmes actuels. C'est vrai que l'usage qu'en faisait BeOS était séduisant: il stockait le type MIME du fichier, l'application préférée, l'icone (en plusieurs résolutions si besoin) et diverses métadonnées liées au type du fichier (tags ID3, ...).

        Seulement, si on veut transposer toutes ces jolies choses dans un système actuel, on se heurte à un problème "balot": BeOS était mono-utilisateur. Ca peut paraître stupide, mais si on applique strictement la même chose que BeOS au niveau du stockage des métadonnées dans les EAs, on fait n'importe quoi: typiquement, on peut vouloir ouvrir un fichier donné prioritairement avec une application différente de celle préférée par le propriétaire du fichier.

        En gros, on peut ranger les attributs en deux catégories: ceux intrisèques au contenu du fichier (type MIME, tags ID3) qui peuvent rester en attributs étendus, et ceux qui sont liés à une vision que l'utilisateur a du fichier (application préférée, icone) qui - dans un système multi-utilisateur - ont tout intérêt à être regroupés dans une structure à part, propre à l'utilisateur.

        C'est dommage, je trouvais ça mignon de stocker l'icone directement dans le fichier :)
        • [^] # Du cote de Gnome

          Posté par . Évalué à 2.

          Merci pour vos commentaires, tres pertinents.

          Je ne suis pas une informaticien a la base, et j'avoue parfois avoir du mal a bien différentier un file systeme d'une base de donnée, surtout quand je lis que beaucoup des idées de reiserFS 4 sont venue suite a l'etude des BD...

          D'ou mon idée candide d'utiliser directement une BD a la place du FS...

          j'ai trouve un lien tres interessant d'un developpeur Gnome parlant de ce sujet, ca se passe ici :
          http://www.gnome.org/~seth/blog/document-indexing(...)

          Maintenant que la transparence de X est en phase de maturation, je pense que l'indexation des fichiers est la prochaine evolution majeure que doit faire les environnements de bureaux.

          Néanmoins le blog si dessus, et les annonces faites autour de kde 4 me font penser que les choses vont bouger de ce cote la...
          • [^] # Re: Du cote de Gnome

            Posté par . Évalué à 3.


            Je ne suis pas une informaticien a la base, et j'avoue parfois avoir du mal a bien différentier un file systeme d'une base de donnée, surtout quand je lis que beaucoup des idées de reiserFS 4 sont venue suite a l'etude des BD...

            D'ou mon idée candide d'utiliser directement une BD a la place du FS...


            Un FS et une BD reposent sur le même principe, c'est vrai. De la même manière qu'un microphone repose sur le même principe qu'un écouteur. Et effectivement on peut faire faire le travail d'un FS à une BD (ce que tu proposes) ou l'inverse (mais ça fournit une BD largement moins riche que ce qui existe aujourd'hui).

            En fait, FS et BD visent le même problème, stocker des données, mais en mettant l'accent sur différents aspects de ce problème. Dans un FS, ce qui importe c'est d'avoir un accès rapide, les fonctionnalités de recherche/classement sont optionelles. On a donc une structure "relativement" simple et uniforme pour tout les fichiers, et un nombre restreint et figé (sauf dans le cas des EAs, dont je parlais plus haut) de "champs" (les attributs, ceux que ls te montre).
            Dans une BD, les performances sont moins primordiales, mais en échange on désire pouvoir utiliser une algèbre sophistiquée (généralement l'algèbre "relationelle") pour faire des manipulations avancées (recherche, sélection de sous-ensembles, fusion de deux données différentes, etc.).

            La différence de design entre les deux tient principalement à un consensus différent en matière d'équilibre fonctionnalités/performances. Certains projets visent à introduire de nouveaux consensus intermédiaires, comme les attributs étendus ou les systèmes d'indexation de fichiers.

            Cependant, il faut bien garder à l'esprit que les premiers essais de filesystem de BeOS étaient de véritables SGBD, mais ont été abandonnés pour cause de performances déplorables (au bénéfice du système actuel, avec un FS "classique" amélioré).

            J'espère pas avoir dit trop de conneries :)
      • [^] # Re: Moins violent

        Posté par (page perso) . Évalué à 2.

        > Est-ce qu'un démon d'indexation ne serait pas tout aussi performant ?

        Un démon basique, surement pas :

        Tu as un /home de 100Go.
        Tu fais un "mv" sur un fichier
        Tu fais une requette.

        Soit ta requette porte sur une base pas à jour, soit le démon à reparcouru tes 100Go de données pour se rendre compte que tu avais fait un "mv".

        Avec un truc dans le filesystem, quand tu fais un "mv", le filesystem met la base à jour, et sait sans tout reparcourir que tu as fait cette action et seulement celle là.
        • [^] # Re: Moins violent

          Posté par . Évalué à 2.

          Oui mais là ce n'est plus un démon basique mais un démon carrément crétin ;)

          Depuis que j'utilise Linux, les déplacements de fichiers sur un même support sont instantanés : Linux se contente de "dire" au système de fichier que le fichier a bougé dans l'arborescence mais physiquement il est à la même place.

          Un démon malin pourrait mettre à jour juste ce qu'il faut de sa base de donnée d'indexation.

          BeOS le faisait il y a 15 ans !

          • [^] # Re: Moins violent

            Posté par (page perso) . Évalué à 2.

            > Depuis que j'utilise Linux, les déplacements de fichiers sur un même support sont instantanés

            Euh, oui, y'a pas que Linux qui fonctionne comme ça, hein ...

            > Un démon malin pourrait mettre à jour juste ce qu'il faut de sa base de donnée d'indexation.

            Ben, problème con: Je te donne un gros disque bien rempli, et la précédante base de donnée.

            Tu fais comment pour savoir ou tu dois mettre à jour sans reparcourir le disque ? (je ne dis pas qu'il faut reconstruire toute la base, mais reparcourir au moins toutes les méta-données du disque, si tu n'as pas l'aide du système de fichiers, je ne vois pas comment tu peux faire). En tous cas, si tu as une solution, donnes-la de toutes urgence aux auteurs de updatedb/locate.
            • [^] # Re: Moins violent

              Posté par . Évalué à 1.

              linux a un système de notification d'évenement. un peu comme un select posé sur un fichier mais je ne crois pas que le "select" en question puisse fonctionner sur tous les fichiers.

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

  • # A la WinFS ?

    Posté par . Évalué à 1.

    http://www.alaide.com/dico.php?q=WinFS(...)
    (A priori WinFS ne sera qu'une surcouche de NTFS, donc dans l'esprit une sorte de BdD sur un Ext3 !)

    La BdD est effectivement très intéressant, par exemple pouvoir associer une photo avec des "contacts" des personnes s'y trouvant, avec les tris indexés par personne, lieu, etc...
    Mais c'est un sacré boulot !
  • # Et ?

    Posté par (page perso) . Évalué à 1.

    La technologie "Spotlight" de Apple (indexation avancée), ça mache comment ?
    Sur sa keynote de 2004 Steve Jobs nous montrait fièrement que le logiciel avait même indexé des textes incrustés dans une image (une carte il me semble)... J'ai pas eu des renseignements plus techniques...
    • [^] # Re: Et ?

      Posté par (page perso) . Évalué à 1.

      dans la Keynote de S. Jobs

      la carte était un fichier pdf, il me semble

      donc je pense que spotlight doit gérer quelques types de fichiers mais pas tout (txt, pdf,doc, xls,...)

      Mais il ne doit pas indexer le contenu des images.
      A la limite les informations (tags) associés à l'image comme l'heure de la prise de vue ou bien le type d'appareil qui a pris la photo...

Suivre le flux des commentaires

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