BLOB

「BLOB」には、LONG VARCHAR、LONG BINARY、TEXT、IMAGE の各データ型が含まれています。

SQL Remote は、INSERT 文または UPDATE 文をレプリケートすると、BLOB 値の代わりに変数を使用します。つまり、BLOB は細かく分割して各部分がレプリケートされます。分割された部分は受信データベースで SQL 変数を使用して再構成され、連結されます。変数の値は、次のように文を結合して作成します。

SET var = var || 'more_stuff';

この変数によって、長い値を含んでいる SQL 文が短くなり、1 つのメッセージ内に収まります。

SET 文は独立した SQL 文であるため、BLOB は複数の SQL Remote メッセージに効果的に分割されます。

BLOB のレプリケーションの制御

verify_threshold オプションを使用してメッセージサイズを最小にする

verify_threshold データベースオプションを使用すると、(レプリケートされた UPDATE 文の VERIFY 句による) 確認の対象から長い値を除外できます。このオプションのデフォルト値は 1000 です。カラムのデータ型がスレッショルドより長いと、カラムの古い値は UPDATE 文がレプリケートされるときに確認されません。このようにして、SQL Remote メッセージのサイズを小さくしますが、競合する長い値の更新が検出されないという短所もあります。

メッセージのサイズを小さくするために verify_threshold オプションを使用している場合に競合を検出するには、次の方法を使用します。

BLOB を更新するときに、同じテーブル内の last_modified カラムも必ず更新されるようにデータベースを設定します。
last_modified カラムが BLOB カラムと一緒にレプリケートされるようにパブリケーションを設定します。
BLOB カラムと last_modified カラムがレプリケートされるときに、last_modified カラムの値を確認できます。last_modified カラムと競合している場合は、BLOB カラムとも競合しています。

ワークテーブルを使用して重複する更新を防ぐ

BLOB が繰り返し更新されるときは、ワークテーブルで更新し、最終バージョンをレプリケートされたテーブルに割り当てるようにします。たとえば、作業中の資料が 1 日に 20 回更新される場合、1 日の終りに SQL Remote を 1 回実行すると、20 回の更新すべてがレプリケートされます。資料のサイズが 200 KB の場合は、4 MB のメッセージが送信されます。

document_in_progress テーブルを使用することをおすすめします。ユーザが資料の変更を終了したときに、アプリケーションがその資料を document_in_progress テーブルからレプリケートされたテーブルに移動します。この結果、1 回の更新 (200 KB のメッセージ) で済みます。

参照

DocCommentXchange で意見交換できます