Les clusters Elasticsearch gèrent l'indexation et la recherche sur les mêmes nœuds. Vous devez donc dimensionner votre cluster pour le débit d'écriture maximal, même si le trafic en écriture est sporadique ou imprévisible. Les clusters Alibaba Cloud Elasticsearch Kernel-enhanced Edition avec Indexing Service déchargent toutes les opérations d'écriture vers un service cloud managé, ce qui libère les ressources de votre cluster pour la recherche. Fondée sur une architecture de séparation lecture/écriture, Indexing Service offre une indexation à haut débit et à faible latence pour une fraction du coût des charges de travail intensives en écriture exécutées sur un cluster standard.
Indexing Service est disponible dans la région Chine (Hong Kong). La disponibilité dans d'autres régions suivra prochainement.
Cas d'utilisation
Indexing Service est conçu pour l'analyse de données de séries temporelles caractérisées par un nombre élevé de transactions d'écriture par seconde (TPS), des fluctuations importantes du trafic en écriture et un faible nombre de requêtes par seconde (QPS). Voici des exemples de charges de travail typiques :
Récupération et analyse des journaux
Surveillance et analyse des métriques
Collecte, surveillance et analyse intelligentes des données matérielles de l'Internet des objets (IoT)
La synchronisation des données entre un cluster Kernel-enhanced Edition avec Indexing Service activé et votre cluster dépend de la tâche apack/cube/metadata/sync. Exécutez GET _cat/tasks?v pour vérifier l'état de la tâche. Ne supprimez pas cette tâche manuellement. Si la tâche est supprimée, exécutez immédiatement POST /_cube/meta/sync pour la restaurer et éviter toute interruption des écritures de données.
Fonctionnement
Les clusters Elasticsearch traditionnels gèrent l'indexation et la recherche sur les mêmes nœuds, ce qui couple étroitement le débit d'écriture à la capacité du cluster. Lorsque le trafic en écriture augmente brusquement, l'ensemble du cluster en subit les conséquences, y compris la latence de recherche.
Indexing Service dissocie ces deux fonctions :
Chemin d'écriture : Indexing Service reçoit tout le trafic en écriture et traite l'indexation dans un environnement d'hébergement d'écriture dédié.
Chemin de lecture : Votre cluster gère les requêtes de recherche sur les données répliquées depuis l'environnement d'hébergement d'écriture.
Cette architecture élimine la nécessité de dimensionner votre cluster pour le débit d'écriture maximal. Indexing Service provisionne et met à l'échelle les ressources d'écriture en arrière-plan, tandis que votre cluster se concentre sur les performances de recherche.
Trois technologies clés alimentent l'environnement d'hébergement d'écriture :
| Technologie | Description |
|---|---|
| Réplication physique des index | Réplique les données au niveau des segments entre les clusters en temps réel, maintenant la synchronisation entre le cluster d'hébergement d'écriture et votre cluster. |
| Séparation du calcul et du stockage | Dissocie le calcul d'écriture du stockage, permettant une mise à l'échelle indépendante de chaque niveau. |
| faster-bulk | Optimisation du noyau par Alibaba Cloud qui accélère considérablement le débit d'indexation groupée. |
Avantages
| Avantage | Détails |
|---|---|
| Coût réduit | Les ressources de calcul pour les opérations d'écriture sont réduites en moyenne de 60 %. Vous payez pour le volume d'écriture réel, et non pour la capacité maximale. |
| Mise à l'échelle élastique | Les ressources d'écriture s'adaptent automatiquement aux fluctuations du trafic. Aucune migration de données n'est requise. |
| Aucune opération ni maintenance (O&M) | Indexing Service gère toutes les opérations d'écriture dans le cloud, éliminant la surcharge de gestion du cluster liée aux écritures. |
| Hautes performances | Optimisation professionnelle de l'écriture grâce à la réplication physique, à la séparation calcul-stockage et à faster-bulk. |
| Faible latence | La réplication physique inter-clusters au niveau des segments maintient la latence des données dans la plage de quelques centaines de millisecondes, même dans des conditions d'écriture saturées. |
| Haute disponibilité | Prise en charge de la reprise après sinistre géographique via des sauvegardes multi-clusters entre régions. En cas de défaillance d'un cluster, transférez l'index vers un autre cluster fonctionnel pour l'hébergement. |
Facturation
Indexing Service facture des frais d'hébergement d'écriture, qui comprennent :
Frais de trafic en écriture : Basés sur le volume de trafic en écriture vers l'environnement d'hébergement d'écriture.
Frais de stockage : Basés sur l'espace de stockage utilisé pour l'hébergement.
Les frais d'hébergement d'écriture s'appliquent quel que soit le mode de facturation de votre cluster (abonnement ou paiement à l'utilisation). Pour plus de détails sur les tarifs, consultez Facturation Elasticsearch.
Indexing Service réduit les ressources nécessaires pour gérer les opérations d'écriture dans votre cluster, abaissant ainsi le coût global du cluster.
Limites
Indexing Service impose des limites sur le débit d'écriture, le nombre de documents et la configuration des index.
Limites au niveau du cluster
Il s'agit de limites strictes. Leur dépassement renvoie une erreur HTTP 429.
| Élément | Limite | Erreur en cas de dépassement |
|---|---|---|
| Trafic en écriture | 200 Mo/s | Inflow Quota Exceed. Pour demander une limite supérieure, soumettez un ticketsoumettez un ticket. |
| Documents écrits par seconde | 200 000 docs/s | Write QPS Exceed. Pour demander une limite supérieure, soumettez un ticketsoumettez un ticket. |
| Requêtes Put Mapping | 50 TPS | PutMappingRequest blocked. |
Les requêtes Put Mapping fréquentes consomment des ressources de calcul importantes et peuvent affecter la stabilité du service d'hébergement. Définissez un modèle d'index avant d'écrire des données afin de minimiser les opérations Put Mapping.
Limites au niveau des shards
Il s'agit de limites souples. Si une limite est atteinte, le service continue de fonctionner, mais la qualité ne peut pas être garantie.
| Élément | Limite souple | Code d'erreur |
|---|---|---|
| Trafic en écriture (sans clés primaires) | 10 Mo/s par shard | write_size blocked |
| Trafic en écriture (avec clés primaires) | 5 Mo/s par shard | write_size blocked |
| Documents écrits par seconde | 5 000 docs/s par shard | — |
| Shards par index | 300 shards | — |
Limites de configuration
Indexing Service gère automatiquement les paramètres suivants. Les configurations côté client pour ces paramètres ne prennent pas effet.
| Paramètre | Valeur par défaut | Notes |
|---|---|---|
index.refresh_interval |
30s |
Configuré automatiquement par Indexing Service. |
index.translog.durability |
async |
Défini sur async pour activer les écritures asynchrones du translog. |
index.merge.policy.max_merged_segment |
1024mb |
Configuré automatiquement. |
index.translog.flush_threshold_size |
2gb |
Configuré automatiquement. |
index.translog.sync_interval |
100s |
Configuré automatiquement. |
Limites au niveau de l'index
| Élément | Limite |
|---|---|
Paramètre freeze du cycle de vie |
Ne peut pas être modifié au sein du cycle de vie de l'index. |
| Opération de réduction (Shrink) | Un index hébergé est incompatible avec l'opération de réduction dans la gestion du cycle de vie des index (ILM). Effectuez l'opération de réduction uniquement lorsque l'index n'est pas hébergé. Consultez Shrink. |
| Annulation automatique de l'hébergement | L'hébergement est automatiquement désactivé 3 jours après qu'un index est hébergé. Modifiez cette durée pour qu'elle corresponde à vos exigences en matière de cycle de vie des données. |
| Prétraitement Ingest Node | Lors de l'utilisation d'un Ingest Node pour prétraiter les documents avant l'indexation, le prétraitement s'exécute sur votre cluster, et non sur l'environnement d'hébergement. Évitez une logique de traitement trop complexe dans cette configuration. Pour plus de détails, consultez Ingest Node. |
Tests de performance
Les résultats suivants comparent les performances d'écriture entre l'édition Kernel-enhanced Edition avec Indexing Service et les clusters Standard Edition avec des spécifications matérielles identiques.
Ces résultats sont basés sur l'environnement de test et l'ensemble de données décrits ci-dessous. Les performances réelles dépendent des caractéristiques de vos données, de la configuration de vos index et des modèles de charge de travail.
Environnement de test
Résultats des tests
| Spécifications (3 nœuds de données) | Édition du cluster | TPS en écriture | Délai de visibilité en écriture |
|---|---|---|---|
| 2 cœurs, 8 Go | Standard Edition | 24 883 | 5 secondes |
| 2 cœurs, 8 Go | Kernel-enhanced Edition avec Indexing Service | 226 649 | 6 secondes |
| 4 cœurs, 16 Go | Standard Edition | 52 372 | 5 secondes |
| 4 cœurs, 16 Go | Kernel-enhanced Edition avec Indexing Service | 419 574 | 6 secondes |
| 8 cœurs, 32 Go | Standard Edition | 110 277 | 5 secondes |
| 8 cœurs, 32 Go | Kernel-enhanced Edition avec Indexing Service | 804 010 | 6 secondes |
Amélioration des performances par rapport à Standard Edition
| Spécifications (3 nœuds) | Amélioration des TPS en écriture |
|---|---|
| 2 cœurs, 8 Go | 910 % |
| 4 cœurs, 16 Go | 801 % |
| 8 cœurs, 32 Go | 729 % |