Elasticsearch lire et écrire la cohérence
Elasticsearch n'a pas de paramètre "cohérence de lecture" (comme Cassandra) . Mais il a " cohérence d'écriture " et " préférence de lecture ".
La documentation indique ce qui suit à propos de Cohérence en écriture
Cohérence en écriture
Pour empêcher les écritures de se produire du "mauvais" côté d'une partition réseau, par défaut, les opérations d'index ne réussissent que si un quorum (> réplicas/2 + 1) de fragments actifs est disponible. Cette valeur par défaut peut être remplacée noeud par noeud à l'aide du paramètre action.write_consistency. Pour modifier ce comportement par opération, le paramètre de demande de cohérence peut être utilisé.Les valeurs de cohérence en écriture valides sont un, quorum et tous.
Remarque: dans le cas où le nombre de réplicas est égal à 1 (total de 2 copies des données), le comportement par défaut consiste à réussir si une copie (la principale) peut effectuer l'écriture.
L'opération d'index ne retourne qu'après que tous les fragments active du groupe de réplication ont indexé le document (réplication de synchronisation).
Ma question concerne le dernier paragraphe:
L'opération d'index ne retourne qu'après que tous les fragments active du groupe de réplication ont indexé le document (réplication de synchronisation).
Si write_consistency=quorum (par défaut) et tous les fragments sont en direct (pas de nœud en panne, pas de partition réseau), alors:
1) L’opération d’indexation est-elle renvoyée dès que le quorum de Shards a terminé l’indexation? (même si tous les fragments sont vivants/actifs)
2) Ou l'opération d'indexation est-elle renvoyée lorsque tous les fragments actifs/actifs ont terminé l'indexation? (c’est-à-dire que le quorum est pris en compte uniquement en cas d’échec/de dépassement de délai)
Dans le premier cas - la lecture peut être éventuellement cohérente (peut obtenir des données obsolètes), l'écriture est plus rapide.
Dans le second cas - lecture est cohérente (tant qu'il n'y a pas de partitions réseau), écriture est plus lente (car elle attend le fragment/nœud plus lent).
Est-ce que quelqu'un sait comment ça marche?
Une autre chose sur laquelle je me demande - est pourquoi la valeur par défaut de ' preference ' param (dans la requête get/search) est randomized mais pas _local (ce qui doit avoir été plus efficace, je suppose)
Je pense que je peux répondre à ma propre question maintenant :)
En ce qui concerne la première question, en relisant à plusieurs reprises la documentation ( ceci et ceci ) :), j’ai réalisé que cette déclaration devait être exacte:
L'opération d'indexation est renvoyée lorsque l'indexation de tous les fragments actifs/actifs est terminée, quel que soit le paramètre de cohérence. Le paramètre de cohérence peut uniquement empêcher le démarrage de l'opération s'il n'y a pas suffisamment de fragments disponibles (nœuds).
Ainsi, par exemple, s'il y a 3 fragments (un primaire et deux répliques) et que tous sont disponibles, l'opération attendra tous les 3 (en considérant que tous les 3 sont actifs/disponibles), indépendamment de paramètre de cohérence (même lorsque consistency=one)
Cela rend le système cohérent (au moins la partie document-api); À moins qu'il y ait une partition réseau… .. Mais je n'ai pas encore eu l'occasion de le tester.
UPDATE: par cohérence, je ne parle pas de cohérence ACID, c’est simplement la garantie que toutes les répliques sont mises à jour au moment où la demande est renvoyée.
En ce qui concerne la deuxième question: La réponse évidente est la suivante: il est randomized de répartir la charge; d'un autre côté, un client peut choisir un nœud aléatoire avec lequel dialoguer, mais ce n'est probablement pas efficace à 100% car une requête unique peut nécessiter plusieurs fragments.
Ecrire: Je ne sais pas si ce qui précède est vrai pour ES 6.1 https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#index-wait -for-active-shards indique que l'opération d'index est renvoyée si le fragment principal est actif et peut être remplacé par d'autres valeurs.
Les recherches sont aléatoires. Par conséquent, si vous définissez l'attente du champ de fragment actif à tous, vous vous assurez que l'écriture est réussie si elle est effectuée sur tous les fragments.
Lire: Les préférences peuvent toujours être utilisées, mais elles sont marquées comme étant déconseillées.