カスタムデータレプリケーションキー - PolarDB - Alibaba Cloud ドキュメントセンター

デフォルトでは、IMCI はプライマリキーを使用してデータ更新とデータ削除を同期します。しかし、テーブルにプライマリキーがない場合や、UUID のように順序付けられていないプライマリキーがある場合、この戦略は非効率的です。これらのシナリオでは、データ同期中に過剰なランダム I/O が発生し、パフォーマンスが低下します。このガイドでは、これらのシナリオでデータ同期パフォーマンスを向上させるために、カスタムレプリケーションキーを定義する方法について説明します。

前提条件

テーブルには、物理ストレージ内で単調増加する値を持つ列が必要です。

注意事項

開始する前に、次の点を考慮してください。

一意なインデックスに基づいている必要があります: カスタムレプリケーションキーは、USING INDEX 句で指定された一意なインデックスに基づいている必要があります。
インデックス列は NULL 不可である必要があります: レプリケーションキー用の一意なインデックス内のすべての列は、NOT NULL として定義されている必要があります。
最適なパフォーマンスを得るには、順序付けられたインデックスを使用してください: 最適なパフォーマンスを得るには、SERIAL または BIGSERIAL 型の自動増分列など、単調増加列に一意なインデックスを構築することを強く推奨します。

仕組み

`REPLICA IDENTITY` メカニズム

REPLICA IDENTITY プロパティは、論理レプリケーション中に変更された行を識別するために WAL (ライトアヘッドログ) に書き込まれる情報を決定します。IMCI はこのメカニズムを使用して、カラム型ストア内のデータを特定し、更新します。REPLICA IDENTITY は次の 4 つのモードをサポートしています。

モード	説明	ユースケース
`DEFAULT`	プライマリキーをレプリケーション ID として使用します。	デフォルトで推奨されるモードです。テーブルにプライマリキーがある場合、変更は不要です。
`USING INDEX`	指定された一意なインデックスをレプリケーション ID として使用します。	テーブルにプライマリキーがない場合、または順序付けられていないプライマリキーがある場合に、効率を向上させるために順序付けられた一意なインデックスを指定します。
`FULL`	行内のすべての列の値を WAL に書き込みます。	テーブルにプライマリキーも一意なインデックスもないが、UPDATE または DELETE 操作をサポートする必要がある場合にのみ使用します。
`NOTHING`	識別情報は記録されません。	更新または削除をサポートしない挿入専用テーブルにのみ使用します。

レプリケーションキーとしての順序付けられた一意なインデックス

コアとなる原則は、USING INDEX モードを使用して、レプリケーションキーを自動増分列などの順序付けられた列上の一意なインデックスに設定することです。

ワークフローは次のとおりです。

順序付き一意なインデックスを作成します：物理的に順序付けられた列（例： SERIAL 型の自動インクリメント ID）に一意なインデックスを作成します。
レプリケーション ID の変更: ALTER TABLE ... REPLICA IDENTITY USING INDEX ... コマンドを実行して、テーブルのレプリケーション ID を新しく作成された一意なインデックスに切り替えます。
効率的な論理デコード: 論理レプリケーション中、システムは WAL から順序付けられたインデックスキー値を効率的にデコードします。
データ同期の高速化: IMCI はこれらの順序付けられたキー値を使用して、カラム型ストア内のデータを特定し、更新します。キー値が順序付けられているため、操作は効率的なシーケンシャル I/O となり、データ同期パフォーマンスが大幅に向上します。

操作手順

ステップ 1: 一意なインデックスの作成
順序付けられた自動増分列に一意なインデックスを作成します。
```
-- Assuming table t has an auto-incrementing column named serial_id
CREATE UNIQUE INDEX idx_t_serial_id ON t(serial_id);
```
ステップ 2: レプリケーション ID の変更
テーブルの REPLICA IDENTITY を前のステップで作成した一意なインデックスに切り替えます。
```
ALTER TABLE t REPLICA IDENTITY USING INDEX idx_t_serial_id;
```
ステップ 3: カラム型ストアインデックスの作成または再構築
カラム型ストアインデックス (CSI) にレプリケーションキーに使用される列が含まれていることを確認します。カラム型ストアインデックスがすでに存在する場合、最適なパフォーマンスを得るために再構築することを推奨します。
```
-- Create a columnar store index that includes all columns
CREATE INDEX ON t USING csi;
```

ステップ 4: パフォーマンスの比較

パフォーマンスの向上を検証するために実験を実施しました。

テスト設定:
1. 順序付けられていないプライマリキー (random_id) と順序付けられた自動増分列 (serial_id) を持つテーブルを作成します。
```
create table t (random_id text primary key, serial_id serial, a text);
```
2. 1,000 万行のデータを挿入します。
```
insert into t(random_id, a)
  select md5(i::text), i::text
    from generate_series(1, 10000000) i;
```
3. serial_id 列にカラム型ストアインデックスと順序付けられた一意なインデックス idx_a を作成します。
```
create unique index idx_a on t(serial_id);
create index on t using csi;
```
テスト手順:
1. デフォルトモードテスト (順序付けられていないプライマリキー random_id をレプリケーションキーとして使用):
```
-- Update 10,000 rows
UPDATE t SET a = '0' WHERE serial_id <= 10000;
```
2. カスタムモードテスト (レプリケーションキーを順序付けられた一意なインデックス idx_a に切り替え):
```
ALTER TABLE t REPLICA IDENTITY USING INDEX idx_a;
-- Update another 10,000 rows
UPDATE t SET a = '1' WHERE serial_id <= 10000;
```

テスト結果:

レプリケーションキーのタイプ	デフォルト (順序付けられていないプライマリキー)	カスタム (順序付けられた一意なインデックス)
同期時間 (10,000 行)	約 0.5 秒	約 0.01 秒

まとめ

約 50 倍のパフォーマンス向上は、カスタムの順序付けられたレプリケーションキーが IMCI データ同期効率を最適化するために重要であることを示しています。

前提条件

注意事項

仕組み

REPLICA IDENTITY メカニズム

レプリケーションキーとしての順序付けられた一意なインデックス

操作手順

まとめ

`REPLICA IDENTITY` メカニズム