データ移行におけるデータの結合についてその１～ ETLとELT

データ加工において、２つ以上のテーブルをキーで結合することがあります。

実現方法としては、データベースなら、SQLのジョインの構文を使用することをすぐに思いつきます。

しかし、SQLはあくまで構造化設計されたテーブルを獲得するための機能です。
そのため、データは絞り込まれることを前提に処理されます。
絞り込んだ結果、数十万件になるようなレコードをエンドユーザーアプリに返すような処理はありえないとして、想定されていないからです。

SQLエンジンは、データのマッチングをメモリあるいはそれに準ずる高速領域で処理しようとします。
限定されたデータに対してさらに高速に処理するための手法ですが、想定外の大量データなどの場合は逆に処理が遅くなってしまいがちです。リソースが足りない場合にはパラメータチューニングが必要になりますが、それでも足りない場合がありえます。

システム間のデータ移行におけるデータ加工の場合はどうでしょうか。
データ移行の場合、大規模なデータを全件対象で処理する必要があります。そのため、SQLエンジンのような手法では、かえって速度が遅くなってしまうことが起きえますし、そんな処理が動くことで、データベースの他のユーザーへの影響が生じてしまうこともあるでしょう。

大量データを全件処理する場合には、「ETLツール」のようなバッチ処理型の手法を利用する方が効果的です。
その際、旧システム→新システムへのデータ移行を一回の処理で読み込み→書き込みできるとなお良いです。

手法はごく単純です。
入力データの両方あるいはマッチさせたいマスターデータをキーでソートし、頭からぶつけます。非常にドロくさい手法ですが、ジョインが複雑になるほど、このような方式が高速処理できるはずです。

外部から入手したデータを処理するために、わざわざSQLデータベースに読み込んで加工する方式（ELT：Extruct→Load→Transform：データをDBに取り込んでから加工するという、ETLに対向した言葉）も最近出て来ていますが、これはDB側にとってみれば苦し紛れの手法にも見えてしまいます。
だいたい、SQLデータベースへのデータ書き込み速度を無視しているかのように見えてしまうのです。
ETLツールを使ったバッチ処理型の手法であれば、データのロードを待っている間に処理は終了します。

データのロードに時間がかかり、SQL実行にさらに時間がかかり、DBのデータ領域にフラグメンテーションを起こしてしまう恐れがあるにもかかわらず、最終結果をそのまま使用するならともかく、たいていの場合は最後データの反映には専用アプリケーションやストアドプロシージャのプログラムが必要になってしまうこともあるでしょう。

SQLでは、オンライン中のDBに対して、複雑な条件でのデータ追加や書き換えを得意としないはずだからです。

もちろん、これらのオーバーヘッド満載のデータ加工処理が苦も無くできる大規模DB専用ハードウェアなどもありますが、そのコストを考えると、投資対効果を発揮してもらうのは容易なことではないのではないでしょうか？