카우치베이스 함수에서 주문하기 - 1부

카우치베이스 함수는 소개 의 Couchbase Server 5.5 릴리스에서 카우치베이스 이벤트 서비스. 카우치베이스 함수는 데이터 기반 비즈니스 로직을 데이터에 더 가깝게 이동할 수 있는 기능을 제공합니다. 웹 및 엣지 애플리케이션에서 발생하는 상호 작용의 결과로 데이터가 변경되면 사용자 정의 비즈니스 로직이 서버에서 실시간으로 트리거될 수 있습니다. 컴퓨팅이 데이터에 더 가까이 있을 때는 수신 중인 데이터가 변경될 때 컴퓨팅이 어떻게 작동하는지 이해하는 것이 중요합니다. 이벤트 서비스가 돌연변이 순서에 따라 어떻게 반응하는지 이해해 보겠습니다.

간단한 예제를 통해 동작을 이해해 보겠습니다. 다음 코드를 사용하여 테스트 함수를 만들고 함수에 대한 기본 설정(즉, 워커 3명)을 가정해 보겠습니다.

참고: 함수 배포 중 아래의 모든 작업에서 피드 경계에서 '모든 것'을 선택합니다.

이 함수가 수신하는 소스 버킷에 문서 ID가 증가하는 문서 10개 정도를 삽입해 봅시다. 이 함수에 대한 애플리케이션 로그 파일에서 다음 항목과 비슷한 내용을 볼 수 있습니다.

 T위의 함수를 언디플로이하고 배포하면 ID(/변경)의 순서가 동일하지 않은 것을 관찰할 수 있습니다. 이 단계를 몇 번 반복하여 이 관찰을 강화할 수 있습니다.

테이크아웃#1 : 문서가 삽입된 순서대로 처리되지 않는 기능입니다.

이제 삽입된 문서 중 하나를 삭제해 보겠습니다(이 예에서는 DocId#2를 삭제했습니다). 로그에서 즉시 다음 항목이 관찰됩니다(올바른 항목):

이제 함수를 배포 취소하고 다시 배포해 보겠습니다. 다음 순서를 준수합니다:

우리는 그것을 관찰합니다:

• "생성된 문서 ID:" "2"가 누락되었습니다.
• "삭제된 문서 ID:" "2"는 처리 순서에서 후자가 아닌 앞에 나타납니다.

테이크아웃#2 : 중복 제거

문서에 대한 연속적인 작업(/변경/변형)은 디스크와 메모리의 오버헤드를 최소화하기 위해 빠른 속도로 연속적으로 발생하는 경우 Couchbase Server에서 병합(중복 제거)됩니다. 카우치베이스 서버는 DCP 스트림에서 문서의 최신 버전만 전송합니다.

위의 예제에서 문서에 대한 작업 순서에서 가장 늦게 발생한 문서 ID 삭제가 OnUpdate 핸들러가 트리거되지 않는 이유는 업데이트와 삭제가 순서대로 발생하면 타임라인에서 나중에 발생한 삭제로 합쳐지기 때문입니다. 즉, 문서에 대한 여러 업데이트(또는 단일 업데이트)가 발생한 후 문서가 삭제되면 업데이트가 최종 이벤트, 즉 문서의 삭제에 병합되므로 Couchbase 함수에서는 삭제 이벤트만 표시됩니다.

문서가 작은 창에서 여러 번 업데이트된 후 함수가 변경 내용을 사용하는 경우에도 비슷한 동작이 나타나며, 문서에 발생한 최신 변경 내용만 표시되고 중간 변경 내용은 손실됩니다. 이는 버킷에 많은 변경 사항이 있는 기존 버킷에 새 함수가 배포된 경우에만 해당됩니다.

함수가 배포되고 문서에 변경 사항이 발생하면 각 변경 사항은 함수에 의해 처리됩니다. 그러나 짧은 시간 간격으로 문서에 발생하는 변경 사항의 수가 매우 많은 경우 Couchbase Server는 여전히 어느 정도의 중복 제거를 수행하며, 이로 인해 모든 변경 사항이 함수를 트리거하지 않을 수도 있습니다.

즉, 10개의 문서가 삽입되고 그 중 하나가 삭제된 경우 함수가 배포될 때 삭제 작업(삽입된 문서와 삭제된 문서)이 함수에 의해 마지막에 표시되는 것은 보장할 수 없습니다.

테이크아웃#3 : 함수가 돌연변이를 수행한 순서대로 처리하지 않습니다.

여기서 무슨 일이 일어나고 있는 걸까요? In 파트 2 블로그 시리즈에서는 카우치베이스 이벤트 서비스의 내부를 자세히 살펴보고 이벤트 워커가 돌연변이를 처리하는 방식을 이해해 보겠습니다.