ビュー3統合を備えたDrupal 7を使用した大きなフラットファイルデータソースのインポート


13

私の目標は、ビュー3を使用して照会できるDrupal 7を使用して、いくつかの非常に大きなフラットファイルデータソース(CSV、固定幅、XMLドキュメント)に含まれる読み取り専用データにアクセスするための高速で信頼性の高い自動化された方法を作成することですモジュール。すでに利用可能なモジュールを使用することを希望しますが、カスタムモジュールの構築もオプションです。

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

  • 年間インポート:8,500,000行のCSVファイル。(毎年パージおよび再ロードされます。主キーがあります。)
  • 毎週のインポート:350,000行の固定幅ファイル。(毎週パージおよび再ロードされます主キーはありません。)
  • 毎時インポート:3,400行のCSVファイル。(可能な限り頻繁に更新および同期したいが、20分ごとにしたい。主キーがある)
  • 毎日のインポート:200アイテムのXMLファイル。(毎日パージおよび再ロードされます。主キーがあります)

3つの形式間での変換は問題ではなく、インポートのパフォーマンスが向上するか、より優れたツールを使用できるようにする場合に実行できます。(CSVへの固定幅のAWKなど)cronおよびshスクリプトを使用すると、取得と変換の自動化は簡単ですが、Drupal 7統合を自動化する必要があります。vewsがリレーションシップを使用してデータを参照できる限り、カスタムテーブルの使用も可能です。

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


以下は、解決策を見つけるために現在検討しているプロジェクトです。これを拡張して、大規模なデータインポートで作業する場合に他のユーザーがどのルートを取るかを決定できるようにします。

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

フィードはデータを確実にインポートします。小さいデータソースでは速度は妥当ですが、300k +テーブルでは速度が遅すぎます。

cronおよびJob Scheduler(現在はAlpha for D7)を使用して自動化が可能です。

ソースデータでインデックスまたは一意のキーを使用できないため、これを使用するのが難しくなります。フィードよりも高速ですが、非常に大きなテーブルのインポートは依然として低速です。

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

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

データモジュールは非常に有望に見えるが、現時点ではD7のための非常にバギーです。自動化とインポート速度の要件は、データを使用して簡単に満たされますが、信頼性が不足しています。ビューの統合は、(リンクはD6のためである)非常に有望に見えます。

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

参照用にこれを追加しました。これは、Drupal 6のテーブルウィザードによって吸収されたようです。ここでも、参照用にのみ追加されました。

ビューの統合にテーブルウィザード(D6のみ)が必要なようです。参照用に追加されましたが、ビューの要件を満たしていません。


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

回答:


8

私の腸は、この計画があなたのサーバーに火をつけることを教えてくれます...

真剣に、その量のデータを大量に消費している場合、データを外部データソースに保持し、それをDrupalと統合する必要があると思います。

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

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

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

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

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

明確化/拡張に対応するために以下の編集:

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

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

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

しかし、個人的には、外部データとビューの統合が本当に価値があるとは思いませんでした。私がそれを検討した場合、データはビューベースのアプローチでうまく機能するには「違いすぎ」ました。最終的には、上記の「アボミネーション」リンクで説明した方法を使用します。


あなたは3つの優れた点を挙げてきました。それに応じて質問を調整します。大量のインポートとエクスポートは便利ですが、この時点で数十万、またはおそらく数百万のノードをインポートする場合、せいぜい非現実的です。また、カスタムテーブルは、ビューと統合できる場合は非常に便利です。返信@MPDをありがとう。
Citricguy

2

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

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.