MongoDb linearizable read concern restrictions

Question

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?

Answer 1

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.