변경 피드를 어떻게 이용합니까?

단일 데이터베이스 orders의 제공 시에, 변경사항 목록에 대해 데이터베이스에 요청할 수 있습니다. 이 경우에는 ?limit=5의 5개의 변경사항으로 결과 세트를 제한할 수 있습니다.

GET /orders/_changes?limit=5
{
  "results": [
    {
      "seq": "1-g1AAAAB5eJzLYWBg",
      "id": "00002Sc12XI8HD0YIBJ92n9ozC0Z7TaO",
      "changes": [
        {
          "rev": "1-3ef45fdbb0a5245634dc31be69db35f7"
        }
      ]
    },
    ....
  ],
  "last_seq": "5-g1AAAAB5eJzLYWBg"
}

API 호출은 다음과 같은 변경사항을 리턴합니다.

results

변경사항의 배열

last_seq

후속 API 호출 시 변경 사항 엔드포인트에 전달하여 다음 변경 사항 배치를 가져올 수 있는 토큰입니다.

다음 예제에서 변경사항의 다음 일괄처리를 페치하는 방법을 알아봅니다.

GET /orders/_changes?limit=5&since=5-g1AAAAB5eJzLYWBg
{
  "results": [ ...],
  "last_seq": "10-g1AAAACbeJzLY"
}

since 매개변수는 다음에서 시작하려는 변경 피드의 위치를 정의하는 데 사용됩니다.

since=0

변경 사항 피드의 시작 부분입니다.

since=now

변경 사항 피드의 끝.

since=<a last seq token>

변경 내역 피드에서 알려진 위치에서.

액면 그대로 보면 변경 사항 피드를 따르는 것은 _changes API 호출을 연결하는 것만큼 간단해 보입니다. 그런 다음 IBM Cloudant 은 changes feed 응답의 last_seq 을 다음 요청의 since 매개 변수로 전달합니다. 그러나 변경 피드에 대한 일부 미묘한 사항은 추가적인 논의가 필요합니다.

변경 내역 피드는 왜 각 변경 사항을 적어도 한 번씩 전달하나요?

IBM Cloudant 표준은 피드가 각 문서를 최소 한 번은 반환하겠다고 약속하는 것으로, 각 문서를 딱 한 번만 반환하겠다고 약속하는 것과는 다릅니다. 다시 말하면, changes feed의 이용자는 동일한 변경을 다시 보거나 실제로 변경 세트의 반복을 다시 볼 수 있습니다.

변경 피드의 이용자는 멱등 방식으로 변경사항을 처리해야 합니다. 실제로는 변경사항에서 조치를 트리거하기 전에 변경사항이 이미 처리되었는지 여부를 기억해야 합니다. 순진한 변경 피드 이용자는 수신된 모든 변경사항에 대해 스마트폰으로 메시지를 보낼 수 있습니다. 그러나 변경사항이 재생될 때 변경이 이상적으로 처리되지 않는 경우 사용자는 중복된 텍스트 메시지를 수신할 수 있습니다.

일반적으로, 이러한 변경 피드의 "리와인드"는 짧으며 일부 변경사항만 재생합니다. 그러나 일부 경우에는 요청에 수천 개의 변경된 변경사항이 있는 응답이 표시될 수 있습니다. 잠재적으로 모든 변경사항이 시간의 시작 부분에서 발생할 수 있습니다. rewinds의 가능성으로 인해 changes feed는 큐와 유사한 작동을 예상하는 애플리케이션에 적합하지 않습니다.

다시 한 번 강조하자면, IBM Cloudant 의 변경 내역 피드는 변경 내역 피드 내에서 적어도 한 번 문서를 제공할 것을 약속할 뿐이며, 여러 요청에 걸쳐 값이 반복되는 것에 대해서는 어떠한 보장도 하지 않습니다.

변경 피드가 "실시간" 으로 작동합니까?

변경 피드는 변경 피드를 이용하는 클라이언트에 입력 변경이 얼마나 빨리 나타나는지를 보장하지 않습니다. 데이터 삽입, 업데이트 및 삭제가 즉시 변경사항 판독기로 전파된다는 가정 하에 애플리케이션을 개발하지 않아야 합니다.

변경 피드에 모든 개별 문서 변경사항이 표시되지 않는 이유는 무엇입니까?

변경 내역 피드 호출 사이에 문서가 여러 번 업데이트된 경우, 변경 내역 피드에는 이러한 변경 사항 중 가장 최근의 변경 사항만 반영될 수 있습니다. 클라이언트는 모든 문서에 대한 모든 변경사항을 수신하지 않습니다.

IBM Cloudant 변경 피드는 시간 순서대로 발생한 모든 이벤트를 포함하는 트랜잭션 로그 가 아닙니다.

운영 쿼리에 대해 필터링된 변경 피드를 사용할 수 있습니까?

변경 내역 피드를 필터링하고, 더 나아가 필터링된 복제를 실행하는 데는 다음과 같은 장점이 있습니다:

• 소스에서 대상으로 데이터를 복사하지만 삭제된 문서는 무시합니다.
• 인덱스 정의 없이 데이터 복사(디자인 문서)

이 블로그 게시물에서는 복제 중에 selector 을 제공하면 이러한 사용 사례의 작업이 원활하게 실행되는 방법에 대해 설명합니다.

수반되는 selector 매개변수가 있는 변경 피드는 루틴을 기반으로 데이터베이스에서 데이터 조각을 추출하는 방법이 아닙니다. 이 기능을 데이터베이스에 대한 운영 쿼리를 실행하는 수단으로 사용해서는 안 됩니다. 필터링된 변경사항은 느립니다(인덱스를 사용하지 않고도 변경된 모든 문서에 필터가 차례로 적용됩니다). 이 프로세스는 보조 인덱스(예: MapReduce 뷰)를 작성하고 해당 뷰를 쿼리하는 것보다 훨씬 느립니다.

feed=continuous 변경 사항 피드가 무기한으로 계속 실행되나요?

아니요, IBM Cloudant 은 연속 변경 피드에 대한 연결 시간을 보장하지 않습니다. 유지보수, 보안 문제 또는 네트워크 오류 등 여러 가지 이유로 인해 서버 측에서 정기적으로 연결이 끊길 수 있습니다. 변경 피드를 사용하는 코드는 최근에 저장된 순서 ID를 since 값으로 사용하여 오류 또는 연결 끊기 후 변경 피드를 재개하기 위한 새 요청을 작성하도록 설계되어야 합니다.

변경 피드가 시간 순서를 보장하지 않는 이유는 무엇입니까?

유스 케이스가 다음 명령문을 기반으로 하는 경우, IBM Cloudant 변경 피드를 사용하여 이 결과를 달성할 수 없습니다.

"Fetch me every document that has changed since a known date, in the order they were written."

IBM Cloudant 데이터베이스는 각 문서 변경이 기록된 시간을 기록하지 않습니다. 변경 피드는 피드 변경사항의 순서에 대한 보장을 제공하지 않습니다. 즉, 데이터베이스로 전송된 순서대로 보장되지 않습니다.

그러나 문서 본문에 변경 날짜를 저장하여 이 유스 케이스를 달성할 수 있습니다.

{
  "_id": "2657",
  "type": "order",
  "customer": "bob@aol.com",
  "order_date": "2022-01-05T10:40:00",
  "status": "dispatched",
  "last_edit_date": "2022-01-14T19:17:20"
}

그리고 last_edit_date을(를 ) 키로서 MapReduce 뷰를 작성할 수 있습니다.

function(doc) {
  emit(doc.last_edit_date, null)
}

이 뷰는 제공된 날짜 및 시간이나 그 이후에 수정된 문서를 리턴하기 위해 쿼리될 수 있습니다.

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"

이 기술은 성능 및 반복 가능한 방식으로 반복되는 값이 없는 시간 정렬된 결과 세트를 생성합니다. 이 데이터의 사용자는 데이터를 항등적으로 관리할 필요가 없으므로, 개발 과정이 더 간단해집니다.

어떤 IBM Cloudant 변경 피드가 현재 유용합니까?

IBM Cloudant 변경 피드는 다음 태스크에 유용합니다.

• 일부 변경사항을 필터링하기 위해 선택적으로 선택기를 사용하여 IBM Cloudant 복제를 수행합니다.
• 클라이언트는 변경 내역 피드를 일괄적으로 처리하지만, 정렬 순서는 고려하지 않고 각 변경 사항을 항등적으로 처리하며, 일부 변경 사항이 한 번 이상 표시될 수 있음을 예상합니다.

IBM Cloudant 변경 피드는 다음 구성요소에 적합하지 않습니다.

• 메시지 큐. 자세한 내용은 IBM Messages for RabbitMQ 큐 관리에 관한 내용을 참조하십시오.
• 메시지 브로커. 자세한 내용은 다음을 참조하십시오. IBM Event Streams 확장 가능하고 시간 순서가 정해진 이벤트 스트림을 처리하는 방법에 대한 내용을 참조하십시오.
• 실시간 발행 및 구독 시스템. 자세한 내용은 다음을 참조하십시오. IBM Databases for Redis 게시 및 구독 토픽 처리에 관한 내용을 참조하십시오.
• 트랜잭션 로그. 일부 데이터베이스는 각 변경 사항을 트랜잭션 로그에 저장하지만, 분산형 및 최종 일관성(eventually consistent) 특성을 지닌 분산 트랜잭션( IBM Cloudant )의 특성상, 명확한 시간 순서를 따르는 트랜잭션 로그는 존재하지 않습니다.
• 쿼리 메커니즘. 자세한 정보는 선택한 키로 정렬된 데이터의 뷰 작성에 대해 MapReduce 뷰를 참조하십시오.