RDB 間のデータ連携を行う際に整理すべきポイントと進め方
進め方
要件整理
- 連携元と連携先のテーブル
- 主キー有無
- 参照整合性制約有無
- データ変換要件
- カラムのマッピング
- UNION
- データ鮮度（連携頻度）: 定期（日次／毎時）／準リアルタイム
- 連携方式: 全量洗い替え／差分連携
- 連携中に連携先テーブルが参照されるか
データ連携パターンの整理
以下の観点でデータ連携のパターンを整理する。
- RDBプロダクト: 連携先と連携元の RDB プロダクト（Oracle/PostgreSQL/MySQLなど）やバージョン
- 方向: 片方向/双方向
- 連携頻度: 日次・毎時など定期的/ニアリアルタイム
- 連携対象テーブルの対応: 1:1, 1:N/N:1 など
- テーブル定義の対応: カラム名が異なる
- 連携元テーブルのデータ更新方式: C/CD/CU/UD/CUD/洗い替え（Truncate/Insert）
- C: Insert, U: Update, D: Delete
- データ連携の粒度: テーブル単位/レコード単位/フィールド単位（特定カラムのみ）
- 連携対象レコードを特定する方法: タイムスタンプ/シーケンス/フラグなど
- テーブルの制約: Primary Key（ユニーク&Not Null）/参照整合性制約
- テーブルの属性：行数、データサイズ
方式設計
- 論理設計: 各パターンでの正常系・異常系（失敗時のリカバリ方法）の論理的な連携方式（SQLでどう表現するか）を机上検討する。
- 物理設計: 各パターンでの正常系・異常系（失敗時のリカバリ方法）の連携方式（具体的な実装方式）を机上検討する。
- 具体的な実装方式: 利用するミドルウェア、クラウドサービス、プログラミング言語など
PoC
- 机上検討でフィージビリティ（実現可能性）が不明な点があれば、実機検証で確認する。
実装
- 各パターンで1つのデータ連携処理を実装し、正常系・異常系が期待通り動作することをテストで確認する。
- 横展開して各パターンの実装する。
テスト
- 機能（正常系）: 正しくデータ連携が行われているか
- 機能（異常系）: 障害時に可用性設計通りの挙動になるか、障害時にリカバリ手順通りにリカバリできるか
- 非機能（性能）: 全てのデータ連携時に期待するレイテンシー/スループットが出るか
- DB への負荷は許容範囲内か
- 途中のネットワーク帯域などがボトルネックにならないか
データ連携方式例
- ファイル出力/転送/ロード
- CDC（Oracle GoldenGate/Attunity Replicate/Debezium）
注意事項
- DB接続がネットワーク障害で発生時のリカバリ方法
- 障害時にDBのロックが長時間残らないよう、DBサーバーに無効接続検知の設定は入れる。
- Read処理であってもトランザクションが内部的に発生し、トランザクションのクローズ処理が必要にならないか。
- データ連携が中断した場合のリカバリ方向（フルロードから再開できるか、差分連携で再開する必要がある場合はどこから連携できてないか論理的に得的可能か）
