2

私はこれに非常に慣れておらず、良い友人が拘束されています。私は途方に暮れています。これを行うために navicat や sqlyog などの gui を使用しましたが、手動でのみ行いました。

彼のバンド情報データ (スケジュールなど) は、サーバー (管理サーバー) 上の MYSQL データベースにあります。

私のサーバー (公開サーバー) に常駐するデータベースからデータを取得し、スケジュール情報、以前のギグのニュースレター、ファンとのやり取りを表示する Perl で書かれた基本的なサイトをまとめています。

彼は、管理サーバー上のデータを管理するために、好きで保持したい管理インターフェースを使用しています。

管理サーバーのデータベースには多数のテーブルがあり、パブリック データベースには不要なテーブル データさえあります。

そこで、関連データのみを含む表を公開側に作成しました。

私は基本的にGUIを使用してデータをエクスポートし、管理データベースを更新するたびに公開側に挿入しました(コピーアンドペースト)。

(参考までに、DBIモジュールを使用して、パブリックdb perlスクリプト内/経由でデータにアクセスしています。)

管理サーバーに直接アクセスして、必要なデータのみを取得することもできますが、これの全体的な目的は、すべてのクエリで管理サーバーにアクセスするのではなく、データを「ミラーリング」することです。また、いくつかのテーブルは何千もの行であり、ループ内のすべての行を解析することは私には「かさばる」ように思えました。ただし、比較に使用できる「時間」列があります。

構造が異なるため、「同期」できません。必要なのは、3 つのテーブルからの関連するテーブル データのみです。

そう……自動化したい!

「コピー」は手っ取り早い方法だと読みましたが、実装方法に関する私の発見は、私のレベルには高すぎました。

更新があったときに通知するスクリプトを管理サーバーに配置する余裕はありません。

1- テーブルをチェックして、管理サーバー データベースで行が更新または追加されたかどうかを確認するスクリプトをセットアップしたいと考えています。次に、新しいデータまたは変更されたデータを公開サーバーのデータベースに更新または挿入したいと思います。

この「チェック」は、私が推測する cron ジョブで設定するか、公開側で特定のページがロードされたときにトリガーされる可能性があります。(私が想定するcronによって呼び出されるのと同じサブルーチン)。

このデータは「リアルタイム」である必要はありませんが、何かを更新した場合、できるだけ早く表示されるとよいでしょう。

私は多くの読書、モジュールの調査、実験を行ってきましたが、ここで再びスタックオーバーフローに戻り、常に素晴らしいアドバイスと例を得ることができます.

用語の多くはまだ私の頭の中にあるので、説明付きの詳細な例は、私がより早く学ぶのに本当に役立ちます.

前もって感謝します。

4

4 に答える 4

1

あなたは ETL を複雑な問題領域と誤解していると思いますが、ETL は 1 回限りの解決策であり、多くの場合、レポートを書くよりもそれほど難しくありません。問題を完全に誤解していない限り、一般的な ETL ソリューションは必要ありません。少数のテーブルと数千行で機能する 1 回限りのソリューションが必要です。ETL とスキーマ マッピングは、単一のジョブよりも恐ろしく聞こえます。(ETL の一般化、スケーリング、変更管理、および OLTP から OLAP へのサポートは、特に困難な部分です。) Perl を使用して SQL データベースからレポートを作成できる場合は、おそらく ETL を処理するのに十分な知識があります。ここに関わっています。

1- テーブルをチェックして、管理サーバー データベースで行が更新または追加されたかどうかを確認するスクリプトをセットアップしたいと考えています。次に、新しいデータまたは変更されたデータを公開サーバーのデータベースに更新または挿入したいと思います。

プルする必要があるすべてのテーブルに更新タイムスタンプ列がある場合、cron ジョブには、更新のみを取得するために cron ジョブが最後に実行された時刻に基づく WHERE 句を含むいくつかの SELECT ステートメントが含まれます。更新タイムスタンプのないテーブルには、おそらくフル ダンプが必要です。

正規化が必要でない限り、1対1のテーブルマッピングを使用します...私の意見では単純です。必要がないのに、「大きな」スキーマの変更で複雑にする必要はありません。

一部のテーブルは何千もの行であり、ループ内のすべての行を解析することは私には「かさばる」ように思えました。

クエリを必要な列のみに制限します (必要な列に BLOB や非常に大きな列がない場合)、FETCHALL メソッドを使用した DBI を介して数千行が問題になることはありません。ローカルで必要なすべてをループし、リモート データベースへのトリップをできるだけ少なくします。

行の日付が新しい場合は、更新します。また、挿入する新しい行を確認する必要があります。

各テーブルに 1 つ必要SELECT ... WHERE updated_timestamp_columnname > last_cron_run_timestampです。その結果セットには、新しく挿入された行を含む新しいタイムスタンプを持つすべての行が含まれます (タイムスタンプ列が期待どおりに動作する場合)。ローカル データベースを更新するには、MySQL のON DUPLICATE KEY UPDATE構文を確認してください。これにより、ワンステップで実行できます。

... 実装方法が私のレベルには高すぎました... はい、実際にはすでにこれを実行しましたが、手動で更新する必要があります...

あなたのレベルを理解するのに役立ついくつかの質問... mysql クライアントのコマンドラインまたは GUI からデータベースにアクセスしていますか? SQL クエリを Perl と DBI でラップするところまできましたか?

于 2011-01-04T05:59:30.133 に答える
1

探している 2 つの用語は、「レプリケーション」または「ETL」です。

まず、複製アプローチ。

管理サーバーにテーブル T1、T2、T3 があり、パブリック サーバーにテーブル TP1、TP2 があるとします。

だから、あなたがしたいことは(あなたが言ったように異なるテーブル構造を持っているので)次のとおりです:

  1. パブリック サーバーからテーブルを取得し、それらのテーブルの正確なコピーを管理サーバー (TP1 および TP2) に作成します。

  2. 管理サーバーの元のテーブルにトリガーを作成して、T1/T2/T3 から管理サーバーの TP1/TP2 のコピーにデータを取り込みます。

  3. また、T1/T2/T3 から管理サーバーの TP1/TP2 のコピーに初期データを移入する必要もあります。当たり前。

  4. 管理サーバのTP1/TP2から公開サーバのTP1/TP2への「レプリケーション」を設定

別のアプローチは、管理サーバー (「ETL」の「E」部分) 上の T1/T2/T3 からデータを抽出するプログラム (そのようなプログラムは ETL - Extract-Transform-Load と呼ばれます) を作成し、データをマッサージすることです。 TP1/TP2 テーブル (「ETL」の「T」部分) にロードするのに適した形式に変換し、(ftp/scp/whatnot 経由で) それらのファイルを公開サーバーに転送し、プログラムの後半 (「L」)一部は、公開サーバー上のテーブル TP1/TP2 にファイルをロードします。プログラムの両方の半分は、cronまたは選択したスケジューラによって開始されます。

Perl/MySQL ETL の構築を開始する方法の非常に良い例を含む記事があります: http://oreilly.com/pub/a/databases/2007/04/12/building-a-data-warehouse-with-mysql- and-perl.html?page=2

独自に構築したくない場合は、オープン ソース ETL システムのリストを以下に示します。使用したことがないため、使いやすさや品質に関する意見はありません: http://www.manageability.org/blog/stuff/open-source-その他

于 2010-12-31T15:34:50.533 に答える
0

「スレーブ」サーバーにマスターサーバーと同じ構造を作成しないのはなぜですか。次に、更新されたテーブルの最後のタイムスタンプまたは ID を追跡する小さなテーブルを作成します。

次に、マスターから、最後のタイムスタンプ以降に変更されたすべての行、または ID より大きい行を選択します。それらをスレーブサーバーのマッチングテーブルに挿入します。

更新された行に注意する必要があります。マスターの行が更新されてもタイムスタンプが変わらない場合、フェッチする行をどのように判断するのでしょうか? それが問題でなければ、プロセスは非常に簡単です。

それが問題である場合は、より洗練されたものにする必要がありますが、データ構造と更新メカニズムを知らなければ、ポインタを与えるのはガチョウの追跡です。

スクリプトは、変更を更新するために cron によって頻繁に呼び出される可能性があります。

2 つのサーバーでデータベース構造が異なる必要がある場合は、単純な変換手順を追加する必要がある場合がありますが、ほとんどの場合、SQL の select ステートメントと 1 つまたは 2 つの結合内で実行できます。

于 2011-01-04T02:10:28.893 に答える
0

2 つのデータベースが異なる場合は、あるスキーマから別のスキーマにマップする ETL ソリューションが必要になります。

スキーマが同じである場合は、あるデータから別のデータに複製するだけです。

于 2010-12-31T15:35:39.363 に答える