Il y a 11 ans, je commençais ma carrière professionnelle en ingénierie de logiciels avec le but de faire mieux que Google.
J’étais n’y au courant des usages, même si satisfait de MySQL (https://aneglus.free.fr), le gout pour l’aventure m’a amené à tester différent logiciel expert en donnée durable. J’ai programmé pour dans l’ordre MySQL, PostgreSQL, zodb, Neo4J (hypermove.net), MongoDB (Flask-Andalucia), Oracle Berkeley DB, feu sleepycat database et bsddb, wiredtiger (guile-babelia), j’ai aussi commencé un Doctorat en autonomie chez Wikimedia.
NLnet m’a fait une donation suite à mon travail sur l’implémentation de démonstration de la nouvelle version de mon moteur de recherche. Cette fois-ci, le moteur de recherche a été écrit en Python avec FoundationDB, même si ce n’est pas aussi bien que ce que j’avais imaginé, j’ai quand même exploré et documenter le sujet :
- https://hyper.dev/blog/2020/do-it-yourself-a-search-engine/
- https://hyper.dev/blog/2021/nlnet-supports-babelia/
- https://hyper.dev/blog/2021/babelia-search-engine-design-planning/
- https://hyper.dev/blog/2021/raxes/
La page principale du projet est chez sourcehut lien direct vers la section décrivant la précédente feuille de route.
- Lien vers une démo : https://babelia.one/
À la différence de https://search.marginalia.nu/, la Babelia (2022) fait seulement la recherche dans son propre index (il n’y a pas de wiki en support du moteur de recherche), l’avantage de Babelia, c’est que garantir le stockage cohérent et perenne est déléguée à FoundationDB. Plutôt que Java, sur ce projet, j’ai choisi CPython.
Les différences avec le projet Rust sur GitHub qui s’appelle tantivy/quickwit
, c’est encore une fois FoundationDB, et FoundationDB seulement qui permet de monter à l’échelle, c’est-à-dire connaitre / stocker plus de documents. Je n’ai pas lu le code, donc je ne sais pas quel algorithme il utilise pour répondre aux utilisateurs.
L’algorithme de Babelia est décrit dans ce sujet dans le forum de l’association francophone python.
[à suivre…]