InterSystems IRIS 글로벌의 트랜잭션

InterSystems IRIS DBMS는 데이터 저장을 위한 흥미로운 구조인 전역을 지원합니다. 본질적으로 이는 트랜잭션 형태의 다양한 추가 기능, 데이터 트리 탐색을 위한 빠른 기능, 잠금 및 자체 ObjectScript 언어가 포함된 다중 레벨 키입니다.

"전역은 데이터 저장을 위한 보물검입니다"라는 기사 시리즈에서 전역에 대해 자세히 알아보세요.

나무. 1 부
나무. 2 부
희소 배열. 3부

저는 글로벌에서 트랜잭션이 어떻게 구현되는지, 어떤 기능이 있는지에 관심을 갖게 되었습니다. 결국 이것은 일반적인 테이블과 데이터를 저장하는 구조가 완전히 다릅니다. 훨씬 낮은 수준입니다.

관계형 데이터베이스 이론에서 알 수 있듯이 트랜잭션을 제대로 구현하려면 다음 요구 사항을 충족해야 합니다. ACID:

A - 원자성(원자성). 거래의 모든 변경 사항이 기록되거나 전혀 기록되지 않습니다.

C - 일관성. 트랜잭션이 완료된 후 데이터베이스의 논리적 상태는 내부적으로 일관성이 있어야 합니다. 여러 면에서 이 요구 사항은 프로그래머와 관련이 있지만 SQL 데이터베이스의 경우 외래 키에도 관련됩니다.

나 - 격리하다. 병렬로 실행되는 트랜잭션은 서로 영향을 주어서는 안 됩니다.

D - 내구성. 트랜잭션이 성공적으로 완료된 후 낮은 수준의 문제(예: 정전)가 트랜잭션에 의해 변경된 데이터에 영향을 주어서는 안 됩니다.

전역은 비관계형 데이터 구조입니다. 매우 제한된 하드웨어에서 매우 빠르게 실행되도록 설계되었습니다. 다음을 사용하여 전역에서 트랜잭션 구현을 살펴보겠습니다. 공식 IRIS 도커 이미지.

IRIS에서 트랜잭션을 지원하기 위해 다음 명령이 사용됩니다. 티스타트, TCOMMIT, 트롤백.

1. 원자성

확인하는 가장 쉬운 방법은 원자성입니다. 데이터베이스 콘솔에서 확인합니다.

Kill ^a
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TCOMMIT

그런 다음 결론을 내립니다.

Write ^a(1), “ ”, ^a(2), “ ”, ^a(3)

우리는 얻는다 :

1 2 3

모든 것이 괜찮습니다. 원자성은 유지됩니다. 모든 변경 사항이 기록됩니다.

작업을 복잡하게 만들고, 오류를 발생시키고, 트랜잭션이 부분적으로 또는 전혀 저장되지 않는 방법을 살펴보겠습니다.

원자성을 다시 확인해 보겠습니다.

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3

그런 다음 컨테이너를 강제로 중지하고 실행한 후 살펴보겠습니다.

docker kill my-iris

이 명령은 프로세스를 즉시 중지하기 위해 SIGKILL 신호를 보내기 때문에 강제 종료와 거의 동일합니다.

거래가 부분적으로 저장되었을 수도 있나요?

WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)

- 아니요, 살아남지 못했습니다.

롤백 명령을 시도해 보겠습니다.

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TROLLBACK

WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)

아무것도 살아남지 못했습니다.

2. 일관성

전역을 기반으로 하는 데이터베이스에서는 키도 전역에서 생성되므로(전역은 관계형 테이블보다 데이터를 저장하기 위한 하위 수준 구조라는 점을 상기시켜 주세요) 일관성 요구 사항을 충족하려면 키의 변경 사항이 포함되어야 합니다. 전역 변경과 동일한 트랜잭션에서.

예를 들어, 개인 정보를 저장하고 TIN을 키로 사용하는 글로벌 ^사람이 있습니다.

^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
...

성과 이름으로 빠른 검색을 하기 위해 ^index 키를 만들었습니다.

^index(‘Kamenev’, ‘Sergey’, 1234567) = 1

데이터베이스의 일관성을 유지하려면 다음과 같이 페르소나를 추가해야 합니다.

TSTART
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1
TCOMMIT

따라서 삭제할 때 트랜잭션도 사용해야 합니다.

TSTART
Kill ^person(1234567)
ZKill ^index(‘Kamenev’, ‘Sergey’, 1234567)
TCOMMIT

즉, 일관성 요구 사항을 충족하는 것은 전적으로 프로그래머의 어깨에 달려 있습니다. 그러나 글로벌의 경우 낮은 수준의 특성으로 인해 이는 정상적인 현상입니다.

3. 격리

이곳이 야생이 시작되는 곳입니다. 많은 사용자가 동일한 데이터베이스에서 동시에 작업하여 동일한 데이터를 변경합니다.

상황은 많은 사용자가 동일한 코드 저장소로 동시에 작업하고 한 번에 여러 파일에 대한 변경 사항을 동시에 커밋하려고 하는 경우와 비슷합니다.

데이터베이스는 모든 것을 실시간으로 정렬해야 합니다. 진지한 회사에는 버전 관리(브랜치 병합, 충돌 해결 등)를 담당하는 특별한 사람도 있고 데이터베이스는 이 모든 작업을 실시간으로 수행해야 하며 작업의 복잡성과 정확성을 고려합니다. 이를 제공하는 데이터베이스 설계 및 코드.

데이터베이스는 사용자가 동일한 데이터에 대해 작업하는 경우 충돌을 피하기 위해 사용자가 수행하는 작업의 의미를 이해할 수 없습니다. 다른 트랜잭션과 충돌하는 트랜잭션 하나만 실행 취소하거나 순차적으로 실행할 수 있습니다.

또 다른 문제는 트랜잭션 실행 중(커밋 전) 데이터베이스 상태가 일관되지 않을 수 있으므로 다른 트랜잭션이 관계형 데이터베이스에서 달성되는 데이터베이스의 일관되지 않은 상태에 액세스하지 않는 것이 바람직하다는 것입니다. 다양한 방법: 스냅샷 생성, 행 다중 버전 관리 등

트랜잭션을 병렬로 실행할 때 서로 간섭하지 않는 것이 중요합니다. 이것이 고립의 속성이다.

SQL은 4가지 격리 수준을 정의합니다.

• 커밋되지 않은 읽기
• 커밋 된 읽기
• 반복 읽기
• 직렬화 가능

각 레벨을 개별적으로 살펴보겠습니다. 각 수준을 구현하는 데 드는 비용은 거의 기하급수적으로 증가합니다.

커밋되지 않은 읽기 - 이는 가장 낮은 격리 수준이지만 동시에 가장 빠릅니다. 트랜잭션은 서로 변경된 내용을 읽을 수 있습니다.

커밋 된 읽기 격리의 다음 단계인 절충안입니다. 트랜잭션은 커밋 전에는 서로의 변경 사항을 읽을 수 없지만 커밋 후에는 변경 사항을 읽을 수 있습니다.

T1과 동일한 데이터로 작업한 트랜잭션 T2, T3 ... Tn에서 커밋이 발생한 긴 트랜잭션 T1이 있는 경우 T1에서 데이터를 요청할 때 매번 다른 결과를 얻게 됩니다. 이러한 현상을 반복 불가능 읽기라고 합니다.

반복 읽기 — 이 격리 수준에서는 데이터 읽기 요청이 있을 때마다 결과 데이터의 스냅샷이 생성되고 동일한 트랜잭션에서 재사용될 때 스냅샷의 데이터가 생성되므로 반복 불가능한 읽기 현상이 없습니다. 사용. 그러나 이 격리 수준에서는 팬텀 데이터를 읽을 수 있습니다. 이는 병렬 커밋된 트랜잭션에 의해 추가된 새 행을 읽는 것을 의미합니다.

직렬화 가능 - 최고 수준의 절연. 트랜잭션에서 어떤 방식으로든 사용된 데이터(읽기 또는 변경)는 첫 번째 트랜잭션이 완료된 후에만 다른 트랜잭션에서 사용할 수 있다는 사실이 특징입니다.

먼저, 트랜잭션의 작업이 메인 스레드로부터 격리되어 있는지 살펴보겠습니다. 2개의 터미널 창을 열어보겠습니다.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

고립은 없습니다. 한 스레드는 트랜잭션을 연 두 번째 스레드가 무엇을 하고 있는지 확인합니다.

서로 다른 스레드의 트랜잭션이 내부에서 무슨 일이 일어나고 있는지 살펴보겠습니다.

2개의 터미널 창을 열고 2개의 트랜잭션을 병렬로 열어보겠습니다.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

병렬 트랜잭션은 서로의 데이터를 봅니다. 그래서 우리는 가장 간단하면서도 가장 빠른 격리 수준인 READ UNCOMMITED를 얻었습니다.

원칙적으로 이는 항상 성능이 최우선인 글로벌 기업에서 예상할 수 있는 일입니다.

전역 작업에 더 높은 수준의 격리가 필요한 경우 어떻게 해야 합니까?

여기에서는 격리 수준이 필요한 이유와 작동 방식에 대해 생각해 볼 필요가 있습니다.

가장 높은 격리 수준인 SERIALIZE는 병렬로 실행된 트랜잭션의 결과가 순차 실행과 동일하여 충돌이 없음을 보장함을 의미합니다.

다양한 용도로 사용되는 ObjectScript의 스마트 잠금을 사용하여 이 작업을 수행할 수 있습니다. 다음 명령을 사용하여 일반, 증분, 다중 잠금을 수행할 수 있습니다. 잠그다.

낮은 격리 수준은 데이터베이스 속도를 높이기 위해 설계된 절충안입니다.

잠금을 사용하여 다양한 격리 수준을 달성하는 방법을 살펴보겠습니다.

이 연산자를 사용하면 데이터를 변경하는 데 필요한 배타적 잠금뿐만 아니라 읽기 프로세스 중에 다른 프로세스에 의해 변경되어서는 안 되는 데이터를 읽어야 할 때 여러 스레드를 병렬로 사용할 수 있는 소위 공유 잠금을 사용할 수 있습니다.

러시아어 및 영어로 된 XNUMX단계 차단 방법에 대한 추가 정보:

→ XNUMX단계 차단
→ XNUMX단계 잠금

어려운 점은 트랜잭션 중에 데이터베이스 상태가 일관되지 않을 수 있지만 이 일관되지 않은 데이터가 다른 프로세스에 표시된다는 것입니다. 이것을 피하는 방법?

잠금을 사용하여 데이터베이스 상태가 일관되게 유지되는 가시성 창을 만듭니다. 그리고 합의된 상태의 공개 창에 대한 모든 액세스는 잠금 장치로 제어됩니다.

동일한 데이터에 대한 공유 잠금은 재사용이 가능하므로 여러 프로세스에서 이를 사용할 수 있습니다. 이러한 잠금은 다른 프로세스가 데이터를 변경하는 것을 방지합니다. 이는 일관된 데이터베이스 상태의 창을 형성하는 데 사용됩니다.

배타적 잠금은 데이터 변경에 사용됩니다. 단 하나의 프로세스만이 이러한 잠금을 사용할 수 있습니다. 배타적 잠금은 다음 방법으로 수행할 수 있습니다.

1. 데이터가 무료인 경우 모든 프로세스
2. 이 데이터에 대한 공유 잠금이 있고 배타적 잠금을 가장 먼저 요청한 프로세스만 해당됩니다.

가시성 창이 좁을수록 다른 프로세스가 이를 기다려야 하는 시간이 길어지지만 그 안에 있는 데이터베이스의 상태는 더 일관될 수 있습니다.

READ_COMMITTED — 이 수준의 핵심은 다른 스레드에서 커밋된 데이터만 볼 수 있다는 것입니다. 다른 트랜잭션의 데이터가 아직 커밋되지 않은 경우 이전 버전이 표시됩니다.

이를 통해 잠금이 해제될 때까지 기다리지 않고 작업을 병렬화할 수 있습니다.

특별한 트릭이 없으면 IRIS에서 이전 버전의 데이터를 볼 수 없으므로 잠금을 설정해야 합니다.

따라서 일관성이 있는 순간에만 데이터를 읽을 수 있도록 공유 잠금을 사용해야 합니다.

서로 돈을 이체하는 사용자 기반 ^사람이 있다고 가정해 보겠습니다.

123번 사람에서 242번 사람으로 이동하는 순간:

LOCK +^person(123), +^person(242)
Set ^person(123, amount) = ^person(123, amount) - amount
Set ^person(242, amount) = ^person(242, amount) + amount
LOCK -^person(123), -^person(242)

인출 전 123번 사람에게 금액을 요청하는 순간에는 전용 블록이 동반되어야 합니다(기본적으로).

LOCK +^person(123)
Write ^person(123)

개인 계정에 계정 상태를 표시해야 하는 경우 공유 잠금을 사용하거나 전혀 사용하지 않을 수 있습니다.

LOCK +^person(123)#”S”
Write ^person(123)

그러나 데이터베이스 작업이 거의 즉시 수행된다고 가정하면(전역은 관계형 테이블보다 훨씬 낮은 수준의 구조라는 점을 상기시켜 드리겠습니다) 이 수준에 대한 필요성이 줄어듭니다.

반복 읽기 - 이 격리 수준은 동시 트랜잭션에 의해 수정될 수 있는 데이터의 다중 읽기를 허용합니다.

따라서 변경하는 데이터 읽기에는 공유 잠금을 설정하고 변경하는 데이터에는 배타적 잠금을 설정해야 합니다.

다행스럽게도 LOCK 연산자를 사용하면 필요한 모든 잠금(많을 수 있음)을 하나의 명령문에 자세히 나열할 수 있습니다.

LOCK +^person(123, amount)#”S”
чтение ^person(123, amount)

기타 작업(현재 병렬 스레드는 ^person(123, amount)을 변경하려고 시도하지만 변경할 수 없음)

LOCK +^person(123, amount)
изменение ^person(123, amount)
LOCK -^person(123, amount)

чтение ^person(123, amount)
LOCK -^person(123, amount)#”S”

쉼표로 구분된 잠금을 나열하면 순차적으로 사용되지만 이렇게 하면 다음과 같습니다.

LOCK +(^person(123),^person(242))

그런 다음 원자적으로 한 번에 가져옵니다.

직렬화 — 궁극적으로 공통 데이터가 있는 모든 트랜잭션이 순차적으로 실행되도록 잠금을 설정해야 합니다. 이 접근 방식의 경우 대부분의 잠금은 배타적이어야 하며 성능을 위해 전역의 가장 작은 영역에서 수행되어야 합니다.

글로벌 ^사람의 차변 자금에 대해 이야기하는 경우 돈은 엄격하게 순차적으로 지출되어야 하기 때문에 SERIALIZE 격리 수준만 허용됩니다. 그렇지 않으면 동일한 금액을 여러 번 지출할 수 있습니다.

4. 내구성

용기를 하드컷팅하여 테스트를 진행했습니다.

docker kill my-iris

기지는 그들을 잘 견뎌냈습니다. 아무런 문제도 확인되지 않았습니다.

결론

글로벌의 경우 InterSystems IRIS는 트랜잭션을 지원합니다. 그들은 진정으로 원자적이고 신뢰할 수 있습니다. 글로벌 기반 데이터베이스의 일관성을 보장하려면 외래 키와 같은 복잡한 내장 구조가 없기 때문에 프로그래머의 노력과 트랜잭션 사용이 필요합니다.

잠금을 사용하지 않는 전역의 격리 수준은 READ UNCOMMITED이며, 잠금을 사용할 경우 SERIALIZE 수준까지 보장할 수 있습니다.

전역 트랜잭션의 정확성과 속도는 프로그래머의 기술에 크게 좌우됩니다. 읽을 때 더 널리 공유된 잠금을 사용할수록 격리 수준이 높아지고, 더 좁은 범위의 배타적 잠금을 사용할수록 성능이 더 빨라집니다.

출처 : habr.com