트랜잭션이 여러 개체에 걸쳐 있지 않을 경우 개체 당 낙관적 동시성이 직렬화 가능성을 의미합니까?

다음을 제공하는 시스템이 제공됩니다.

• 개체 당 낙관적 동시성 제어 / 버전 관리 (CAS-Check-and-Set 사용)
• 단일 개체 이상으로 확장 될 필요가없는 트랜잭션
• 스냅 샷 격리

이 시스템은 직렬화 가능한 것으로 간주 됩니까?

에서 스냅 샷 격리

쓰기 스큐 이상에서 두 트랜잭션 (T1 및 T2)은 겹치는 데이터 세트 (예 : 값 V1 및 V2)를 동시에 읽고 분리 된 업데이트 (예 : T1 업데이트 V1, T2 업데이트 V2)를 만들고 마지막으로 커밋합니다. 다른 사람이 수행 한 업데이트 시스템이 직렬화 가능했으면 T1 또는 T2가 "먼저"발생하고 다른 시스템에서 볼 수 있기 때문에 이러한 예외는 불가능합니다. 반대로 스냅 샷 격리는 쓰기 왜곡 현상을 허용합니다.

구체적인 예로서, V1과 V2가 한 사람 Phil이 보유한 두 개의 저울이라고 상상해보십시오. 은행은 V1 또는 V2가 적자를 실행할 수 있도록 허용합니다. 둘 다 보유한 총액이 음수 인 경우 (즉, V1 + V2 ≥ 0). 두 잔액은 현재 $ 100입니다. Phil은 두 개의 트랜잭션을 동시에 시작합니다. T1은 V1에서 $ 200를 인출하고 T2는 V2에서 $ 200를 인출합니다.

이를 바탕으로 쓰기 왜곡 가능성 이있는 것은 스냅 샷 격리가 직렬화 가능하지 않은 시스템의 유일한 이유 인 것 같습니다 .

그러나 트랜잭션이 여러 개체 (위의 예 V1 및 V2)에 걸쳐있을 수없는 시스템에서는 쓰기 왜곡 이 발생할 수 없는 것 같습니다 .

따라서 위에서 설명한 시스템은 직렬화 가능합니다. 이 올바른지?

아니요, 귀하의 규정으로 인해 직렬화 가능한 시스템을 고려해야한다고 생각하지 않습니다.

스냅 샷 격리는 트랜잭션이 전체 트랜잭션에서 동일한 데이터 집합을 볼 수 있도록하는 기술입니다. 스냅 샷 격리는 몇 가지 보장을 제공하지만 스냅 샷 격리와 MVCC를 혼동하지 않는 한 트랜잭션이 실제로 어떻게 작동하는지 이해하는 데 필요한 모든 특성을 정의하지는 않습니다.

스냅 샷 격리는 MVCC, Multi Version Consistency Control을 사용하여 가장 일반적으로 구현됩니다. MVCC는 스냅 샷과 관련하여 더 자세한 트랜잭션을 정의합니다. 즉, 쓰기 충돌시에만 격리가 필요하다고합니다 (구현에 따라 위치 만 또는 위치 + 값). MVCC는 편안한 일관성 모델을 제공하며 쓰기 왜곡으로 어려움을 겪습니다.

편안한 일관성 모델은 격리가없고 완전 격리가 혼재되어 있기 때문에 이해하기 어렵습니다.

먼저 엄격한 동시성 모델부터 시작해 보겠습니다. 하나는 다른 하나 가 읽거나 쓰는 데이터에 쓰면 (그리고 그 반대로도) 두 트랜잭션은 서로 분리되어야합니다 .

트랜잭션이 데이터를 읽는 이유를 모르는 경우 다른 값 읽기가 관련된 클라이언트의 동작을 변경시킬 수 있다고 가정해야하므로 트랜잭션이 겹치는 조건이 분리를 나타냅니다. 격리하지 않으면 스냅 샷에서 오래된 데이터를 읽을 때 일관성이 떨어지는 완화를 쉽게 나타낼 수 있는데, 다른 용어는 불일치, 즉 오류입니다.

트랜잭션이 읽거나 쓴 정확한 데이터 만 고려하면되며 해당 세트 외부의 데이터는 고려할 필요가 없습니다. 그러나 트랜잭션에서 읽은 데이터에 대해 이야기 할 때 반드시 모든 "메타"데이터 (및 제약 조건 검사와 같은 메타 작업에서 읽은 데이터 및 메타 데이터)를 반드시 포함해야한다는 것을 인식하는 것이 중요합니다. 메타 데이터의 예는 다음과 같습니다. / 메타 작업 : 고유 한 새 기본 키 식별; 다른 하나는 전체 열의 합입니다. 다른 하나는 무언가를 찾고 찾지 않는 것입니다. 범위 검색 또는 합계. 이것은 중복을 방지하는 것에 대한 @Matthew의 의견과 @Tersosauros 답변으로 상태를 고려합니다.

예를 들어, 키 제약 조건을 확인하는 것이 전체 기본 키 열을 읽는 것과 동의어이므로 두 트랜잭션이 모두 고유 한 기본 키 제약 조건을 가정하여 행을 삽입 할 때 두 트랜잭션이 겹치게됩니다 (분리 필요). 다른 예로, 무언가를 찾아서 찾는 것은 하나의 값을 읽는 것과 같지만, 그것을 찾지 못하는 것은 열의 모든 값을 보는 것과 같습니다.

MVCC는 겹치거나 충돌하는 쓰기에 대해서만 보호하지만 읽기에 대해서는 보호하지 않습니다 (해당 트랜잭션에 의해 쓰여지지 않은 경우). 따라서 MVCC에서 일관성 오류를 얻으려면 다른 트랜잭션에 의해 변경된 것을 읽으십시오 (다른 트랜잭션은 전자의 스냅 샷을 얻은 후 커밋하지만 먼저 커밋). 다른 트랜잭션은 오래된 데이터를 계속 사용합니다. 최신 데이터와 비교했을 때 오래된 데이터를 기반으로 결정을 다르게합니다. 생각보다 원인이 더 쉽습니다.

편안한 일관성은 잠재적으로 일관성이 없거나 오류가 발생하기 쉬운 방법입니다. 완화 된 일관성은 최종 일관성과 혼동되어서는 안됩니다. 이는 "NoSQL"에서 자주 발생하는 다른 형식의 오류입니다.

귀하의 질문에 따르면 트랜잭션이 둘 이상의 객체에 걸쳐있을 필요가 없다고 말할 때 일관성 확인, 전체 열 집계, 부재 확인, 범위 검색 등을 포함한 메타 데이터 (및 메타 작업)에 읽기 및 쓰기 모두에 적용되어야합니다. . : 그렇다면 지금까지 너무 좋습니다.

하나...

귀하의 질문에서 개별 객체 (예 : 객체 잠금이 아닌)에서 스냅 샷 격리 (MVCC)를 사용하고 있습니다. (또한 CAS를 언급했습니다. 비교 및 ​​스왑에 대해 들었고 테스트 및 설정에 대해 들었지만 확인 및 설정은하지는 않았지만 비슷하다고 가정합니다).

귀하의 질문에 따르면 "객체"에 둘 이상의 필드가 있다고 제안합니다. 그렇지 않으면 질문의 규정이 필요하지 않습니다.

따라서 스냅 샷 처리 / MVCC 처리 객체에는 둘 이상의 필드가 있으므로 단일 객체 내에서 기울어 짐이 발생하기 쉽습니다. 두 트랜잭션이 동시에 동일한 오브젝트를 업데이트하는 경우, 동일한 오브젝트에서 동시에 다른 트랜잭션에 의해 오래된 오브젝트 값 필드를 읽은 후 잠재적 불일치 (일명 오류)를 알 수 없습니다.

대신 객체 잠금을 사용할 수 있습니다. 이렇게하면 다른 트랜잭션이 이미 처리중인 경우 두 트랜잭션 (업데이트 용)이 동일한 객체를 보지 못하게됩니다.

MVCC의 깨진 쓰기 세트 전용 비교 모델을 사용하지 않고 다른 형태의 스냅 샷 격리를 수행 할 수 있다고 생각합니다. 따라서 읽기 세트를 포함하도록 비교 세트를 쓰기 전용에서 (알고리즘 방식으로) 승격시킬 수 있습니다. 그런 다음 동일한 객체를 업데이트하는 두 개의 트랜잭션으로 인해 쓰기 왜곡이 발생할 수 없습니다 (나중에 커밋을 시도하는 트랜잭션이 중단되기 때문에). 다중 객체 트랜잭션을 배제함으로써 MVCC가 우리에게 구매할 수있는 대부분의 혜택을 이미 얻고 있기 때문에 이것이 설명하는 문제에 대한 적절한 해결책 일 수 있습니다.

(읽거나 쓴 정확한 특정 항목 / 필드 만 고려하면되지만 메타 연산 중에는 잠재적으로 쓰기 왜곡 (예 : 오류)을 방지하기 위해 메타 데이터로 읽어야합니다. 비교 세트에서 읽기 세트를 제거하는 경우 메타 데이터 (메타 작업에서 잠재적으로 사용됨)를 고려하지 않으면 오류를 허용하는 모델이 있습니다.)

나는 같은 생각 @ pjc50 , 진술 ^{강조 추가 (:)} " 경우 다음"대답은 '예'트랜잭션이 단일 개체를 읽기 / 쓰기 제한됩니다. " 그러나 이것이 떨어지는 곳은 단일 대상 이라는 생각입니다 .

스냅 샷 격리 에서 가져온 예에서 T1 및 T2는 값을 공유하지 않습니다. 그러나, 그들은 여전히 쓰기 스큐의 가능성 때문에 " 어느 [가] 업데이트가 다른 수행 볼 " ^소스 . 따라서 그것은이다 능력이 다른 모든 업데이트를 볼 수있는 트랜잭션의 커밋하기 전에 그 트랜잭션이 진정으로 직렬화한다은.

에서 직렬화 :

스케줄의 직렬화 가능성은 동일한 트랜잭션의 직렬 스케줄 (즉, 트랜잭션이 시간이 중첩되지 않은 순차적)과 동등 함 (결과, 데이터베이스 상태, 데이터 값)을 의미합니다.

불행하게도,이 때문에 (그리고 @Matthew Mark Miller가 지적한 바와 같이 ), 우리는 상태 뿐만 아니라 가치 도 고려해야 합니다. 이 점을 고려하면 OCC를 사용하는 두 트랜잭션 은 데이터베이스 상태가 기록 될 때마다 쓰기 불균형이 발생할 수 있습니다 .