Quel type de base de données utilise `updatedb` et` Locate`?


25

Le locateprogramme findutilsscanne une ou plusieurs bases de données de noms de fichiers et affiche toutes les correspondances. Cela peut être utilisé comme une findcommande très rapide si le fichier était présent lors de la dernière mise à jour de la base de données de noms de fichiers.

Il existe de nombreux types de bases de données de nos jours,

Alors, quel type de base de données est mis à updatedbjour et locateutilisé?

Merci.


Indépendamment du fait que la localisation utilise réellement BerkelyDB, cela vaut la peine d'être étudié - il s'agit d'un magasin de valeurs-clés sur disque très ancien, simple et efficace.
pjc50

@ pjc50 j'adorerais. Où sont les fichiers de la base de données? Comment consulter leur contenu?
Tim


"Page non trouvée", le lien doit être serverfault.com/questions/454127/…
Tim

Que représentent donc les "clés" et les "valeurs" dans la base de données? Si je comprends bien le commentaire de Stephen Kitt unix.stackexchange.com/questions/379725/… , la base de données n'est pas une valeur-clé.
Tim

Réponses:


29

Les implémentations de locate/ updatedbutilisent généralement des bases de données spécifiques adaptées à leurs besoins, plutôt qu'un moteur de base de données générique. Vous trouverez ces bases de données spécifiques documentées par chaque implémentation; par exemple:

  • GNU findutils'est documenté dans locatedb(5), et est à peu près juste une liste de fichiers (avec un algorithme de compression spécifique);
  • mlocateest documenté dans mlocate.db(5), et peut également être considéré comme une liste de répertoires et de fichiers (avec métadonnées).

Merci. Où et comment puis-je apprendre les principes de conception et de mise en œuvre de bases de données spécifiques adaptées aux besoins spécifiques? J'apprécierais toutes les références pour la lecture.
Tim

11
La conception de bases de données se résume à la conception de structures de données, alors renseignez-vous sur celles-ci, puis sur les compromis de conception taille / vitesse ... Je ne connais pas de ressource spécifique qui serait bonne, peut-être quelque chose comme Programming Pearls serait une belle introduction à la façon de penser sur ces sujets (et non pas de trop les penser).
Stephen Kitt

Merci. J'ai appris quelque chose sur les structures de données, et la question suivante serait de trouver des références et des moyens de passer des structures de données aux bases de données.
Tim

2
Les bases de données utilisées par ne locatesont que des structures de données stockées sur le disque, il est donc relativement simple de passer des structures de données aux bases de données correspondantes. Passer aux bases de données au fur et à mesure que votre question les présente est une tout autre chose; il existe des livres et des cours consacrés à ces sujets. Concevoir et développer un système de gestion de base de données tel que MongoDB ou PostgreSQL est l'un des problèmes les plus difficiles en informatique et en génie logiciel aujourd'hui, en particulier lorsque vous mettez le côté distribué des choses.
Stephen Kitt

2
j'ai fait pas mal avec locatedb & mlocate.db au fil des ans. Au départ, j'avais du code perl pour générer un locatedb pour mon dlocateprogramme dans debian. J'ai fini par découvrir que le simple fait d'appréhender un fichier texte était beaucoup plus rapide que de rechercher un localiséb, et étant donné la taille des disques de nos jours, les économies de taille de fichier étaient insignifiantes. Je suis donc passé à juste grep. J'ai également un travail cron local qui transfère mlocate.db en texte brut après l'exécution du travail cron mlocate, que je recherche avec un qlocatescript shell local .... beaucoup plus rapide que l'exécution mlocateet a également quelques options supplémentaires utiles.
cas

13

Semble être un fichier plat de structures C, écrit / lu à l'aide des macros Gnu LibC OBSTACKS

Voir les sources

https://github.com/msekletar/mlocate/blob/master/src/updatedb.c#L720

https://github.com/msekletar/mlocate/blob/master/src/locate.c#L413

Vous pourriez obtenir quelque chose de similaire avec

find / -xdev -type f -not -path \*\.git\/\* | gzip -9 > /tmp/files.gz
zgrep file_i_want /tmp/files.gz

2
Merci. Que font les deux commandes à la fin?
Tim

2
La commande @Tim First recherche le système de fichiers ( find) à partir du /répertoire racine ( ), sans descendre dans les répertoires des autres systèmes de fichiers ( -xdev), les fichiers normaux ( -type f), pas dans les *.gitrépertoires ( -not -path \*\.git\/\*). Il compresse output ( | gzip -9) et l'enregistre dans file /tmp/files.gz( > /tmp/files.gz). La ligne suivante recherche un zgrepfichier file_i_wantdans un fichier compressé/tmp/files.gz
piotrekkr

2

Pour autant que je sache, Berkeley DB est une base de données sans démon clé / valeur. Suivez le lien pour plus d'informations. Extrait de Wikipedia:

Berkeley DB (BDB) est une bibliothèque de logiciels destinée à fournir une base de données intégrée hautes performances pour les données clés / valeurs. Berkeley DB est écrit en C avec des liaisons API pour C ++, C #, Java, Perl, PHP, Python, Ruby, Smalltalk, Tcl et de nombreux autres langages de programmation. BDB stocke des paires clé / données arbitraires sous forme de tableaux d'octets et prend en charge plusieurs éléments de données pour une seule clé. Berkeley DB n'est pas une base de données relationnelle.

L'emplacement de la base de données dans RHEL / CentOS est /var/lib/mlocate/mlocate.db(pas sûr des autres distributions). La commande locate --statisticsvous donnera des informations sur l'emplacement et quelques statistiques de base de données (exemple):

Database /var/lib/mlocate/mlocate.db:
        16,375 directories
        242,457 files
        11,280,301 bytes in file names
        4,526,116 bytes used to store database

Pour le format mlocate, voici la tête de la page de manuel:

Une base de données mlocate commence par un en-tête de fichier: 8 octets pour un nombre magique ("\ 0molocate" comme un littéral C), 4 octets pour la taille du bloc de configuration en big endian, 1 octet pour la version de format de fichier (0), 1 octet pour l'indicateur «nécessitent une visibilité» (0 ou 1), remplissage de 2 octets et un nom de chemin terminé par NUL de la racine de la base de données.

L'en-tête est suivi d'un bloc de configuration, inclus pour garantir que les bases de données ne sont pas réutilisées si certaines modifications de configuration peuvent affecter leur contenu. La taille du bloc de configuration en octets est stockée dans l'en-tête du fichier. Le bloc de configuration est une séquence d'affectations de variables, ordonnée par nom de variable. Chaque affectation de variable se compose d'un nom de variable terminé par NUL et d'une liste ordonnée de valeurs terminées par NUL. La liste de valeurs se termine par un caractère NUL de plus. L'ordre utilisé est défini par la fonction strcmp ().


2
Cela dépend de la mise en œuvre de locate/ updatedb...
Stephen Kitt

2
mlocaten'utilise certainement pas Berkeley DB.
Stephen Kitt

1
Avez-vous une source soutenant votre réclamation BerkeleyDB? La deuxième partie de votre réponse la contredit.
Mat
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.