Alibaba Cloud Elasticsearch Agent Engine Edition est un moteur de recherche cloud-native conçu pour la génération augmentée par récupération (RAG), le codage assisté par IA, la mémoire des agents et les scénarios de recherche multi-locataires. Il expose une Collection comme point d'accès unifié et organise différents espaces métier, tels que les bases de connaissances, les dépôts de code, les agents et les locataires, sous forme de Slices.
Pourquoi l'utiliser : défis de la recherche multi-espaces métier
Les applications de RAG, de codage assisté par IA, de mémoire d'agent et de recherche multi-locataires doivent généralement héberger de nombreuses bases de connaissances, dépôts de code, espaces de mémoire ou espaces de données locataires indépendants au sein d'un seul système de recherche. Ces charges de travail partagent les défis suivants :
Coexistence de nombreux espaces métier — Les modèles d'accès diffèrent considérablement d'un espace à l'autre. Certains restent continuellement actifs, tandis que d'autres sont rarement consultés pendant de longues périodes. Le maintien d'un index distinct pour chaque espace rend la gestion et la planification de la capacité de plus en plus complexes à mesure que votre activité se développe.
Distribution inégale des données chaudes/froides — Un grand nombre d'espaces rarement accédés occupent des ressources de calcul et de stockage sur de longues périodes, alors que les espaces actifs nécessitent des réponses stables à faible latence. Les architectures traditionnelles peinent à équilibrer coût et performance.
Pics de lecture/écriture divergents — L'ingestion de données et les requêtes connaissent chacune leurs propres pics et creux. Lorsque les écritures, la construction d'index et les requêtes partagent le même ensemble de nœuds, les pics d'écriture impactent directement la latence des requêtes. Pour relever ces défis, Agent Engine Edition découple le stockage persistant, le calcul d'écriture et le calcul de requête. Les données d'index et l'état persistant sont stockés dans le stockage d'objets, et des types de nœuds distincts gèrent les écritures et les requêtes. Pour connaître le rôle de chaque composant, consultez la section Architecture principale de cette rubrique.
Sur la page d'achat de la console et dans la liste des instances, les deux types de nœuds sont affichés sous les noms Index Nodes et Query Nodes, qui correspondent respectivement aux nœuds d'index et aux nœuds de recherche mentionnés dans cette rubrique.
Ce qu'il résout : avantages principaux et scénarios
Séparation lecture/écriture avec mise à l'échelle indépendante
Agent Engine Edition exécute les écritures et les requêtes sur des rôles de nœud différents. Configurez les nœuds d'index en fonction de votre volume d'ingestion de données, et configurez les nœuds de recherche en fonction de la concurrence de vos requêtes. Lorsqu'un type de charge de travail augmente, ajustez uniquement les ressources correspondantes, ce qui réduit considérablement la contention entre les écritures, la fusion d'index et les requêtes pour les mêmes ressources de calcul. Les pics d'écriture sont largement isolés de la latence des requêtes, et vice versa.
Mise en cache à la demande avec tiering automatique chaud/froid
L'intégralité des données d'index est stockée dans le stockage d'objets, et les disques locaux des nœuds de recherche servent de cache de requête. Les données fréquemment consultées sont réutilisées en continu depuis le cache, permettant aux requêtes chaudes de répondre en quelques millisecondes. Les données rarement consultées ne sont chargées depuis le stockage d'objets qu'en cas de besoin. Dimensionnez le cache local autour de l'ensemble de travail actif ; il n'a pas besoin de correspondre au volume total de données. Les espaces métier inactifs ne consomment aucune ressource de calcul ou de cache, et leur coût de stockage se limite aux frais de paiement à l'utilisation du stockage d'objets.
Les avantages du cache dépendent de la distribution chaud/froid de votre charge de travail, de la capacité du cache, des spécifications des nœuds et de la concurrence des requêtes. Pour les charges de travail dont les modèles d'accès sont très dispersés ou changent fréquemment, effectuez une évaluation de la capacité et des tests de performance avec vos données réelles.
Des centaines de millions d'espaces métier sous gestion unifiée
Agent Engine Edition est conçu pour prendre en charge des centaines de millions d'espaces métier sous gestion unifiée au sein d'une seule Collection. Une application peut traiter chaque base de connaissances, dépôt de code, agent ou locataire comme un Slice et effectuer à la fois des lectures et des écritures via la même Collection. La plateforme gère les index et les shards sous-jacents en fonction de la capacité, de sorte que les applications n'ont pas besoin de créer un index distinct pour chaque espace métier ni de maintenir les noms d'index sous-jacents ou les schémas de table dans le code de l'application. Le test de performance décrit dans la section Référence de performance de cette rubrique couvre 10 000 espaces métier.
Au moment de la requête, vous pouvez sélectionner un Slice, plusieurs Slices ou explicitement tous les Slices. L'étendue de la requête doit être spécifiée explicitement par défaut. Pour le comportement de requête par défaut, consultez la section Comment les données sont interrogées dans cette rubrique.
Récupération après incident en quelques secondes sans migration de données
Les données d'index, les journaux d'écriture et l'état du cluster sont stockés dans le stockage d'objets, et les nœuds de calcul ne conservent aucun état persistant local. Après une défaillance de nœud, la plateforme planifie rapidement un nœud de remplacement qui reprend les opérations à partir du stockage d'objets et reconstruit le cache local à la demande, sans nécessiter de migration complète des données. La récupération des shards dans les architectures stateful traditionnelles prend de dizaines de minutes à plusieurs heures, donc cette conception réduit l'ampleur de l'impact d'une défaillance.
Si la couche d'écriture ne peut temporairement pas héberger le shard principal (servant aux écritures), les nouvelles écritures sont suspendues. Tant que le shard de recherche (servant aux requêtes) correspondant reste disponible, le système peut continuer à servir les requêtes sur les données déjà persistées et publiées.
Compatibilité avec l'écosystème Elasticsearch
Dans le périmètre des API prises en charge, les applications peuvent continuer à utiliser l'API REST Elasticsearch et le langage DSL de requête, et combiner les capacités d'indexation en texte intégral, de recherche vectorielle KNN, de filtrage et d'agrégation. Les clients officiels Python, Java, Go et JavaScript, Kibana et d'autres composants de l'écosystème peuvent réutiliser la structure de requête et la syntaxe des interfaces compatibles, ce qui réduit les modifications au niveau de l'interface. Avant la migration, vérifiez les interfaces et les composants de l'écosystème que vous utilisez par rapport à la documentation de compatibilité pour la version de votre instance.
Index vectoriel natif disque (DiskBBQ)
Agent Engine Edition utilise l'index vectoriel natif disque DiskBBQ, qui offre des requêtes KNN à E/S prévisibles grâce au clustering hiérarchique K-means combiné à la quantification BBQ. Au moment de la requête, DiskBBQ sonde au plus deux niveaux de centroïdes et lit les clusters ciblés dans un ordre séquentiel par blocs, ce qui le rend bien adapté à la mise en cache SSD et au stockage d'objets sans exiger que les vecteurs résident en mémoire. Par rapport à HNSW, DiskBBQ améliore la vitesse de construction d'index d'environ un ordre de grandeur, et les performances se dégradent progressivement plutôt que brutalement lorsque la mémoire est contrainte. Les résultats de test dans la section Référence de performance de cette rubrique couvrent uniquement la latence des requêtes, pas la vitesse de construction d'index ; vérifiez les performances de construction avec votre propre charge de travail avant de faire un choix. Pour la configuration des champs, les paramètres de requête KNN et des exemples complets, consultez Récupération vectorielle DiskBBQ et Sliced DiskBBQ.
Scénarios
Le tableau suivant décrit les scénarios typiques pour Agent Engine Edition et l'organisation des données recommandée pour chaque scénario :
| Scénario | Organisation des données recommandée | Valeur principale |
| Base de connaissances entreprise et RAG | Traitez chaque base de connaissances comme un Slice | Une seule Collection gère un très grand nombre de bases de connaissances. Les bases actives répondent en millisecondes, et les bases dormantes n'engendrent que des frais de stockage d'objets. |
| Codage assisté par IA et recherche de code | Traitez chaque dépôt de code ou projet comme un Slice | Le code devient interrogeable en quelques secondes après le commit. Les recherches en temps réel des développeurs sont largement unaffected par les écritures par lots. |
| Mémoire d'agent | Partitionnez les Slices par locataire, agent ou espace de mémoire indépendant | Les écritures sont immédiatement interrogeables. Les mémoires dormantes d'un grand nombre d'agents ne consomment aucune ressource de calcul ou de cache. |
| Service de recherche multi-locataire | Traitez chaque locataire ou espace métier comme un Slice | La plateforme gère les index sous-jacents, et les données sont physiquement regroupées par locataire. Le coût de requête d'un seul locataire dépend uniquement du volume de données de ce locataire. |
Composition : concepts clés et architecture
Concepts clés
Pour comprendre Agent Engine Edition, distinguez d'abord Collection de Slice :
| Concept | Description |
| Collection | Point d'entrée unifié pour que les applications accèdent aux données. Vous l'utilisez de la même manière qu'un nom d'index Elasticsearch. Une Collection peut contenir plusieurs espaces métier. |
| Slice | Espace de données logique au sein d'une Collection. Par exemple, une base de connaissances, un dépôt de code, un agent ou un locataire peut chacun constituer un Slice. |
Lors de la lecture et de l'écriture des données, les applications utilisent le nom de la Collection pour accéder aux données et spécifient l'espace métier correspondant via un Slice. La plateforme achemine les requêtes vers les données correspondant au Slice et gère les index et shards sous-jacents. Les applications n'ont pas besoin de stocker ni d'opérer directement sur les noms d'index sous-jacents.
Les Slices organisent les données et délimitent les requêtes. Ils ne sont pas équivalents aux limites d'autorisation de compte. Si vous avez besoin d'une authentification d'identité et d'une isolation des autorisations entre locataires, concevez votre solution en combinant l'authentification au niveau de l'application avec les mécanismes de sécurité pris en charge par le produit.
Architecture principale
L'architecture principale d'Agent Engine Edition repose sur trois idées : les données persistantes sont stockées uniformément dans le stockage d'objets, les écritures et les requêtes sont gérées par différents types de nœuds qui évoluent indépendamment, et plusieurs espaces métier sont organisés via des Collections et des Slices. Les données de requête entrent dans le cache local à la demande.
Les responsabilités de chaque composant sont les suivantes :
| Composant | Responsabilités principales |
| Collection et Slice | La Collection sert de point d'entrée d'accès aux données. Le Slice identifie un espace métier au sein de la Collection, et la plateforme l'utilise pour localiser les données correspondant à une requête. |
| Nœud d'index | Gère les écritures de documents, la persistance des journaux d'écriture, la construction d'index et la fusion en arrière-plan. |
| Nœud de recherche | Exécute les requêtes en texte intégral, vectorielles, de filtrage et d'agrégation, et met en cache localement les données requises par les requêtes. |
| Stockage d'objets | Stocke les données d'index, les journaux d'écriture et l'état persistant requis pour le fonctionnement du cluster. La durabilité des données est de 11 neuf ou plus. La facturation est basée sur le stockage réellement utilisé, sans capacité à pré-provisionner. Sur la page des détails de l'instance de la console, cette capacité est affichée sous les noms OpenStore Storage et OpenStore Storage Usage. |
Comment les données sont écrites
Lors de l'écriture des données, les applications utilisent le nom de la Collection dans l'URI de la requête et identifient l'espace métier auquel appartiennent les données via un Slice.
Les nœuds d'index traitent la requête. Le système confirme l'achèvement de l'écriture au client uniquement après que le journal d'écriture (Translog) a été persisté de manière synchrone dans le stockage d'objets.
Les nœuds d'index génèrent des fichiers d'index en arrière-plan et publient une nouvelle version d'index (Commit). Après l'actualisation des nœuds de recherche, les nouvelles données entrent dans les résultats de requête selon la sémantique quasi temps réel d'Elasticsearch.
Comment les données sont interrogées
Lors de l'interrogation des données, les applications utilisent le nom de la Collection dans l'URI de la requête et spécifient un ou plusieurs espaces métier via des Slices. Par défaut, les requêtes qui ne spécifient pas de Slice sont rejetées, ce qui réduit le risque d'interroger involontairement l'intégralité de la Collection lorsque les informations de routage sont manquantes.
Les nœuds de recherche lisent d'abord les données requises par la requête depuis le cache partagé local.
En cas d'échec du cache, les nœuds de recherche chargent la plage de données requise par la requête actuelle depuis le stockage d'objets. Les requêtes suivantes continuent de réutiliser les données chaudes déjà entrées dans le cache. Pour maintenir la disponibilité des requêtes lors des défaillances de nœuds, consultez Architecture stateless et planification des ressources afin de configurer le nombre de réplicas et de nœuds de recherche.
Référence de performance
Les résultats suivants proviennent d'un test effectué en juillet 2026 dans un scénario d'application typique, et ils montrent les performances des requêtes froides et chaudes dans ces conditions de test. Les résultats du test ne constituent pas un SLA de produit, un engagement de spécification d'instance ou des conclusions générales de performance pour d'autres environnements.
| Élément de test | Configuration |
| Environnement de test | Alibaba Cloud Elasticsearch Agent Engine Edition, 2 nœuds d'index et 2 nœuds de recherche, chacun avec 16 vCPU et 64 GiB de mémoire |
| Échelle des données | 10 000 espaces métier, 93,68 millions de documents au total et 2,8 TB de données |
| Configuration vectorielle | Vecteurs de 512 dimensions, similarité dot_product et index bbq_disk (DiskBBQ) |
| Méthode de requête | Requête KNN renvoyant 10 résultats, avec un ensemble candidat de 100 |
| Métrique de latence | Temps de traitement côté serveur took. Le traitement côté client et la latence réseau ne sont pas inclus. |
| État d'accès | Nombre d'échantillons | P50 (médiane) | P90 | P99 |
| Requête froide | 180 | 225 ms | 377 ms | 605 ms |
| Requête chaude | 1 800 | 1 ms | 32 ms | 65 ms |
Les données précédentes ont été obtenues avec des nœuds d'index et de recherche de 16 vCPU et 64 GiB. Les spécifications des nœuds, le nombre minimal de nœuds et la configuration des nœuds maîtres dédiés sont soumis aux options actuellement disponibles sur la page d'achat. La latence du tableau précédent ne peut pas être reproduite avec des configurations inférieures aux spécifications de test, donc ne vous attendez pas à des performances équivalentes avec la spécification minimale. Les performances réelles des requêtes sont également affectées par le volume de données d'un seul Slice, les dimensions des vecteurs, les paramètres de rappel, les spécifications des nœuds, la capacité du cache, la charge concurrente et les conditions réseau. Avant de faire un choix formel, effectuez une évaluation de la capacité et des tests de stress avec vos données et requêtes métier réelles.
Version et compatibilité
Agent Engine Edition utilise des numéros de version au format 9.99.x. 9.99 indique que le produit appartient à la série compatible Elasticsearch 9.x, et le dernier segment de version différencie les itérations de fonctionnalités d'Agent Engine Edition lui-même. Ce numéro de version ne correspond pas un à un avec des versions mineures spécifiques d'Elasticsearch 9.x, et il n'implique pas la prise en charge de chaque fonctionnalité et API d'Elasticsearch 9.x.
Les fonctionnalités et API prises en charge peuvent varier selon les versions 9.99.x. Avant de créer une instance ou de migrer des charges de travail, consultez la documentation de compatibilité des API pour la version d'instance affichée sur la console afin de confirmer la prise en charge de l'accès aux données, de l'étendue des requêtes, de la recherche vectorielle, de la réplication des données et des capacités de sécurité.
La version actuelle d'Agent Engine Edition 9.99.0 correspond à la version du noyau Elasticsearch 9.5.0, donc le numéro de version renvoyé par l'API du cluster diffère du numéro de version affiché sur la console. Pour la version réelle du noyau Elasticsearch, la réponse de l'API du cluster fait autorité. Lorsque vous installez des plugins personnalisés, utilisez le numéro de version 9.99.0 qui correspond à Agent Engine Edition.
Régions et zones
Les régions et zones prises en charge par Agent Engine Edition sont soumises aux éléments réellement disponibles à l'achat sur la page d'achat. Les spécifications d'instance, les méthodes de facturation et la disponibilité sont soumises au site Web officiel d'Alibaba Cloud, à la console et aux annonces de publication officielles. Avant une migration formelle, effectuez une évaluation de la solution et une vérification des performances basées sur la compatibilité des API, l'échelle des données, la distribution chaud/froid et la charge de requête cible.
Étapes suivantes : comment commencer
Suivez ces étapes pour commencer avec les instances Agent Engine Edition :
Confirmez la région et la version : Sur le site Web officiel d'Alibaba Cloud ou dans la console, confirmez que la région cible est ouverte à l'achat, et consultez la documentation de compatibilité des API pour la version d'instance afin de confirmer que les interfaces et les composants de l'écosystème dont vous dépendez sont pris en charge.
Planifiez l'organisation de vos données : Sur la base de la section Scénarios, décidez si vous souhaitez partitionner les Slices par base de connaissances, dépôt de code, agent ou locataire, et planifiez le nombre et le nommage des Collections.
Créez une instance et configurez les ressources : Configurez les nœuds d'index en fonction du volume d'écriture attendu, et configurez les nœuds de recherche en fonction de la concurrence des requêtes et de l'ensemble de travail actif. Pour la configuration des réplicas et des nœuds de recherche qui maintient la disponibilité des requêtes lors des défaillances de nœuds, consultez Architecture stateless et planification des ressources.
Intégrez et vérifiez : Utilisez l'API REST Elasticsearch ou un client officiel pour compléter l'intégration des écritures et des requêtes, spécifiez l'étendue de la requête via des Slices, et vérifiez les capacités de texte intégral, de recherche vectorielle KNN, de filtrage et d'agrégation.
Exécutez l'évaluation de la capacité et des tests de stress : Exécutez l'évaluation de la capacité et des tests de stress de performance avec vos données et requêtes métier réelles, en vous concentrant sur la latence des requêtes froides et chaudes et les performances de hit du cache, avant de procéder à la migration formelle.
Orientations futures
S'appuyant sur la fondation d'architecture native au stockage d'objets, la feuille de route d'Agent Engine Edition inclut le branching zero-copy en moins d'une seconde (création d'une branche de données indépendante pour tout Slice basée sur le copy-on-write, adaptée à l'évaluation, aux déploiements canaris et aux rollbacks), la mise à l'échelle Scale to Zero au niveau du calcul (mise à l'échelle automatique des espaces métier inactifs vers près de zéro afin que le coût s'aligne davantage sur la charge active réelle) et une intégration plus profonde avec les capacités de l'écosystème Alibaba Cloud Elasticsearch. Les dates de sortie spécifiques des fonctionnalités sont soumises aux annonces du produit.