거래

N1QL을 통한 분산 트랜잭션의 사용 사례 및 모범 사례

카우치베이스는 트랜잭션을 지원하나요?

예! 6.5 버전에서는 산 거래 SDK를 통해 카우치베이스에서 지원됩니다. 1st 당시 이 소식을 접한 고객들로부터 받은 질문은 다음과 같았습니다:

N1QL을 통해 트랜잭션 지원을 받을 수 있나요?

예! 7.0에서는 N1QL을 통한 트랜잭션도 지원하기 시작했습니다!N1QL 트랜잭션은 멀티에브리씽입니다. 여러 버킷 내의 여러 범위에서 여러 컬렉션을 아우를 수 있는 다중 문서입니다. 단일 쿼리 노드에서 여러 트랜잭션을 실행할 수 있고 여러 쿼리 노드를 가질 수 있습니다. 중앙 코디네이터가 없으므로 단일 장애 지점이나 경합을 없애고 무한한 확장성을 확보할 수 있습니다!

N1QL이란 무엇이며 Couchbase에 왜 그렇게 중요한가요?

SQL이 RDBMS에 있는 것처럼, N1QL은 Couchbase에 있습니다!

N1QL 는 선언적 언어로, SQL과 거의 동일하며 JSON 문서 형태로 저장된 데이터를 삽입/검색하고 조작하는 데 사용됩니다.N1QL에 대해 자세히 알아보기 여기 .

N1QL이 SQL과 같다면 왜 이전에는 ACID가 없었을까요?

N1QL에는 항상 단일 문서 내에 ACID가 있었습니다. 7.0 이전에는 없었던 것이 바로 N1QL을 통한 다중 문서 트랜잭션 지원입니다.

먼저 왜 많은 사람들이 다중 문서 트랜잭션이 필요하다고 생각하는지 생각해 봅시다. 관계형 데이터 모델링의 첫 번째 원칙은 테이블 간에 데이터를 정규화하는 것입니다. 즉, 계정 생성과 같은 많은 일반적인 데이터베이스 작업에는 많은 행과 열에 걸쳐 원자적인 업데이트가 필요합니다.

Couchbase에서는 데이터 모델이 근본적으로 다릅니다. 문서 모델은 사용자가 관련 데이터를 단일 문서에 함께 저장하도록 권장합니다. N1QL은 항상 단일 문서에서 ACID 트랜잭션을 지원해 왔으며, 문서 모델을 적절히 활용하면 많은 애플리케이션에서 여러 문서에 걸쳐 ACID 보장이 필요하지 않습니다. 아래 그림과 같이 PK-FK로 연결된 3개의 서로 다른 테이블에 저장해야 하는 데이터가 Couchbase의 단일 문서에 저장됩니다.  

예: 장바구니에 품목 추가하기 는 단일 문서만 업데이트하므로 Couchbase에서 트랜잭션이 필요하지 않습니다.

하지만 트랜잭션은 단순한 체크박스가 아닙니다. 트랜잭션은 모든 카우치베이스 기능과 마찬가지로 개발자의 삶을 더 쉽게 만드는 것을 목표로 합니다. 문서 전반에 걸친 ACID 보증은 복잡한 애플리케이션을 충족하는 데 필요한 애플리케이션 로직을 간소화합니다.

다중 문서 트랜잭션의 사용 사례는 무엇인가요?:

여러 문서에 걸쳐 있는 일련의 작업에 트랜잭션 ACID 보장을 적용해야 하는 사용 사례가 있습니다. "시스템 오브 레코드" 애플리케이션은 다중 문서 트랜잭션이 유용한 일반적인 워크로드 유형입니다. 예를 들면 다음과 같습니다:

  • 사용자가 반복하면 다른 결과를 초래할 수 있으므로 모두 성공하거나 모두 실패해야 하는 작업을 수행할 때 애플리케이션 이벤트를 처리합니다. 예를 들어 일반적인 은행 직불, 신용.
  • 사용자 지정 애플리케이션 작업 로깅 - 사용자가 자동차나 집의 소유권을 이전할 때와 같이 시스템 장애가 발생해도 되돌릴 수 없는 경우, 로깅이 되지 않으면 쓰기가 성공하지 않아야 합니다.
  • 고객, 고객 주문, 제품 및 제조업체와 같이 데이터가 정의된 객체에 자연스럽게 들어맞는 다대다 관계입니다. 고객 주문의 합계를 계산하려면 각 테이블의 값을 수집하고 모든 고객에 대해 합산해야 합니다.

 

카우치베이스에서 N1QL을 통한 트랜잭션에 대한 세부 정보:

간단한 거래, 직불 및 신용으로 N1QL 트랜잭션에 대해 자세히 알아보겠습니다. 선택 항목은 자체 업데이트(RYOW)를 읽어야 합니다.

거래를 시작합니다;

업데이트 고객 SET 잔액 = 잔액 - 100 WHERE cid = 4872;

업데이트 고객 SET 잔액 = 잔액 + 100 WHERE cid = 1924;

SELECT 고객에서 cid, 이름, 잔액에서 cid가 [4872,1924]인 경우;

COMMIT ;

이것은 MySQL에서 작성하는 것과 동일한 구문입니다. 이것이 바로 N1QL의 장점입니다.

이미 SQL에 익숙하다면 Couchbase를 사용하기 위해 새로운 언어를 배울 필요가 없습니다.

위의 예시에서,

Couchbase의 아키텍처에 이미 익숙하다면 다음과 같이 하세요.

  • 트랜잭션 시작은 쿼리 노드로 이동합니다. 쿼리 노드는 이 트랜잭션에 고유한 트랜잭션 ID(txid)를 할당합니다.

  • 다음은 업데이트 문입니다. 쿼리 노드는 where 절을 살펴보고, 쿼리를 처리할 적절한 인덱스를 선택하고, 문서 ID를 찾고, 문서 ID를 데이터 저장소(KV)로 전송하고, 문서를 쿼리 노드로 가져온 다음 잔액을 업데이트합니다. 만약 이것이 트랜잭션 내에 있지 않았다면, 이것은 즉시 데이터 저장소로 다시 전송될 것입니다. 하지만 트랜잭션 내에 있으므로 이제 이 문서는 쿼리 노드의 캐시에 저장됩니다. 이 캐시를 델타 테이블이라고 합니다. 컬렉션당 트랜잭션당 1개의 델타 테이블이 있습니다. 그렇기 때문에 트랜잭션의 모든 문이 동일한 쿼리 노드로 오도록 해야 합니다. 이 스티칭은 START TRANSACTION에서 제공하는 txid로 수행됩니다.
  • 다음 업데이트에서는 동일하게 쿼리 노드가 where 절을 살펴보고 쿼리를 처리할 적절한 인덱스를 선택한 후 문서 ID를 찾지만, 이제는 델타 테이블이 있기 때문에 직접 KV로 이동하여 문서를 가져오는 대신 델타 테이블에 이 문서가 이미 존재하는지 먼저 델타 테이블을 찾습니다. 이 경우에는 존재하지 않으므로 KV에서 가져와 잔액을 업데이트한 후 델타 테이블에 저장합니다.
  • 다음은 쿼리 노드에 select 문을 입력합니다. 다시 쿼리 노드는 where 절을 살펴보고, 쿼리를 처리할 적절한 인덱스를 선택하고, 문서 ID를 찾습니다. 이제 델타 테이블에서 문서 ID를 찾아서 거기서 찾은 다음 예상 필드를 클라이언트로 다시 보냅니다.

  • 지금까지 데이터 저장소에서 읽기는 했지만 데이터 저장소에 쓰기는 하지 않았습니다. 쿼리 노드의 캐시에만 썼습니다. 따라서 우리는 낙관적 동시성을 따른다고 말합니다. 동일한 문서에 대해 여러 트랜잭션이 동시에 작동할 수 있습니다.
  • 이제 다음 문이 쿼리 노드 "COMMIT"에 도달하면 업데이트된 문서가 KV 노드로 이동하고 강조 표시된 커밋 프로토콜을 사용합니다. 여기 를 사용하여 실제로 변경 사항을 커밋합니다. 
  • 이 시점에서 동일한 문서를 업데이트하는 트랜잭션이 여러 개 있으면 하나는 성공하고 다른 트랜잭션은 롤백되어 다시 시도해야 합니다.

N1QL 트랜잭션 모범 사례 :

N1QL 트랜잭션은 언제 사용해야 하나요?
  1. 모두 통과하거나 모두 실패해야 하는 쿼리 문이 여러 개 있는 경우(일반적인 예: 직불 크레딧, 다구간 항공권 예약)
  2. 집/자동차 소유권 이전과 같이 시스템 충돌이 발생하더라도 한 번 변경한 내용을 되돌리지 않으려는 경우.
  3. 필요한 로직이 단일 문서로 병합할 수 없고 여러 문서에 대한 업데이트가 필요한 데이터에 걸쳐 있는 경우.
  4. 일반적으로 대규모 집계가 아닌 작은 결과 집합을 포함하는 매우 단기 실행 워크로드입니다.
  5. 같은 문서를 반복해서 수정/읽어야 할 때(델타 테이블을 사용하여 직접 쓰기에서 지원됨)
N1QL 트랜잭션을 사용하는 동안 피해야 할 행동은 무엇인가요?

위의 간단한 예시만 봐도 그 사실을 알 수 있습니다:

  1. 델타 테이블(트랜잭션당/컬렉션당)은 모든 돌연변이에 따라 증가합니다. 변이가 많은 트랜잭션이 있는 경우 메모리 사용량이 증가합니다. 따라서 트랜잭션 내에서 변이 횟수를 제한하는 것이 좋습니다. ETL과 같은 로드 또는 ACID 보장이 필요한 대규모 업데이트의 경우, 암시적 트랜잭션이라는 또 다른 옵션을 제공합니다. 이에 대한 자세한 내용은 다음을 참조하세요. 여기쿼리 서비스의 "memory-quota" 설정으로 델타 테이블이 사용하는 메모리 양을 제어할 수 있습니다.
  2. 10MB 미만의 문서에 대해서만 트랜잭션을 사용합니다.
  3. 다음을 포함하지 마십시오. DDL 작업 을 사용할 수 없습니다. 모든 DDL 작업은 오류가 발생합니다.
  4. 기본적으로 시간 제한은 15초입니다. 이는 N1QL 트랜잭션을 사용하는 수단(cbq 셸, UI, Java SDK 또는 REST API)에 따라 수정할 수 있습니다.
  5. 쿼리 서비스는 트랜잭션의 영향을 받을 수 있는 높은 처리량과 짧은 지연 시간을 제공하도록 설계되었습니다. 사용 사례에 트랜잭션이 필요한 경우 N1QL 트랜잭션을 사용하세요.
  6. 우리는 낙관적인 동시성을 사용하기 때문에 대부분의 워크로드에서 여러 트랜잭션이 동시에 동일한 문서를 수정하지 않도록 해야 합니다. 이 경우 하나는 성공하고 다른 하나는 'CAS 불일치' 또는 '쓰기 충돌' 오류로 롤백될 수 있기 때문입니다.
  7. 트랜잭션과 비트랜잭션을 동시에 사용하여 동일한 문서를 수정해서는 안 됩니다.

트랜잭션의 작동 방식을 이해하려면 거래 시뮬레이터

N1QL을 통한 트랜잭션 지원에 대해 자세히 알아보기

https://www.couchbase.com/blog/transactions-n1ql-couchbase-distributed-nosql/

https://www.couchbase.com/blog/couchbase-transactions-with-n1ql/

https://docs.couchbase.com/java-sdk/current/howtos/distributed-acid-transactions-from-the-sdk.html#n1ql-queries

 

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 카미니 자그티아니

카미니 자그티아니는 카우치베이스 R&D의 쿼리팀 수석 엔지니어링 매니저입니다. Couchbase에 입사하기 전에는 Futurewei에서 커널 아키텍트/관리자로 7년, IBM Informix에서 소프트웨어 엔지니어로 13년 동안 근무했습니다. 카미니는 인도 봄베이 대학교에서 컴퓨터 과학 및 공학 학사 학위를 받았으며 5개의 미국 특허를 보유하고 있습니다.

댓글 하나

  1. 클라렌스 타우로 2월 27, 2021에서 12:13 오후

    잘 읽었습니다...

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.