Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Elasticsearch read and write consistency

Elasticsearch doesn't have "read consistency" param (like Cassandra). But it has "write consistency" and "read preference".

Documentation says the following about Write Consistency

Write Consistency
To prevent writes from taking place on the "wrong" side of a network partition, by default, index operations only succeed if a quorum (>replicas/2+1) of active shards are available. This default can be overridden on a node-by-node basis using the action.write_consistency setting. To alter this behavior per-operation, the consistency request parameter can be used.

Valid write consistency values are one, quorum, and all.

Note, for the case where the number of replicas is 1 (total of 2 copies of the data), then the default behavior is to succeed if 1 copy (the primary) can perform the write.

The index operation only returns after all active shards within the replication group have indexed the document (sync replication).

My question is about the last paragraph:

The index operation only returns after all active shards within the replication group have indexed the document (sync replication).

If write_consistency=quorum (default) and all shards are live (no node failures, no network-partition), then:
1) Does index operation return as soon as quorum of shards have finished indexing? (even though all shards are live/active)
2) Or does index operation return when all live/active shards have finished indexing? (i.e. quorum is considered only in case of failures/timeouts)

In the first case - read may be eventual-consistent (may get stale data), write is quicker.
In the second case - read is consistent (as long as there are no network-partitions), write is slower (as it waits for the slower shard/node).

Does anyone know how it works?

Another thing that I wonder about - is why the default value for 'preference' param (in get/search request) is randomized but not _local (which must have been more efficient I suppose)

like image 209
Vladimir Sorokin Avatar asked Jul 16 '16 18:07

Vladimir Sorokin


People also ask

Is Elasticsearch strongly consistent?

NO. Elastic Search is eventually consistent, NOT strongly consistent. The index operation is near real-time, if the new writes haven't been refreshed, you cannot get the up-to-date data, even if you get a successful response for your write request.

How does Elasticsearch replicate data?

Cross-cluster replication uses an active-passive model. You index to a leader index, and the data is replicated to one or more read-only follower indices. Before you can add a follower index to a cluster, you must configure the remote cluster that contains the leader index.

How many shards should Elasticsearch indexes have?

A good rule-of-thumb is to ensure you keep the number of shards per node below 20 per GB heap it has configured. A node with a 30GB heap should therefore have a maximum of 600 shards, but the further below this limit you can keep it the better.


1 Answers

I think I can answer my own question now :)

Regarding the first question, by re-re-reading the documentation (this and this) a few times :) I realized that this statement should be right:

Index operation return when all live/active shards have finished indexing, regardless of consistency param. Consistency param may only prevent the operation to start if there are not enough available shards(nodes).

So for example, if there are 3 shards (one primary and two replicas), and all shards are available - the operation will be waiting for all 3 (considering that all 3 are live/available), regardless of consistency param (even when consistency=one)
This makes the system consistent (at least the document-api part); unless there is a network-partition. But, I didn't have a chance to test this yet.

UPDATE: by consistency here, I don't mean ACID-consistency, it is just the guarantee that all replicas are updated at the moment when request is returned.

Regarding the second question: The obvious answer is - it is randomized to spread the load; on the other hand, a client can pick a random node to talk to, but probably it is not 100% efficient as a single request may need multiple shards.

like image 54
Vladimir Sorokin Avatar answered Sep 22 '22 22:09

Vladimir Sorokin