Sortie d’OpenSearch 3.0 : de fortes avancées pour les performances des bases de données vectorielles et l’infrastructure de recherche alimentée par l’IA

• OpenSearch 3.0 est officiellement disponible et offre des performances 9,5 fois supérieures à celles d’OpenSearch 1.3
• De nombreuses fonctionnalités innovantes pour la recherche vectorielle ont été ajoutées, notamment l’accélération GPU, l’intégration avec des agents IA et l’optimisation du stockage
• Des éléments comme gRPC, le streaming Kafka et l’identification automatique des index renforcent l’efficacité et la flexibilité du traitement des données
• Côté infrastructure de recherche, Lucene 10, Java 21 et une architecture modulaire améliorent l’évolutivité future et la maintenabilité
• La plateforme s’affirme comme une plateforme de recherche open source de nouvelle génération, portée par la communauté, pour répondre à la hausse de la demande autour de l’IA et de la recherche fondée sur le RAG

---

Sortie officielle d’OpenSearch 3.0 : une recherche vectorielle optimisée pour l’ère de l’IA

• L’OpenSearch Software Foundation a dévoilé la version stable d’OpenSearch 3.0 et annoncé des performances 9,5 fois supérieures à celles d’OpenSearch 1.3
• Les performances de traitement de grands volumes de données vectorielles requises pour la recherche IA, les systèmes de recommandation et le RAG ont été améliorées

Innovation du moteur vectoriel : performances et efficacité coût en même temps

• Accélération GPU (basée sur NVIDIA cuVS) : temps de construction des index réduit jusqu’à 9,3 fois, avec prise en charge de charges de travail hautes performances
• Prise en charge du Model Context Protocol (MCP) : permet de concevoir des solutions de recherche flexibles via l’intégration avec des agents IA
• Fonction Derived Source : réduction d’un tiers de l’utilisation du stockage grâce à la suppression des données vectorielles en double

Fonctions de gestion des données : plus de flexibilité et d’évolutivité

• Prise en charge de gRPC : accélération des transferts de données entre nœuds ainsi qu’entre client et serveur (expérimental)
• Collecte de données en mode pull : adoption d’une architecture dans laquelle OpenSearch récupère directement les données depuis des systèmes de streaming externes comme Kafka et Kinesis
• Séparation reader-writer : séparation de la recherche et de l’indexation afin de garantir la stabilité et les performances de chaque tâche
• Intégration d’Apache Calcite : fournit une fonction de constructeur de requêtes intuitif dans SQL/PPL
• Détection du type d’index : identification automatique des index de logs afin de proposer les options d’analyse appropriées

Améliorations de l’infrastructure de recherche et du cœur de la plateforme

• Mise à niveau vers Lucene 10 : amélioration des performances des traitements parallèles et enrichissement des fonctions de recherche
• Java 21 comme runtime minimum pris en charge : permet de tirer parti des fonctions et performances les plus récentes du langage
• Introduction du système de modules Java : passage d’une structure monolithique à une base orientée bibliothèques pour améliorer la maintenabilité

Une innovation durable portée par une communauté open source

• OpenSearch est une plateforme de recherche open source fondée sur une communauté indépendante sous l’égide de la Linux Foundation
• De grandes entreprises comme AWS, SAP et Uber, ainsi que des milliers de contributeurs, y participent
• En mettant en avant l’évolutivité adaptée à l’ère des bases de données vectorielles et une gouvernance transparente, la plateforme vise un écosystème ouvert auquel chacun peut contribuer
• Plus d’informations sur cette version sont disponibles sur le blog officiel et dans les notes de version

[kaydash]

Comme Elasticsearch est sous AGPL, ça me fait un peu peur de l’utiliser, donc je continue à n’utiliser qu’OpenSearch on-premise.

[GN⁺]

Avis sur Hacker News

• Je viens tout juste de découvrir OpenSearch, un projet forké en 2021 après le changement de licence d’Elasticsearch. Je me demande s’il peut toujours être utilisé comme alternative à Elasticsearch, et je suis curieux de connaître la comparaison en termes de performances et de fonctionnalités.

  • Je maintiens un client Kotlin pour Elasticsearch et OpenSearch (kt-search).

    • Pour la plupart des fonctionnalités couramment utilisées, l’API reste compatible.

    • Les fonctionnalités ajoutées après le fork, comme la recherche vectorielle, font exception.

    • Certaines fonctionnalités comme search_after se comportent différemment, et le client compense cela.

    • Les deux produits ont une fonctionnalité de requêtes SQL, mais ils l’implémentent différemment.

    • Côté fonctionnalités, Elastic reste en tête, notamment parce que Kibana est plus riche que le fork d’Amazon.

    • Pour les agrégations aussi, Elastic s’est concentré sur de nombreuses optimisations et améliorations ces dernières années.

    • Les performances dépendent des usages ; les deux produits reposent sur Lucene (bibliothèque open source de recherche).

    • Elastic Cloud est un peu meilleur qu’OpenSearch sur AWS.

    • En auto-hébergement avec un bon tuning, les deux produits deviennent très proches.

    • Elastic 9.0 et OpenSearch 3.0 utilisent tous deux une nouvelle version de Lucene, et le client prend en charge les deux.

    • Parmi mes clients en conseil, de plus en plus préfèrent OpenSearch à cause de la licence open source et du support AWS.

    • Pour migrer d’un ancien Elasticsearch vers OpenSearch, il faut réindexer toutes les données, et il peut aussi être nécessaire de changer de bibliothèque. C’est assez pénible, c’est d’ailleurs pour cela que j’ai créé kt-search.

    • Nous avions beaucoup de bases Elasticsearch 2.3 ; nous avons donc monté OpenSearch en parallèle pour chaque base, puis lancé une copie groupée des données au démarrage du service. Jusqu’ici, nous sommes globalement satisfaits d’OpenSearch.

    • Merci pour l’explication détaillée, c’est très utile.

  • Ce qui m’a récemment manqué dans OpenSearch, c’est la fonctionnalité enrich processors (lien vers la documentation fourni).

    • Si l’on n’utilise que les fonctions standard d’ingestion et de recherche de documents, c’est en grande partie compatible.
    • Les fonctionnalités avancées proposées dans les versions payantes sont souvent incompatibles ou absentes.

  • Elasticsearch a évolué jusqu’à la version 9.0 et au-delà, et compte 27 000 commits de plus qu’OpenSearch.

    • Il est désormais difficile de le considérer comme un « drop-in replacement ».
    • Je ne sais pas combien de ces commits concernent des fonctionnalités clés, mais cela montre à quel point les deux projets ont divergé.

  • Depuis septembre 2024, Elasticsearch est repassé à une licence entièrement open source (AGPLv3).

    • Réaction rappelant qu’on s’est déjà fait avoir par le passé.

    • Elastic Search reste malgré tout un modèle open core ; les fonctionnalités « enterprise » ne seront jamais incluses dans la version open source, alors qu’OpenSearch n’a pas cette contrainte.

  • OpenSearch n’est pas un remplaçant « complet », mais il est presque compatible ; la version 1.x est compatible avec Elasticsearch 7.10.

  • Sur le même matériel, OpenSearch est un peu plus lent. Si vous avez besoin d’une UI, prudence : le fork de Kibana est lent et bogué.

    • En réalité, c’est un peu plus complexe : les deux produits ont des workflows où ils excellent.
    • Notre entreprise a benchmarké les deux de manière approfondie ; si cela vous intéresse, voyez le billet de blog correspondant.

  • Le nom OpenSearch vient à l’origine d’un service d’agrégation de résultats de recherche personnelle développé par A9, une filiale d’Amazon.

    • Le même nom peut parfois avoir plusieurs sens.

• Expression de regret à propos du projet OpenSearch.

  • C’est un projet réactionnel créé avec AWS en réponse au changement de licence d’Elasticsearch.

  • La communauté ressemble à un jeu multijoueur déserté, sans l’énergie vitale indispensable à un projet open source.

  • Je n’ai jamais entendu parler d’une entreprise ou d’un client enterprise ayant remplacé Elasticsearch par lui ; il n’est pas encore éprouvé et inspire peu confiance sur l’engagement à long terme.

  • Chaque plateforme SIEM semble d’ailleurs construire son propre moteur de recherche.

  • Elastic a également lancé sa plateforme SIEM (Elastic Security).

  • Même si Elastic s’est de nouveau déclaré open source, les directions ne dépenseront pas pour migrer vers un fork non éprouvé ; l’objectif même du projet devient flou.

    • Je n’ai pas envie de réutiliser Elastic. J’ai utilisé directement Lucene, puis Solr, puis une version étendue maison ; Elasticsearch ne m’était nécessaire que lorsque j’utilisais AWS. Malgré cela, depuis la migration vers OpenSearch, cela se passe plutôt bien.

    • Je pense qu’Elastic a subi pendant longtemps un impact économique causé par OpenSearch et AWS.

• Je me demande si certains utilisent les fonctionnalités knn et vectorielles d’OpenSearch, et comment cela se comporte en vraie production à grande échelle.

  • Je ne connais pas l’implémentation d’OpenSearch, mais j’ai déjà implémenté moi-même un ensemble vectoriel pour Redis avec une structure HNSW.

    • Si HNSW est bien implémenté, cela fonctionne très bien même à une échelle importante.
    • La vitesse d’insertion dans un HNSW unique est de l’ordre de quelques milliers d’éléments par seconde ; la lecture est bien plus rapide (en environnement multicœur).
    • Les premières insertions en masse peuvent être très lentes, mais cela se parallélise.
    • Le point faible de HNSW est sa forte consommation mémoire ; si l’on stocke sur disque, cela provoque des accès aléatoires.
    • Pour des vecteurs de grande dimension, comme 1024 dimensions, la quantization est indispensable.

  • Lorsque la dimension des embeddings vectoriels est élevée, je recommande plutôt une recherche de plus proches voisins approximatifs comme HNSW que le knn lui-même.

    • De mon côté, j’utilise opensearch pour de la recherche hybride basée sur du texte, des embeddings multimodaux et des métadonnées.
    • Ce n’est pas encore un déploiement totalement à grande échelle, mais comme c’est opensearch, j’ai de bonnes attentes sur sa scalabilité.

  • Dans mon expérience, je m’en sers en permanence ; les performances dépendent du modèle d’embedding, et le tuning de l’index est essentiel.

    • Avec Lucene HNSW, cela consomme beaucoup de RAM de heap Java.
    • Si l’on utilise les plugins FAISS ou nmslib, il faut aussi surveiller la RAM JNI.
    • Faire évoluer facilement un ANN massif au-delà de 100 millions de vecteurs n’a rien de simple ; cela demande une forte implication de l’équipe.

  • Il y a un caveat généralement admis : les performances de recherche restent bonnes sur plusieurs millions de documents, mais pour la recherche KNN il faut charger en RAM l’ensemble du graphe d’embeddings ; la gestion de la mémoire est donc le point clé.

    • La qualité des résultats dépend au final de la qualité des embeddings.

• Je voulais un outil simple d’ingestion de logs capable de parser du syslog et de faire des graphes/recherches sur les champs, mais configurer Opensearch ou ELK était beaucoup trop compliqué.

  • J’ai été surpris de voir qu’Elastic comme Opensearch rendent difficiles même ces réglages de base.

    • Tout est centré sur la configuration, il faut donc construire soi-même ses recettes.

    • Il existe des outils utiles comme opentelemetry, mais cela reste peu pratique.

    • Si l’on suit simplement les guides officiels, les deux outils peuvent être utilisés rapidement ; le problème commence quand on a besoin de logique personnalisée.

    • Pour des besoins simples, on peut s’en sortir sans logstash.

    • Elastic et opensearch ne sont pas adaptés aux métriques applicatives ; dans ce cas, mieux vaut prometheus et grafana.

    • Si l’on investit dans l’écosystème Elastic (beats, logstash, etc.), on peut configurer divers templates d’index et pipelines.

    • Aujourd’hui, grâce au dynamic field mapping, il est devenu très simple d’envoyer et de récupérer des données dans Elasticsearch.

    • Le vrai souci, c’est plutôt de maintenir les performances.

  • Avez-vous essayé Graylog ? Dans mon entreprise, on l’utilise de façon assez satisfaisante.

[davidayo]

OpenSearch a émergé en 2021 à la suite du changement de licence d'Elasticsearch, avec pour objectif d'être un remplaçant compatible. Bien qu'il soit largement compatible, en particulier la version 1.x avec Elasticsearch 7.10, ce n'est pas une solution entièrement interchangeable. Elasticsearch a continué d'évoluer, avec davantage de fonctionnalités et d'optimisations, notamment dans Kibana et les agrégations. Les performances dépendent des applications, les deux étant construits sur Lucene. Certains utilisateurs estiment qu'OpenSearch est plus lent et que ses forks de Kibana comportent des bugs. Malgré le retour d'Elasticsearch à l'open source (AGPLv3) en septembre 2024, certains préfèrent OpenSearch pour son caractère véritablement open source et le support d'AWS. Bien que la recherche vectorielle soit un différenciateur clé, les implémentations à grande échelle nécessitent une gestion attentive de la RAM. En fin de compte, le choix dépend des besoins spécifiques, les deux ayant leurs forces et leurs faiblesses. Je travaille sur OpenSearch avec Davidayo https://www.davidayo.com, un puissant outil d'IA, "AskPromptAI" https://askpromptai.com.