Reputation: 47881
will this update in elastic search cause an atomic increment? Or will it be non-atomic?
curl -XPOST 'localhost:9200/test/type1/1/_update' -d '{
"script" : "ctx._source.counter += count",
"params" : {
"count" : 1
}
}'
Upvotes: 10
Views: 10520
Reputation: 4138
I would argue that the suggested update script is atomic, the referred Optimistic Concurrency Control talks about updates on documents which are not atomic (meaning that parallel update requests might get the document into an "inconsistent" unintended state).
Ah, after reading more docs about Partial Updates to Documents I learned that actually it is not atomic, but it checks the version number and fails if they don't match (so updates won't silently get lost, as is the case with non-atomic increments on CPUs):
To avoid losing data, the update API retrieves the current _version of the document in the retrieve step, and passes that to the index request during the reindex step. If another process has changed the document between retrieve and reindex, then the _version number won’t match and the update request will fail.
However there is an easy fix to make it work just the same as atomic increments:
For many uses of partial update, it doesn’t matter that a document has been changed. For instance, if two processes are both incrementing the page-view counter, it doesn’t matter in which order it happens; if a conflict occurs, the only thing we need to do is reattempt the update.
This can be done automatically by setting the
retry_on_conflict
parameter to the number of times thatupdate
should retry before failing; it defaults to0
.
Upvotes: 11
Reputation: 52368
Non-atomic. You need to use the version
parameter to tell ES to update the document only if it has a certain version: https://www.elastic.co/guide/en/elasticsearch/guide/master/optimistic-concurrency-control.html
For example: /test/type1/1/_update?version=5
Upvotes: 5