readConcern "linearizable"

요구 사항:

선형화 가능 읽기 고려는 읽기 작업이 단일 문서를 고유하게 식별하는 쿼리 필터를 명시하는 경우에만 적용됩니다. 또한 다음 기준 중 어느 하나라도 충족되지 않으면 선형화 가능 읽기 고려가 일관적인 스냅샷에서 읽히지 않아 필터와 일치하는 문서가 반환되지 않을 수 있습니다.

• 이 쿼리는 변경 불가능한 필드를 쿼리의 검색 키로 사용합니다. 예를 들면 _id 필드에서 검색하거나 $natural을 사용합니다.

• 동시 업데이트는 쿼리의 검색 키를 변경하지 않습니다.

• 검색 키에는 고유 인덱스가 있고 쿼리는 해당 인덱스를 사용합니다.

위의 기준 중 하나라도 충족되면 쿼리는 일관적인 스냅샷을 읽어 일치하는 문서 하나를 반환합니다.

인과적으로 일관된 세션

Read concern "linearizable" is unavailable for use with causally consistent sessions.

집계 제한

You cannot use the $out or the $merge stage in conjunction with read concern "linearizable". That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include either stages in the pipeline.

실시간 주문 처리

Combined with "majority" write concern, "linearizable" read concern enables multiple threads to perform reads and writes on a single document as if a single thread performed these operations in real time; that is, the corresponding schedule for these reads and writes is considered linearizable.

자체 쓰기 읽기

쓰기에서 승인을 요청하는 경우 인과적으로 일관된 세션을 사용하여 자신의 쓰기를 읽을 수 있습니다.

성능 비교

Unlike "majority", "linearizable" read concern confirms with secondary members that the read operation is reading from a primary that is capable of confirming writes with { w: "majority" } write concern. [1] As such, reads with linearizable read concern may be significantly slower than reads with "majority" or "local" read concerns.

데이터를 가진 멤버의 과반수 이상을 사용할 수 없는 경우, 항상 선형화 가능한 읽기 고려와 함께 maxTimeMS를 사용하세요. maxTimeMS는 작업이 무기한으로 차단되지 않도록 하며, 대신 읽기 고려를 충족할 수 없는 경우 작업이 오류를 반환하도록 합니다.

예를 들면 다음과 같습니다.

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )