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...
Journal Une base de données pour /home ?
27
oct.
2004
# fs VS db
Posté par john Smith (site web personnel) . Évalué à 3.
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 peau chat . Évalué à 3.
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 dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: fs VS db
Posté par peau chat . Évalué à 2.
[^] # Re: fs VS db
Posté par blackshack . Évalué à 3.
[^] # Re: fs VS db
Posté par chl (site web personnel) . Évalué à 2.
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 peau chat . Évalué à 3.
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 Larry Cow . Évalué à 3.
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 dinomasque . Évalué à 2.
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 20 ans !
[^] # Re: Moins violent
Posté par Larry Cow . Évalué à 2.
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 godflesh . Évalué à 2.
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 Larry Cow . Évalué à 3.
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 Matthieu Moy (site web personnel) . Évalué à 2.
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 dinomasque . Évalué à 2.
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 20 ans !
[^] # Re: Moins violent
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# A la WinFS ?
Posté par Anthony F. . Évalué à 1.
(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 Adrien BUSTANY (site web personnel) . Évalué à 1.
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 john Smith (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.