Cette rubrique définit les termes fondamentaux utilisés dans Alibaba Cloud Elasticsearch.
cluster
Un cluster Elasticsearch se compose d’un ou de plusieurs nœuds. Tous les nœuds d’un cluster collaborent pour stocker les données. Chaque cluster doit porter un nom unique : si deux clusters partagent le même nom au sein du même environnement, une exception inattendue peut survenir.
node
Un nœud s’exécute sur un serveur au sein d’un cluster. Les nœuds stockent les données et prennent en charge les opérations d’indexation et de requête. Ils peuvent endosser différents rôles :
Les nœuds de données stockent les index. Utilisez-les pour ajouter, supprimer et modifier des documents, ainsi que pour rechercher et agréger des données.
Les nœuds maîtres dédiés gèrent les opérations au niveau du cluster : création et suppression d’index, suivi des nœuds et allocation des shards. La stabilité de ces nœuds est cruciale pour la santé du cluster. Par défaut, tout nœud du cluster peut servir de nœud maître dédié.
Les nœuds clients déchargent la consommation processeur des nœuds de données, ce qui améliore les performances de calcul et la stabilité du cluster.
index
Un index est un ensemble de documents partageant des caractéristiques similaires, à l’image d’une base de données dans un système relationnel. Vous pouvez par exemple créer trois index distincts pour stocker respectivement les données clients, le catalogue produits et les commandes.
Chaque index est identifié par un nom en minuscules. Lors de l’indexation, de la recherche, de la mise à jour ou de la suppression d’un document, spécifiez le nom de l’index auquel il appartient.
type
Un type constitue une partition logique au sein d’un index, comparable à une table dans une base de données relationnelle. Un index peut contenir des documents de différents types, tels qu’un type user et un type blog.
La prise en charge des types a été progressivement supprimée :
Elasticsearch 5.x — un index peut contenir plusieurs types de documents.
Elasticsearch 6.x — un index ne peut contenir qu’un seul type de document. Le concept de type est obsolète.
Elasticsearch 7.x et versions ultérieures — le type d’un index est fixé à
_doc.
Pour plus de détails, consultez la documentation Elasticsearch sur la suppression des types.
document
Un document représente l’unité de base pouvant être indexée, à l’instar d’une ligne dans une table de base de données relationnelle. Il peut par exemple correspondre à un client unique ou à un produit spécifique. Chaque document est un objet JSON. Un index peut contenir un nombre illimité de documents.
field
Un champ constitue la plus petite unité au sein d’un document, comparable à une colonne dans une table de base de données relationnelle.
mapping
Un mapping définit la manière dont un document et ses champs sont stockés et indexés, notamment les noms des champs, leurs types et l’analyseur lexical à utiliser. Ce concept s’apparente au schéma d’une table dans une base de données relationnelle.
Le tableau suivant établit la correspondance entre les concepts Elasticsearch et ceux des bases de données relationnelles.
| Elasticsearch | Base de données relationnelle |
|---|---|
| index | database |
| type | table |
| document | row |
| field | column |
| mapping | schema |
Shard et replica shard
Un index peut être divisé en plusieurs shards, répartis sur différents nœuds afin de permettre la recherche distribuée. On distingue deux catégories de shards : les shards primaires et les shards de réplication.
Lors de la création d’un index, définissez le nombre de shards primaires et de shards de réplication. Le nombre de shards primaires ne peut pas être modifié après la création de l’index.
Configuration par défaut des shards :
Elasticsearch antérieur à la version 7.0 : 5 shards primaires et 1 shard de réplication par shard primaire, pour chaque index.
Elasticsearch 7.0 et versions ultérieures : 1 shard primaire et 1 shard de réplication par index.
Le tableau ci-dessous résume les différences entre les shards primaires et les shards de réplication.
| Type de shard | Requêtes prises en charge | Nombre modifiable après création | Notes |
|---|---|---|---|
| Primary shard | Requêtes et indexation | Non — défini lors de la création de l’index. Consultez Étape 3 : Créer un index. | Chaque document appartient à exactement un shard primaire. Le nombre de shards primaires détermine le volume maximal de données qu’un index peut contenir. Un nombre élevé de shards primaires accroît la surcharge des performances du cluster. |
| Replica shard | Requêtes uniquement | Oui — modifiable à tout moment. Consultez Modèles d’index. | Les shards de réplication renforcent la tolérance aux pannes : si un shard primaire est perdu, il peut être restauré à partir d’un réplica. Ils améliorent également le débit de recherche en répartissant la charge des requêtes. |
Vous pouvez interroger les shards primaires ou les shards de réplication pour récupérer des données.
Opérations d’écriture : lorsqu’un cluster reçoit une requête d’écriture, il applique l’opération au shard primaire concerné, puis réplique les données vers les réplicas de ce shard. Un grand nombre de shards de réplication augmente la charge de synchronisation des données lors des écritures.
Le nombre de shards et la taille de chacun d’eux influent sur la stabilité et les performances du cluster. Planifiez la configuration des shards pour tous les index avant le déploiement afin d’éviter toute dégradation des performances à grande échelle. Pour obtenir des recommandations de dimensionnement, consultez Évaluer les spécifications et la capacité de stockage.
gateway
Une gateway stocke des snapshots des index. Par défaut, un nœud conserve tous les index en mémoire. Lorsque la mémoire du nœud est saturée, les index sont transférés vers le disque local. Au redémarrage d’un cluster, celui-ci restaure les index à partir des snapshots de la gateway plutôt que de les lire depuis le disque local, ce qui est nettement plus rapide.
Les types de gateway pris en charge incluent le système de fichiers local (par défaut), le système de fichiers distribué, Hadoop Distributed File System (HDFS) et Alibaba Cloud Object Storage Service (OSS).
discovery.zen
discovery.zen constitue le mécanisme de découverte automatique des nœuds utilisé dans Elasticsearch. Elasticsearch fonctionne selon une architecture pair à pair (P2P) et découvre les nœuds en envoyant des broadcasts. Les nœuds communiquent via des protocoles multicast et P2P.
transport
Transport représente la couche de communication entre un cluster Elasticsearch (ou ses nœuds) et les clients. TCP est utilisé par défaut. Intégrez des plug-ins pour prendre en charge d’autres protocoles, notamment HTTP sur JSON, Thrift, Memcached et ZeroMQ.