readConcern "linearizable"

요구 사항:

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

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

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

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

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

인과적으로 일관된 세션

읽기 고려 "linearizable" 는 인과적으로 일관적인 세션에서 사용할 수 없습니다.

집계 제한

$out 또는 $merge 단계는 읽기 고려 "linearizable"(과)와 함께 사용할 수 없습니다. 즉, db.collection.aggregate()에 "linearizable" 읽기 고려를 지정하면, 파이프라인에 둘 중 그 어떤 단계도 포함할 수 없습니다.

실시간 주문 처리

"majority" 쓰기 고려 (write concern)와 결합된 "linearizable" 읽기 고려 (read concern)를 사용하면 단일 스레드가 실시간으로 이러한 작업을 수행하는 것처럼 여러 스레드가 단일 문서에 대해 읽기 및 쓰기 (write)를 수행할 수 있습니다. 즉, 이러한 읽기 및 쓰기 (write)에 해당하는 일정은 선형화가 가능한 것으로 간주됩니다.

자체 쓰기 읽기

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

성능 비교

"majority"와는 달리, "linearizable" 읽기 고려는 세컨더리 멤버에 읽기 작업이 { w: "majority" } 쓰기 고려로 쓰기를 확인할 수 있는 프라이머리로부터 읽기를 실행하고 있음을 확인해 줍니다. [1] 따라서 선형화 가능한 읽기 고려를 가진 읽기는 "majority" 또는 "local" 읽기 고려를 가진 읽기보다 훨씬 느릴 수 있습니다.

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

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

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