2

Could someone explain me some part of Mongodb linearizable read concern documentation:

Linearizable read concern guarantees only apply if read operations specify a query filter that uniquely identifies a single document.

Is it mean that i have to have unique index on fields that presented in query filter?

For example let's answer on 4 questions:

  1. I have collection test without unique index on A field. db.test.find({A:"someValue"}).readConcern("linearizable").maxTimeMS(10000)

    Is it linearizable and i can't get stale read? If answer yes, is it mean that there no reason to use linearizable read concern in reads by fileds which not presented in unique index?

  2. I have collection test with unique index on A field.
    db.test.ensureIndex({A:1}, {unique:true}); db.test.find({A:"someValue"}).readConcern("linearizable").maxTimeMS(10000);

    Is it linearizable and i can't get stale read?

  3. I have collection test with unique index on A field.
    db.test.ensureIndex({A:1}, {unique:true}); db.test.find({A:"someValue", B:"someValue2"}) .readConcern("linearizable").maxTimeMS(10000);

    Is it linearizable and i can't get stale read?

  4. I have collection test without unique index on A field. But find method return only one document in result.
    db.test.find({A:"someValue"}).readConcern("linearizable").maxTimeMS(10000); //returned {_id:"someId", A:"someValue"}

    Is it linearizable and i can't get stale read?

2

Dmitry,

As of MongoDB v3.6, MongoDB only supports the linearizable read concern on single documents, hence the wording of the documentation. However, it doesn't mean you have to run the query using a unique index, but that you have to be sure your query only returns one document. Of course, it can only help to have a query filter that uses a unique index (such as the default index on the _id field), since this will ensure that your query returns a single document.

In your specific cases, queries #2 and #3 can enforce linearizable reads and it will not return stale reads.

For query #4, you will also get a linearizable read, assuming the query only returns one document (which is your assumption).

For query #1, you're not guaranteed to get linearizable reads IF your query returns more than one document so you can indeed get stale reads in that situation (and your cluster happens to be partitioned at the time the query hits the old primary).

Note that your query syntax for the find() method means that you're requesting in documents that include an A property with a value equal to 1 (as a double) [and a B property of value 1 in query #3), while your ensureIndex({A:1}) command specifies that the index should be built on the A attribute. I hope you are aware of that because your queries are otherwise a bit confusing.

  • Thanks for answer, i eliminate confusion about A:1, if i understand your remark correctly. – DmitryZyr Jan 19 '18 at 8:22
  • Thank you, it is indeed clearer with the someValue/someValue2 values now. Glad to know the answer helped! – Raphael Londner Jan 19 '18 at 17:05
  • Raphael, can you answer one additional question? As I know, linearisable consistency is working through noop writes. If write complete it means that we are master node and we can return answer to the client: Replication-Internals. My additional question is: Why linearizable impose restrictions on a single document? Why single? If we are master, why we can't return array of documents? – DmitryZyr Jan 27 '18 at 11:54
  • @DmitryZyr Here's my take: linearizable reads guarantees that the document is current and will not be rolled back at the time when the document leaves the server, which could be true only for a short amount of time, depending on workload & use case. With multiple documents, you cannot guarantee that subsequent documents or batches remain linearizable, unless you do a "read lock" and basically make the database globally single-threaded with pessimistic locking (which would be very very slow). To enable linearizable while allowing concurrency, the guarantee only exist for a single document. – kevinadi Jan 30 '18 at 22:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.