mysql - 究極の MySQL レガシー データベースの悪夢

Question

表 1: キッチン シンクを含むすべて。間違った形式の日付 (最後の年なのでその列でソートできない)、VARCHAR として格納された数値、「番地」列に完全な住所、名列に名と姓、名字列に市区町村、不完全な住所、何年にもわたって変更された一連のルール、重複レコード、不完全なレコード、ガベージレコードに基づいて、あるフィールドから別のフィールドにデータを移動することにより、前の行を更新します...名前を付けます...ああ、もちろん、TIMESTAMPまたはPRIMARYではありませんKEY 列が見えます。

表 2: この赤ん坊をクラックして開いた時点で、正常化の望みはすべて消え去りました。各エントリに行があり、テーブル 1 の行を更新します。したがって、明日はありません (800MB 相当) のような重複と、Phone1 Phone2 Phone3 Phone4 ... Phone15 のような列 (これらは phone とは呼ばれません。説明のためにこれを使用します) 外部キーは..よく推測してください。table1 の行にどのようなデータがあったかによって、3 つの候補があります。

表 3: 悪化することはありますか? そうそう。「外部キーは、ダッシュ、ドット、数字、および文字の VARCHAR 列の組み合わせです! それが一致しない場合 (多くの場合一致しません)、同様の製品コードの 2 番目の列が必要です。それらの中のデータとの相関関係はなく、必須の Phone1 Phone2 Phone3 Phone4... Phone15. Table1 から複製された列があり、TIMESTAMP または PRIMARY KEY 列が見えません。

表 4: 進行中の作業として説明されており、いつでも変更される可能性があります。それは本質的に他のものと似ています。

100 万行近くになると、これは大混乱です。幸いなことに、それは私の大きな混乱ではありません。残念ながら、「顧客」ごとに複合レコードを引き出す必要があります。

最初に、Table1 に PRIMARY KEY を追加し、すべての日付をソート可能な形式に変換する 4 つのステップの変換を考案しました。次に、Table1 を使用して他のテーブルからプルしてコンポジットを形成できるようになるまで、フィルタリングされたデータを返すクエリのステップをさらに 2 つ実行します。数週間の作業の後、いくつかのトリックを使用してこれを 1 つのステップにまとめました。これで、アプリを混乱に向けて、複合データのきれいなテーブルを引き出すことができます。幸いなことに、目的に必要な電話番号は 1 つだけなので、テーブルの正規化は問題になりません。

毎日何百人もの従業員が想像もつかない方法でこのデータベースを追加/更新/削除し、毎晩新しい行を取得する必要があるためです。

どのテーブルの既存の行も変更可能であり、TIMESTAMP ON UPDATE 列がないため、何が起こったのかを知るためにログに頼る必要があります。もちろん、これはバイナリログがあることを前提としていますが、ありません!

鉛風船のように下がったコンセプトをご紹介。私は彼らの子供たちが実験的な手術を受けなければならないだろうと彼らに言ったかもしれません. 彼らは正確にはハイテクではありません...あなたが集めていなかった場合に備えて...

私の会社がひどく欲しがっている貴重な情報を彼らが持っているので、状況は少しデリケートです. 私は、大企業の上級管理職 (彼らがどのようであるかを知っています) から「それを実現する」ように派遣されました。

bin ログ ファイルをさらに別のアプリケーションで解析し、日中にそのデータベースに対して何を行ったかを把握し、それに応じてテーブルを合成する以外に、夜間の更新を処理する方法は考えられません。私のテーブルに何をすべきかを理解するために、私は本当に彼らの table1 を見る必要があるだけです。他のテーブルは、レコードをフラッシュするためのフィールドを提供するだけです。(混乱の重複があるため、MASTER SLAVE を使用しても役に立ちません。)

別の方法は、table1 のすべての行に対して一意のハッシュを作成し、ハッシュ テーブルを作成することです。次に、毎晩データベース全体を調べて、ハッシュが一致するかどうかを確認します。そうでない場合は、そのレコードを読み取ってデータベースに存在するかどうかを確認し、存在する場合はデータベースで更新し、存在しない場合は新しいレコードとして INSERT します。これは醜く、高速ではありませんが、バイナリ ログ ファイルの解析もきれいではありません。

問題を明確にするためにこれを書きました。多くの場合、他の人にそれを話すと、問題が明確になり、解決策がより明白になります。この場合、私はより大きな頭痛を抱えています！

あなたの考えは大歓迎です。

Answer 1

私はMySQLの人ではないので、これは左のフィールドから出てきています.

しかし、ログファイルが答えかもしれないと思います。

ありがたいことに、ログから 2 つのことだけを知る必要があります。

レコード/行IDが必要で、操作が必要です。

ほとんどの DB では、MySQL を想定していますが、行 ID やレコード ID などのように、各行に暗黙的な列があります。これは、データベースが使用する内部行番号です。これが「無料」の主キーです。

次に、操作が必要です。特に、それが行に対する挿入、更新、または削除操作であるかどうか。

このすべての情報を時間順に統合してから、実行します。

挿入/更新ごとに、元の DB から行を選択し、その行を宛先 DB に挿入/更新します。削除の場合は、行を削除します。

フィールド値は気にしません。それらは重要ではありません。行全体を実行します。

バイナリ ログ ファイルを「解析」する必要がないことを願っています。MySQL には、それを行うためのルーチンが既に存在している必要があります。必要なのは、それらの使用方法を見つけて理解することだけです (使用できる便利な「ダンプ ログ」ユーティリティさえあるかもしれません)。 ）。

これにより、システムを非常にシンプルに保つことができ、合計 DB サイズではなく、日中の実際のアクティビティのみに依存する必要があります。最後に、「よりスマート」にすることで、後で最適化できます。たとえば、行を挿入してから更新し、削除します。リプレイでその行を完全に無視できることがわかります。

明らかに、ログ ファイルを実際に読み取るには少し難解な知識が必要ですが、残りは簡単です。ログファイルにもタイムスタンプが付けられていると思います。そのため、「今日から」または任意の日付範囲で行を操作することができます。

Answer 2

このデータベースにアクセスする既存のコードを使用して、ニーズに適合させることはできませんか？もちろん、コードは恐ろしいものでなければなりませんが、データベース構造を処理する可能性がありますね。うまくいけば、考古学者を演じる代わりに、仕事を成し遂げることに集中することができます。

Answer 3

ログ ファイル (バイナリ ログ) も最初に考えました。彼らがどのように物事を行ったかを知っていれば、身震いするでしょう。断片が追加および変更されると、ログにはすべての行に対して多数のエントリが記録されます。それはただ巨大です！今のところ、ハッシュ アプローチに落ち着きました。巧妙なファイルメモリページングにより、これは非常に高速です。

Answer 4

maatkitのmk-table-syncツールを使用して、ステージングデータベースを同期できる場合があります（結局のところ、データベースは非常に小さいだけです）。これは「混乱を複製する」でしょう

次に、同期後にさまざまなクエリを実行して、レポートできるより適切なテーブルのセットを生成するものを作成できます。

これは、パフォーマンスの問題なしに日常的に実行できると思います。

すべてを別のサーバーで実行すると、元のデータベースへの影響を回避できます。

私が見ることができる唯一の問題は、いくつかのテーブルに主キーがないかどうかです。