# NRT Search and Read/Write consistency **URL:** \ **Category:** Elasticsearch\ **Created:** [August 21, 2011, 3:45am UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210 "2011-08-21T03:45:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Prashanth\_Menon](https://avatars.discourse-cdn.com/v4/letter/p/9e8a1a/32.png) [@Prashanth\_Menon](https://discuss.elastic.co/u/Prashanth_Menon)\ **Post date:** [August 21, 2011, 3:45am UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/1 "2011-08-21T03:45:44Z")
Hi everyone, Though the documentation I've read is great, I haven't quiet found the answer to my concern around NRT and quorem reads (similar to this: [http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-and-datacenter-awareness-td696454.html#a696491](http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-and-datacenter-awareness-td696454.html#a696491) and this: [http://groups.google.com/a/elasticsearch.com/group/users/browse\_thread/thread/44f9bea27fe117fe/68aa72d73233db83?lnk=gst&q=distributed+search#68aa72d73233db83](http://groups.google.com/a/elasticsearch.com/group/users/browse_thread/thread/44f9bea27fe117fe/68aa72d73233db83?lnk=gst&q=distributed+search#68aa72d73233db83)). Currently, I'm doing some high volume processing that requires heavy searching into our ES cluster with several indices each with 3-5 shards and at least 2 replicas. The general process is to query ES and insert/index a document if not found or update an existing document. According to what I understand, each query (get/search) gets hashed to a shard id and is serviced by the replica group (primary shard + replica set). The problem I foresee is as follows: In a multi-threaded case: Two threads attempting updates. Thread one searches term "d1" in index "i1", does not find it, performs index and insert or a new document with a random id. At the same time, thread two performs search for the same "d1" term in index "i1" but does not find it (just a timing issue). Thread two then has to also perform an index and insert of a new document with a new random id. So we have duplicate document data here (or overwrites had the ID's been the same). Correct me if I'm wrong but versioning doesn't work here because the ID's of the documents are not the same, so what can I do? In the single-threaded case: During processing, we query for "d1", do not find it and index a new document (presumably into the primary shard since it's "dirty" operation?). Later on we perform a search for the same field "d1" in the same index but it gets hashed/serviced by a replica that hasn't received the update from the primary yet. How can I get around NRT without forcing strong consistency? Is there a quorum read feature I can use? ---
**Author:** ![Prashanth\_Menon](https://avatars.discourse-cdn.com/v4/letter/p/9e8a1a/32.png) [@Prashanth\_Menon](https://discuss.elastic.co/u/Prashanth_Menon)\ **Post date:** [August 21, 2011, 8:22pm UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/2 "2011-08-21T20:22:22Z")
So, it looks like the single-threaded case can be solved by using the "preference" attribute when searching to point to the "primary" shard only: [Search / Get: Allow to specify a preference on which shards (or order) it will be executed · Issue #769 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/769). Any word on the multi-threaded case? On Aug 20, 11:45 pm, Prashanth Menon [prashanth.men...@gmail.com](mailto:prashanth.men...@gmail.com) wrote: > Hi everyone, > > Though the documentation I've read is great, I haven't quiet found the > answer to my concern around NRT and quorem reads (similar to this:[http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an](http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an)... > and this:[http://groups.google.com/a/elasticsearch.com/group/users/browse\_threa](http://groups.google.com/a/elasticsearch.com/group/users/browse_threa)...). > > Currently, I'm doing some high volume processing that requires heavy > searching into our ES cluster with several indices each with 3-5 > shards and at least 2 replicas. The general process is to query ES > and insert/index a document if not found or update an existing > document. According to what I understand, each query (get/search) > gets hashed to a shard id and is serviced by the replica group > (primary shard + replica set). The problem I foresee is as follows: > > In a multi-threaded case: Two threads attempting updates. Thread one > searches term "d1" in index "i1", does not find it, performs index and > insert or a new document with a random id. At the same time, thread > two performs search for the same "d1" term in index "i1" but does not > find it (just a timing issue). Thread two then has to also perform an > index and insert of a new document with a new random id. So we have > duplicate document data here (or overwrites had the ID's been the > same). Correct me if I'm wrong but versioning doesn't work here > because the ID's of the documents are not the same, so what can I do? > > In the single-threaded case: During processing, we query for "d1", do > not find it and index a new document (presumably into the primary > shard since it's "dirty" operation?). Later on we perform a search > for the same field "d1" in the same index but it gets hashed/serviced > by a replica that hasn't received the update from the primary yet. > How can I get around NRT without forcing strong consistency? Is there > a quorum read feature I can use? ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 21, 2011, 8:33pm UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/3 "2011-08-21T20:33:16Z")
As you stated, I was going to point out the versioning support for optimistic concurrency until you said the ids would not be the same. Is it possible for your ids to be the same, and use another field (like 'key') for this random id you are currently using? -- jim ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 22, 2011, 7:50am UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/4 "2011-08-22T07:50:53Z")
How would you solve something like that with a relational database? I think you will see you have exactly the same problem (not talking about the single thread updater case), unless I am missing something. On Sun, Aug 21, 2011 at 11:22 PM, Prashanth Menon \< [prashanth.menon1@gmail.com](mailto:prashanth.menon1@gmail.com)\> wrote: > So, it looks like the single-threaded case can be solved by using the > "preference" attribute when searching to point to the "primary" shard > only: [Search / Get: Allow to specify a preference on which shards (or order) it will be executed · Issue #769 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/769). Any > word on the multi-threaded case? > > On Aug 20, 11:45 pm, Prashanth Menon [prashanth.men...@gmail.com](mailto:prashanth.men...@gmail.com) > wrote: > > > Hi everyone, > > > > Though the documentation I've read is great, I haven't quiet found the > > answer to my concern around NRT and quorem reads (similar to this: > > [http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an](http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an)... > > and this: > > [http://groups.google.com/a/elasticsearch.com/group/users/browse\_threa](http://groups.google.com/a/elasticsearch.com/group/users/browse_threa)...). > > > > Currently, I'm doing some high volume processing that requires heavy > > searching into our ES cluster with several indices each with 3-5 > > shards and at least 2 replicas. The general process is to query ES > > and insert/index a document if not found or update an existing > > document. According to what I understand, each query (get/search) > > gets hashed to a shard id and is serviced by the replica group > > (primary shard + replica set). The problem I foresee is as follows: > > > > In a multi-threaded case: Two threads attempting updates. Thread one > > searches term "d1" in index "i1", does not find it, performs index and > > insert or a new document with a random id. At the same time, thread > > two performs search for the same "d1" term in index "i1" but does not > > find it (just a timing issue). Thread two then has to also perform an > > index and insert of a new document with a new random id. So we have > > duplicate document data here (or overwrites had the ID's been the > > same). Correct me if I'm wrong but versioning doesn't work here > > because the ID's of the documents are not the same, so what can I do? > > > > In the single-threaded case: During processing, we query for "d1", do > > not find it and index a new document (presumably into the primary > > shard since it's "dirty" operation?). Later on we perform a search > > for the same field "d1" in the same index but it gets hashed/serviced > > by a replica that hasn't received the update from the primary yet. > > How can I get around NRT without forcing strong consistency? Is there > > a quorum read feature I can use? ---
**Author:** ![Prashanth\_Menon](https://avatars.discourse-cdn.com/v4/letter/p/9e8a1a/32.png) [@Prashanth\_Menon](https://discuss.elastic.co/u/Prashanth_Menon)\ **Post date:** [August 22, 2011, 11:18am UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/5 "2011-08-22T11:18:42Z")
Hi Shay, James, Haha, this is incredible. I asked myself that exact same question moments after I made my post (can't find an edit button though). I actually simplified my scenario but have an idea of how to solve it. What I'm much happier about was that we had the same train of thought. Great work so far Shay, what you've got here is a pretty awesome product. - Prashanth On Aug 22, 3:50 am, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote: > How would you solve something like that with a relational database? I think > you will see you have exactly the same problem (not talking about the single > thread updater case), unless I am missing something. > > On Sun, Aug 21, 2011 at 11:22 PM, Prashanth Menon \< > > [prashanth.men...@gmail.com](mailto:prashanth.men...@gmail.com)\> wrote: > > > So, it looks like the single-threaded case can be solved by using the > > "preference" attribute when searching to point to the "primary" shard > > only:[Search / Get: Allow to specify a preference on which shards (or order) it will be executed · Issue #769 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/769). Any > > word on the multi-threaded case? > > > On Aug 20, 11:45 pm, Prashanth Menon [prashanth.men...@gmail.com](mailto:prashanth.men...@gmail.com) > > wrote: > > > > > Hi everyone, > > > > Though the documentation I've read is great, I haven't quiet found the > > > answer to my concern around NRT and quorem reads (similar to this: > > > [http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an](http://elasticsearch-users.115913.n3.nabble.com/quorum-consistency-an)... > > > and this: > > > [http://groups.google.com/a/elasticsearch.com/group/users/browse\_threa](http://groups.google.com/a/elasticsearch.com/group/users/browse_threa)...). > > > > Currently, I'm doing some high volume processing that requires heavy > > > searching into our ES cluster with several indices each with 3-5 > > > shards and at least 2 replicas. The general process is to query ES > > > and insert/index a document if not found or update an existing > > > document. According to what I understand, each query (get/search) > > > gets hashed to a shard id and is serviced by the replica group > > > (primary shard + replica set). The problem I foresee is as follows: > > > > In a multi-threaded case: Two threads attempting updates. Thread one > > > searches term "d1" in index "i1", does not find it, performs index and > > > insert or a new document with a random id. At the same time, thread > > > two performs search for the same "d1" term in index "i1" but does not > > > find it (just a timing issue). Thread two then has to also perform an > > > index and insert of a new document with a new random id. So we have > > > duplicate document data here (or overwrites had the ID's been the > > > same). Correct me if I'm wrong but versioning doesn't work here > > > because the ID's of the documents are not the same, so what can I do? > > > > In the single-threaded case: During processing, we query for "d1", do > > > not find it and index a new document (presumably into the primary > > > shard since it's "dirty" operation?). Later on we perform a search > > > for the same field "d1" in the same index but it gets hashed/serviced > > > by a replica that hasn't received the update from the primary yet. > > > How can I get around NRT without forcing strong consistency? Is there > > > a quorum read feature I can use? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:56am UTC](https://discuss.elastic.co/t/nrt-search-and-read-write-consistency/5210/6 "2017-07-06T03:56:24Z")