IBM Cloudant 変更フィードの FAQ の使用

IBM Cloudant データベースの変更フィードの主なユース・ケースは、ソース・データベースからターゲット・データベースへのデータの複製を強化することです。 IBM Cloudant リプリケーターは、変更フィードを処理するように設計されており、データが宛先に正確にコピーされることを保証するために必要なチェックを実行します。

IBM Cloudant 単一のデータベースの変更内容を取得するために利用できる「raw changes feed API 」がありますが、使用には注意が必要です。

_changesAPI エンドポイントはいくつかの方法で使用でき、さまざまな形式でデータを出力できます。 ただし、ここでは、_changes API に対して開発する際のベスト・プラクティスと、いくつかの落とし穴を回避する方法に焦点を当てています。

変更フィードをコンシュームするにはどうすればよいですか？

単一のデータベース 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 は last_seq を 1 つの changes feed 応答から次の要求の since パラメーターに渡します。 しかし、変更フィードに対するいくつかの微妙な点については、さらに検討する必要があります。

なぜ「changes」フィードは、各変更を少なくとも1回ずつ配信するのでしょうか？

IBM Cloudant 標準では、フィードが各ドキュメントを_少なくとも1回は_返すことを保証するものであり、各ドキュメントを _1回だけ_返すことを保証するものではありません。 言い換えると、changes feed のコンシューマーに同じ変更が再度表示されたり、一連の変更が繰り返し表示されたりする場合があります。

変更フィードのコンシューマーは、変更を_べき乗的に_扱わなければなりません。 実際には、変更からアクションをトリガーする前に、変更が既に処理されているかどうかを覚えておく必要があります。 単純な変更フィード・コンシューマーは、変更を受信するたびにスマートフォンにメッセージを送信する可能性があります。 ただし、再生された変更が発生したときに、変更がべき等として扱われない場合、ユーザーは重複したテキスト・メッセージを受け取る可能性があります。

通常、これらの変更フィードの「巻き戻し」は短く、一部の変更のみを再生します。 ただし、場合によっては、何千もの変更が再生された応答が要求に表示されることがあります（場合によっては、最初からすべての変更が再生される可能性があります）。 rewinds の可能性があるため、changes feed は、キューのような動作を必要とするアプリケーションには適していません。

繰り返しになりますが、 IBM Cloudant の変更フィードは、変更フィード内でドキュメントを_少なくとも1回_配信することを約束するものであり、複数のリクエストにわたって値が重複することについては一切保証しません。

変更フィードは「リアルタイム」で動作しますか？

変更フィードは、変更フィードをコンシュームするクライアントに対して着信変更がどの程度迅速に表示されるかを保証するものではありません。 アプリケーションは、データの挿入、更新、および削除が変更リーダーに即時に伝搬されることを前提として開発してはなりません。

すべての個別文書の変更が変更フィードに表示されないのはなぜですか ?

変更フィードの呼び出しの間にドキュメントが数回更新された場合、変更フィードにはそのうちの最新の変更のみが反映されることがあります。 クライアントは、すべての文書に対するすべての変更を受け取るわけではありません。

IBM Cloudant 変更フィードは、時間順に発生したすべてのイベントを含む トランザクション・ログ ではありません。

フィルタリングされた変更フィードを運用クエリーに使用できますか？

変更フィードをフィルタリングすること、ひいてはフィルタリングされたレプリケーションを実行することには、次のような利点があります：

  • ソースからターゲットにデータをコピーしますが、削除された文書は無視します。
  • 索引定義（設計文書）なしでデータをコピーします。

この ブログ投稿 では、複製中に selector を指定すると、これらのユース・ケースの作業がスムーズに実行される方法について説明します。

selectorパラメーターが付随する変更フィードは、 not ルーチン・ベースでデータベースからデータのスライスを抽出する方法です。 データベースに対して操作クエリを実行する手段として使用してはなりません。 フィルターに掛けられた変更は低速です（フィルターは、索引を使用せずに、変更されたすべての文書に順番に適用されます）。 このプロセスは、副次索引（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 パブリッシュ・アンド・サブスクライブ・トピックの取り扱いについては、
  • トランザクション・ログ。 一部のデータベースでは、変更のたびにトランザクションログに記録されますが、 IBM Cloudant の分散型かつ「最終的に一貫性」を持つという性質上、明確な時系列順のトランザクションログは存在しません。
  • 照会メカニズム。 選択したキー順にデータのビューを作成する方法について詳しくは、 MapReduce ビュー を参照してください。