Sync Gatewayによるリビジョンについて解説します。
Couchbase Mobileにおけるドキュメント
Couchbase Mobileでは、ドキュメントは次のもので構成されます。
- ドキュメントID
- 現在のリビジョンID
- JSONドキュメント本体
- メタデータ
ドキュメントへの変更(作成と削除も含む)は、リビジョンとして記録されます。
ドキュメントのリビジョンはメタデータ内に含まれ、メタデータにはリビジョンの履歴がリビジョンツリーとして保存されます。
画像、オーディオ、その他のマルチメディアオブジェクトなどのバイナリデータは、ドキュメントとは別に、blob(または添付ファイル)と呼ばれるエンティティに保存されます。BLOBを変更しても、リビジョンは生成されません。
リビジョン
Couchbase Mobileは、ドキュメントが作成、更新、または削除されるたびにリビジョンを作成します。
言い換えると、各ドキュメントは、一連のリビジョン(リビジョンツリー)で構成されます。
各リビジョンには、ドキュメントIDに加えて一意のリビジョンIDが与えられます。
リビジョンIDは、データの複製されたコピーに同時に変更が行われたときに発生する競合を解決するときに使用されます。
リビジョンIDは、2つの部分で構成されています。
-
世代ID(generation ID): これは、ドキュメントが存在するデータベースに固有の連続した自動インクリメント番号です。Couchbase Liteは単純な整数を生成します。Sync Gatewayは、より複雑で長いbase64値を生成します。
-
ドキュメントの内容から派生したハッシュ
アプリケーションは、リビジョンIDの内容に依存する処理ロジックを持つべきではありません。
リビジョンツリー
ドキュメントのリビジョンツリーは、ドキュメントの存続期間を通じて発生した各リビジョンを順番に記録します。
ツリーの先端であるリーフノードが、現在のリビジョン( ドキュメントの最新バージョン)です。
リビジョンツリーの成長はそのままでは無制限であり、パフォーマンスレベルを維持するには、不要なリビジョンを削除する必要があります。このプロセスは、リビジョンツリープルーニング(剪定)といわれます。
プルーニング(剪定)
リビジョンが追加されるたびに、不要なリビジョンを削除するプロセス(プルーニング)が自動的に実行されます。
構成
構成ファイルのrevs_limit
設定を使用して、保持されるリビジョンの数を変更できます。
たとえば、revs_limit
が1000の場合、アルゴリズムは最も短い非トゥームストーンブランチの中の、最近の1000のリビジョンを保持し、他のリビジョンを削除します。
適切なserevs_limit
の値は、Sync Gatewayで、自動競合解決が有効になっているかどうかによって異なります。自動競合解決が有効になっている場合、revs_limit
を少なくし過ぎると、競合解決プロセスが適切に行われない可能性が生じます。
リビジョンプルーニングとデータベースサイズ管理の詳細については、以下のブログを参照することができます。
リビジョンキャッシュ
ドキュメントにアクセスするたびに、そのリビジョンツリーもキャッシュされます。
リビジョンキャッシュがいっぱいになると、Sync Gatewayは古いリビジョンを削除して、新しいリビジョン用のスペースを確保します。
構成
構成ファイル内のrev_cache
設定を使用して、リビジョンキャッシュのサイズを制御できます。rev_cache
設定には次のふたつがあります(エンタープライズエディションでのみ利用可能です)。
-
rev_cache.size
:メモリにキャッシュされるリビジョンの総数を指定します。この設定を調整することで、Sync Gatewayのメモリ消費量を調整できます。 -
rev_cache.shard_count
:リビジョンキャッシュが分割される数。根拠なく、デフォルト値から変更することは推奨されていません。
参考情報