レプリケーションへの通常のアプローチは、1つのデータベース（マスター）から他のデータベース（スレーブ）へのバイナリログの同期または非同期転送です。 バイナリログでは、データを変更するすべての操作が厳密に順番に記録されます。 同じ開始点から別のシステムで「失う」場合、元のシステムとまったく同じデータ状態を取得する必要があります。 「再生」は、単一の操作または単一のトランザクションで、つまり非常に小さな部分で発生します。
このアプローチは、OLAP固有のデータベース、特にデータを行ではなく列に物理的に保存する列指向のデータベースではうまく機能しません。 このようなデータベースは、分析タスクに一般的な大きなデータ配列の書き込み、読み取り、ソートに最適化されていますが、単一のレコードに対する小さな操作には適していません。操作には、異なるファイル（および異なるディスク）に物理的に保存される多くの列が含まれるためです。 最悪の事態はデータの変更です。 もちろん、すべてのデータベースはSQL標準とUPDATEステートメントをサポートしますが、物理レベルでは通常、更新されたレコードが削除済みとしてマークされ、代わりに変更されたコピーが挿入されるという事実に変換されます。 その後、いつか、ガベージコレクターがテーブルをシェイクし、削除されたレコードが永久に削除されます。 パフォーマンスの低下に加えて、削除と更新を頻繁に行うとデータベースの目詰まりが発生し、読み取りなどのパフォーマンスが低下することになります。
ロバートは、このような場合のデータ複製の問題を解決するための新しい、しかし自然なアプローチのように思えます。 バイナリログは、各テーブルの一連の部分的に順序付けられた一連のDELETE / INSERT操作に変換されます。さらに、「セット」という言葉は、「同一」の操作で一度実行すれば十分であることを意味します。 もう少し説明します。
まず、個々の変更またはテーブルを複製する代わりに、かなり大きなチャンクまたはデータパケットで複製を行うことをお勧めします。 これは、データをOLAPデータベースに読み込むのに自然です。 たとえば、特定の期間のすべての変更：分、5分など。 次に、パッケージに含まれるすべての変更がテーブルに分割されます。 次に、各UPDATEはDELETEおよびINSERTとペアになります。 そして最後に、各テーブルに対して、特定のルールに従って縮小が実行されます。各キーについてはDELETEが1つだけ残り、各キーについてDELETEが続かない場合は最後のINSERTのみが残ります。 この削減により、変更のフローがDELETEやINSERTなどの最小限の操作セットに変わり、INSERTの前にDELETEが実行されます。 例：
バイナリログ内の3つの操作は中間段階で4つの操作に変換され、削減後は最後の2つのみが残りました。
それは何を与えますか？ これにより、OLAPデータベースの観点からデータを変更する最も効率的な方法が得られます。まず、パッケージで削除または変更されたすべてのレコードが削除され、それ以降は削除されます。次に、テーブルごとに新しいレコードと変更されたレコードが追加されます。これは、バッチ演算子によって非常に効率的に実行できますデータの読み込み。 つまり、厳密に順序付けられた線形シーケンスは、部分的に順序付けされたセット（部分的に順序付けられたセットのシーケンス）に変換されます。 これが基本的な意味です。
明らかに、制限があります。 バイナリログのUPDATEまたはDELETEにテーブルのプライマリキーの条件が含まれていない場合、このアプローチは機能せず、この場合、従来の方法でデータを複製する必要があります。
結論として、これは空の理論ではなく、実用的な実装であり、ロバートが次の記事で書いていることに注意してください 。 なぜこれが必要なのですか？ クライアントは、MySQLに保存されたデータの迅速な分析を求めていました。 また、Verticaはこのための非常に優れたツールです。 私は直接知っています。