Une explication technique du moteur de recherche de code de Github.

Avec 155 To de données et plus de 15 milliards de documents, ils ont développé une solution maison de l'ingestion jusqu'au moteur de recherche.

Le moteur de recherche est basé sur des ngrams (trigramme à priori)

De la recherche vectorielle sur des fichiers audio avec Elasticsearch et librosa

Une vidéo très intéressante sur le déclin de l'hégémonie de Google.

Cela s'explique notamment par une part de plus en plus importante des recherches Instagram / TikTok qui proposent des résultats plus interactifs (images, vidéos)

Aussi le SEO à une grosse part de responsabilité dans la merdification des résultats avec des articles de plus en plus vides écrits par des IA dans le seul but de placer des mots-clés.

Finalement, on note la montée en puissance de Reddit pour du contenu certifié "User generated" et des réponses de qualité

Un moteur de connaissance backé par un LLM (surement OpenAI) mais qui en plus cite les sources.

Très utile pour débroussailler des sujets de dev lorsqu'on est en phase de recherche / prototypage et qu'on a besoin de comprendre des technos

Une histoire d'optimisation d'un cluster Elasticsearch.

Le problème chez Netflix venait d'une mauvaise allocation des shards des indices, tous les indices avaient le même nombre de shards et donc certains noeuds se retrouvent à héberger des shards contenant des millions de documents.

Leur stratégie a été de distribuer les documents non pas par type mais par date de création (time buckets) en utilisant des index template pour la création automatique et des alias pour la recherche (comme pour l'ingestion des logs donc).

Un article plus posé sur l'éventuel remplacement des moteurs de recherche par des LLM.

Il faut considéré les problèmes de biais induit par les données sur lesquels les modèles sont entrainés mais il faut surtout prendre en compte le coût d'entrainement et de génération d'une réponse.

Pour avoir un modèle à jour, il faut constamment l'entrainer et ça coûte très cher.
Pareil pour une réponse qui coûte beaucoup plus cher à générer (Google traite ~10 000 requêtes/sec)

A priori, les LLM vont surtout être utilisé pour répondre à des sujets précis. Par exemple, entrainer un LLM sur toutes les publications relatives au cancer des 20 dernières années.

Très bonne explication des différences entre Nested fields et Object fields pour stocker des tableaux d'objets avec Elasticsearch.

Si on souhaite faire des recherches sur plusieurs propriétés contenues dans ces tableaux, alors on devra utiliser le type nested car sinon ES "applatit" les champs.

{
  "authors": [
    { "name": "Gustavo Llermaly", "age": "32", "country": "Chile" },
    { "name": "John Doe", "age": "20", "country": "USA" }
  ]
}

Sans préciser le type nested, cela sera indexé de cette manière:

{
  "authors.name": ["Gustavo Llermaly", "John Doe"],
  "authors.age": [32, 20],
  "authors.country": ["Chile, USA"]
}

Un très bonne comparaison entre les performances de recherches d'Elasticsearch et MongoDB et le résultat est sans appels.

Sur la recherche, Elasticsearch est jusqu'à 20x plus rapide que MongoDB.

Sur les aggrégations, Elasticsearch est jusqu'à 38x plus rapide que MongoDB.

Sur l'insertion, MongoDB est 1.20x plus rapide que Elasticsearch.

Sur le parcours des données, Elasticsearch offre des performances stables quand MongoDB passe de 5 à 60 sec pour récupérer les derniers documents d'une collection.

Sur l'espace disque, MongoDB occupait 2x plus d'espace avec les mêmes données. (sans index!)

Ces benchmarks ont été effectués sur de grosses collections (dizaines de millions) mais les différences performances se font aussi sentir sur de plus petites collections.

Les performances seules ne doivent pas guider le choix mais aussi les features, par exemple les limitations d'Elasticsearch sont les suivantes:

• Near Realtime Search: les documents ne sont pas disponible immédiatement dans le search après écriture
• Pas de modification possible du type d'un champs d'une collection (int vers string par exemple)
• Pas de transactions
• Pas de pseudo-relationnel comme en MongoDB

On parle souvent des comparaisons entre SQL et NoSQL mais cet article va plus loin en comparant les usages des 5 grandes familles de "Data Store"

• Base de données relationnelles (e.g. PostgreSQL)
• Base de données non-relationnelles (e.g. MongoDB)
• Base de données clé/valeur (e.g. Redis)
• Moteur de recherche (e.g. Elasticsearch)
• File de messages (e.g. Kafka)

Une alternative à ES qui est un fork de Sphinx Search.

A priori ils proposent de meilleurs performances à la recherche et à l'indexation que Elasticsearch en plus de supporter une syntax SQL.

PRO:

• meilleurs perfs de recherche et d'insertion
• support SQL (syntax et clients existants)
• 100% open source (GPLv2 + Apache 2)
• recherche temps-réel (max 1sec avec ES)

CON:

• obligé de définir le schéma à l'avance
• moins de ressources dispo car moins populaire
• robustesse du scaling à prouver
• pas complètement intégré avec les autres outils de la suite Elastic

Si vous avez besoin d'ajouter un moteur de recherche et que vous n'avez ni besoin de fonctionnalités très avancé, ni de scale à plusieurs centaines de millions de documents alors c'est une alternative à creuser.