web-dev-qa-db-ja.com

Drupal 7とViews 3を統合して大きなフラットファイルデータソースをインポートする

私の目標は、いくつかの非常に大きなフラットファイルデータソース（ [〜＃〜] csv [に含まれるread-onlyデータにアクセスするための高速で信頼できる自動化された方法を作成することです〜＃〜] s、Fixed Width and XML docs）using Drupal 7これは、 ビュー3 モジュールの使用に対して照会できます。すでに利用可能なモジュールを使用したいのですが、ただし、カスタムモジュールのビルドもオプションです。

タスクに適さないモジュールとメソッドを除外するために、ここで私が作業しているファイルの統計があります：

  • 年間インポート：8,500,000行 [〜＃〜] csv [〜＃〜] ファイル。 （毎年パージおよびリロードされます。主キーがあります。）
  • 週次インポート：350,000行の固定幅ファイル。 （毎週パージされリロードされます。主キーなし）
  • 時間ごとのインポート：3,400行 [〜＃〜] csv [〜＃〜] ファイル。 （可能な限り頻繁に更新および同期したいが、20分以内。主キーがある）
  • 毎日のインポート：200アイテムのXMLファイル。 （毎日パージされリロードされます。主キーがあります）

3つの形式間の変換は問題ではなく、インポートのパフォーマンスを向上させるか、より優れたツールを利用できるようにする場合に実行できます。 （ [〜＃〜] awk [〜＃〜] for 固定幅からCSV など）取得および変換の自動化は、cronおよび sh スクリプトを介して簡単ですが、自動化する必要がありますDrupal 7統合。ビューが関係を使用してデータを参照できる限り、カスタムテーブルの使用も可能です。

Drupal 7？）を使用してこのタイプのデータ統合を実現するためのベストプラクティスは何ですか？また、データに関する重要な詳細や達成しようとしていることは省いていますか？

ここに私が現在解決策を見つけるために見ているいくつかのプロジェクトがあります。これをさらに拡張して、大規模なデータインポートを処理するときに他の人がどのルートを取るかを決定できるようにしたいと思います。

ノードへのデータのインポート：

フィード はデータを確実にインポートします。速度は、小規模なデータソースには妥当ですが、30万以上のテーブルには遅すぎます。

Cronと ジョブスケジューラ （現在D7のアルファ版）を使用して自動化できます。

ソースデータで使用可能なインデックスまたは一意のキーがないため、これは使いにくくなっています。フィードよりは高速ですが、非常に大きなテーブルのインポートには時間がかかります。

自動化は、drushとcronを介して利用できます。

ノードの代わりにカスタムテーブル

データモジュール は非常に有望に見えますが、現時点ではD7には非常にバグがあります。自動化とインポート速度の要件はデータを使用して簡単に満たすことができますが、信頼性が欠けています。 ビューの統合 （リンクはD6用）は非常に有望に見えます。

参考のために追加しました。この時点ではD7候補はありませんが、カスタムモジュールの開始点として使用できます。

参考のために追加しました。これは、Table Wizard in Drupal 6.によって吸収されたようです。ここでも、参照用にのみ追加されています。

テーブルWizard （D6のみ） ビュー 統合用に必要です。参照用に追加されましたが、ビューの要件を満たしていません。

@MPD-可能な解決策として「カスタムテーブル」を追加し、モジュールを拡張しました。この追加をありがとう。

7migrationimporting-exporting
13
Citricguy

私の直感は、この計画はあなたのサーバーを燃え上がらせることになると私に言います...

真剣に、もしあなたがそれだけ多くのデータをチャーンしているなら、私はあなたが外部データソースにデータを保持し、それをDrupalと統合する必要があると思います。

私が最初に考えたのは、外部データ用に2つのデータベースを使用することです。これにより、邪魔にならないように週次インポートを実行できます。つまり、データベースAを起動して実行し、Bにインポートします。インポートが完了したら、Bをライブソースにします。次に、ワイプしてAにインポートします。

私は外部データソースのDrupalへの統合を数多く行ってきましたが、それほど難しくはありません。 PHP5 abominationからDrupalへの移行計画 で概要を説明しました。これはDrupal 6の場合でしたが、基本的にDrupal 7にも同じことが当てはまります。基本的に、CCK/Fields APIが独自のインターフェースで行うことをシミュレートします。

ただし、毎週のデータベースのUUIDがないと、実際にはレンチがスローされます。しかし、その部分には多くのことが必要ですが、このようなQ/Aフォーラムで提供できるものはもっとあります。

本当にインポートのルートをたどりたければ、私はFeeds and Migrateを利用して独自のインポートスクリプトを作成します。基本的には、index.phpから最初のブックストラッププロセスを実行し、データソースにクエリを実行し、ノードを作成して保存します。プログラムでノードを作成するのは簡単です。

これを開始する最良の方法は、UIでノードを作成し、次にそれをprint_rし、インポートスクリプトのコードでオブジェクトを複製することです。分類法、ファイル、noderefは難しい部分ですが、これらのオブジェクトプロパティを構築するには、APIのこれらの部分に精通する必要があります。有効なノードオブジェクトを取得したら、node_save（）を実行するだけです。スクリプトが実行されるように、set_time_limit（）で非常に大きな制限を設定してください。

明確化/拡張に対処するために以下を編集します。

個人的には、データインポートのためのcontribモジュールベースのアプローチの使用を少し前に停止しました。彼らはほとんどうまく機能しますが、結局、彼らとの戦いに多くの時間を費やしてしまい、コスト/利益が低すぎると判断しました。

Drupalのデータが本当に必要な場合は、カスタムインポートスクリプトに関する私の意見は変わっていません。参照するモジュールの1つは、ノードオブジェクト、データビルドノードをループして保存するだけです。PKがある場合は、データベースを検索するロジックを簡単に追加し、node_load（）を変更して保存できます。インポートスクリプトは実際には数時間だけですDrupal APIを知っている場合は動作します。

ビューの統合が重要であり（編集に基づいているように聞こえます）、外部テーブルアプローチを実行する場合、最良のオプションは、カスタムモジュールを実行して hook_views_data を実装することです。データをビューに入れます。おそらく、とにかくデータソースをサポートするためにカスタムモジュールを使用するので、このフックを追加することはそれほど多くの作業ではないはずです。 TWモジュールとDataモジュールには、いくつかの例があるはずです。

しかし、個人的には、外部データとのビューの統合が本当に価値があるとは思っていません。私がそれを検討した場合、データはあまりに「異なる」ため、ビューベースのアプローチではうまく機能しませんでした。私は上記の「abomination」リンクで説明した方法を使用するだけです。

8
mpdonadio

ノードベース（またはエンティティベース）のアプローチでは、サーバーが数百万のノードで焼き尽くされると思います。さらに、毎時のインポートを見ると、少なくとも1秒に1回はnode_save（）を作成することになります。 Drupal）には多すぎて、パフォーマンスの問題を引き起こします。

その背後にある理由は、これらのコンテンツのためです。フックメカニズムは必要ありません。pathautoは必要ありません（ただし、手動でエイリアスを作成できます。pathautoよりもはるかに安価です）。フィールドは必要ありません...書き込み単純な「INSERT」クエリは、node_save（）またはentity_save（）よりも100倍高速です。

1/IMHO最良のオプションは、データインポート用のカスタムテーブルとカスタムモジュールで、Drupal統合用のビューハンドラーを記述します。

2 /時間ごとのインポート中、データベースキャッシュは無効になります。時間がかかりすぎる場合は、レプリケーションについて考えることができます。最も簡単な形式では、2つの同一のテーブルを作成し、最初のテーブルを使用し、2番目のテーブルにインポートし、2番目のテーブルを使用するようにDrupal構成を切り替え、2番目のテーブルを最初のテーブルに同期します（その後オプションで別の解決策は、カスタムインポートスクリプトにあり、INSERT/UPDATEクエリを準備してグループ化し、1つのトランザクションで最後にのみ送信して、データベースの書き込み時間を短縮します。

2
jcisio