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:
-
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?
-
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?
-
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?
-
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?
Best Answer
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 aB
property of value1
in query #3), while yourensureIndex({A:1})
command specifies that the index should be built on theA
attribute. I hope you are aware of that because your queries are otherwise a bit confusing.