Alibaba Cloud Elasticsearch Agent Engine Edition repose sur une architecture sans état qui permet de faire évoluer indépendamment la capacité de stockage, le débit d'écriture et les capacités de requête. Le stockage objet conserve les données persistantes et la facturation se base sur l'utilisation réelle. Dimensionnez les ressources de calcul en fonction de vos charges de lecture et d'écriture effectives, et planifiez le cache local autour de vos données actives.
Par exemple, si seule une petite partie de votre base de connaissances historique, en constante croissance, est consultée quotidiennement, stockez les nouvelles données dans le stockage objet et concentrez les ressources de calcul et de cache sur les données actives. Cela réduit la nécessité de réserver des ressources pour les données rarement consultées.
Stockage des données et responsabilités des composants
|
Composant |
Responsabilité principale |
Éléments à planifier |
|
Nœud d'indexation |
Gère les écritures entrantes, la création d'index et les fusions en arrière-plan, et persiste les données dans le stockage objet. |
Débit d'importation, volume d'écriture soutenu et surcharge liée à la création d'index. |
|
Nœud de requête |
Exécute les requêtes et met en cache localement les données requises. En cas d'absence du cache, il lit les données depuis le stockage objet. |
Concurrence des requêtes, surcharge liée à la recherche vectorielle, ensembles de données actives et capacité du cache. |
|
Stockage objet |
Stocke les données d'index, les journaux d'écriture et l'état persistant nécessaire au fonctionnement du service. |
Aucun achat de capacité anticipé ni extension manuelle ; facturation basée sur l'utilisation réelle. |
Pour connaître les configurations des nœuds et les points d'accès dans la console, consultez la rubrique Créer et se connecter à une instance.
Mise à l'échelle indépendante des charges d'écriture et de requête
Les pics d'écriture et les pics de requête ne doivent pas nécessairement partager la même configuration de ressources. Ajoutez des ressources au composant qui constitue le goulot d'étranglement réel, afin d'éviter le gaspillage lié à la mise à l'échelle simultanée des deux côtés pour une seule charge :
Lorsque les importations groupées ou le volume d'écriture soutenu augmentent, ajoutez des nœuds d'indexation pour améliorer la capacité d'écriture et de création d'index.
Lorsque la concurrence des requêtes augmente, ajoutez des nœuds de requête pour disposer de davantage de ressources de calcul et de cache dédiées aux requêtes.
Lorsque le volume total de données augmente mais que les données actives changent peu, maintenez la taille du cache local adaptée aux données actives. Le stockage persistant évolue avec l'utilisation, tandis que le cache local n'a pas besoin de croître proportionnellement au volume total de données.
Les spécifications des nœuds et leur nombre dépendent des configurations disponibles sur la page d'achat. La planification des shards, la concurrence des opérations groupées et l'étendue des requêtes influent également sur l'utilisation des ressources. Si l'accès aux données froides est lent, préchauffez le cache Slice sur les nœuds de requête avant que les utilisateurs n'ouvrent la base de connaissances, afin de réduire le temps d'attente en lecture de la première requête.
Accusé de réception d'écriture et visibilité dans la recherche
Pour confirmer une écriture par ID, utilisez GET ou mget, qui effectuent des lectures en temps réel par défaut et ne nécessitent aucune actualisation. Pour connaître les limites de lecture lorsque le shard principal est indisponible, consultez la rubrique Confirmer les écritures par ID. Les paragraphes suivants décrivent quand les documents deviennent visibles pour les requêtes de recherche.
L'accusé de réception d'écriture et la visibilité dans la recherche constituent deux étapes distinctes. Une écriture est accusée de réception une fois que le journal d'écriture est persisté. Les données n'apparaissent dans les résultats de recherche qu'après que les nœuds d'indexation ont généré et publié une nouvelle version interrogeable et que les nœuds de requête ont chargé cette version. Par conséquent, une recherche lancée immédiatement après une demande d'écriture réussie peut ne pas renvoyer les nouveaux documents pendant un court instant.
Pour les écritures standard, ne transmettez pas le paramètre refresh. Attendez plutôt l'actualisation automatique en arrière-plan, car la publication et le chargement plus fréquents des versions de données augmentent la surcharge des ressources. Des attentes synchrones sont disponibles sous certaines conditions. Pour connaître l'intervalle d'actualisation par défaut et ces conditions, consultez la rubrique Actualisation et visibilité des requêtes.
Répliques de requête, disponibilité et différences avec Elasticsearch traditionnel
Les requêtes sont traitées par les shards de réplique situés sur les nœuds de requête. Planifiez à la fois les répliques de requête et les nœuds de requête pouvant les héberger en fonction de vos objectifs de disponibilité. La seule présence de données persistantes ne signifie pas que le service de requête est prêt. Après des modifications ou une récupération de nœuds, confirmez que le service est disponible en exécutant des requêtes réelles et observez la latence pendant la récupération du cache local. Si l'accès aux données froides est lent, le préchauffage du cache Slice réduit le temps d'attente en lecture de la première requête.
Vous ne pouvez pas réutiliser directement les niveaux de données, la gestion du cycle de vie des index (ILM), Translog ou les paramètres d'attente des répliques d'Elasticsearch traditionnel. Pour plus de détails, consultez la rubrique Différences avec Elasticsearch traditionnel avec état. Lors de la création d'une Collection, le paramètre de réplique de requête index.number_of_replicas est défini par défaut sur 2. Une valeur de 0 ne permet pas de traiter les requêtes, et une valeur de 1 répond uniquement aux exigences de requête de base et n'offre pas de haute disponibilité (HA) pour les requêtes. Dans les environnements de production, configurez au moins 2 nœuds de requête afin qu'une réplique disponible puisse toujours traiter les requêtes en cas de défaillance d'un seul nœud de requête. Les données persistantes sont conservées dans le stockage objet, et les répliques de requête gèrent principalement les travaux de requête et de cache ; l'ajout de répliques ne peut donc pas remplacer une stratégie de sauvegarde.