Importieren großer Flat-File-Datenquellen mit Drupal 7 mit Views 3-Integration

Mein Ziel ist es, mit Drupal 7 eine schnelle, zuverlässige und automatisierte Methode für den Zugriff auf schreibgeschützte Daten in mehreren sehr großen Flat-File-Datenquellen ( CSVs , Dokumente mit fester Breite und XML-Dokumente) zu erstellen, die mit Views 3 abgefragt werden können Modul. Ich würde es vorziehen, bereits verfügbare Module zu verwenden, aber das Erstellen eines benutzerdefinierten Moduls ist auch eine Option.

Um Module und Methoden auszuschließen, die für die Aufgabe nicht geeignet sind, finden Sie hier die Statistiken zu den Dateien, mit denen ich arbeite:

• Jährlicher Import: 8.500.000 Zeilen CSV Datei. (Jährlich gelöscht und neu geladen. Hat Primärschlüssel.)
• Wöchentlicher Import: Datei mit 350.000 Zeilen fester Breite. (Wöchentlich gelöscht und neu geladen. Kein Primärschlüssel .)
• Stündlicher Import: 3.400 Zeilen CSV Datei. (Möchte so oft wie möglich aktualisieren und synchronisieren, jedoch nicht mehr als alle 20 Minuten. Hat Primärschlüssel)
• Täglicher Import: XML-Datei mit 200 Elementen. (Täglich geleert und neu geladen. Hat Primärschlüssel)

Das Konvertieren zwischen den drei Formaten ist kein Problem und kann durchgeführt werden, wenn dadurch die Importleistung verbessert oder bessere Tools verfügbar gemacht werden. ( AWK für feste Breite zu CSV usw.) Die Automatisierung des Abrufs und der Konvertierung ist über Cron- und Sh- Skripte einfach , muss jedoch die Drupal 7-Integration noch automatisieren. Die Verwendung von benutzerdefinierten Tabellen ist auch möglich, solange vews die Daten mithilfe von Beziehungen referenzieren kann.

Was wäre die beste Vorgehensweise, um diese Art der Datenintegration mit Drupal 7 durchzuführen? Lasse ich auch wichtige Details zu den Daten aus oder was versuche ich zu erreichen?

Hier sind einige Projekte, an denen ich gerade arbeite, um eine Lösung zu finden. Ich möchte dies erweitern, um anderen bei der Entscheidung zu helfen, welchen Weg sie bei der Arbeit mit größeren Datenimporten einschlagen müssen.

Daten in Knoten importieren:

• Feeds (Derzeit Alpha für D7)

Feeds importieren die Daten zuverlässig. Die Geschwindigkeit ist für die kleineren Datenquellen angemessen, für die 300k + -Tabellen jedoch zu langsam.

Automatisierung über cron und Job Scheduler möglich (aktuell Alpha für D7).

• Wandern

Das Fehlen eines Index oder eines eindeutigen Schlüssels in den Quelldaten erschwert die Verwendung. Es ist schneller als Feeds, aber dennoch langsam, um die sehr großen Tabellen zu importieren.

Die Automatisierung erfolgt über drush und cron.

Benutzerdefinierte Tabellen anstelle von Knoten

• Datenmodul (derzeit Alpha für D7)

Das Datenmodul sieht sehr vielversprechend aus, ist aber im Moment für D7 sehr fehlerhaft. Die Anforderungen an die Automatisierung und die Importgeschwindigkeit können mithilfe von Daten problemlos erfüllt werden, die Zuverlässigkeit ist jedoch unzureichend. Die Views-Integration (Link ist für D6) sieht sehr vielversprechend aus.

• Tabellenassistent (Nicht verfügbar für D7)

Dies wurde als Referenz hinzugefügt. Derzeit gibt es keinen D7-Kandidaten, er könnte jedoch als Ausgangspunkt für ein benutzerdefiniertes Modul dienen.

• Views Schema (Verlassen, nur D6)

Dies wurde als Referenz hinzugefügt. Dies scheint vom Tabellenassistenten in Drupal 6 übernommen worden zu sein.

• Importer (RC2 für D7)

Scheint den Tabellenassistenten (nur D6) für die Views- Integration zu benötigen . Als Referenz hinzugefügt, erfüllt aber nicht die Anforderungen für Ansichten.

@MPD - "Benutzerdefinierte Tabellen" als mögliche Lösung hinzugefügt und Module erweitert. Vielen Dank für diesen Zusatz.

Mein Bauch sagt mir, dass dieser Plan Ihre Server in Flammen aufgehen lässt ...

Im Ernst, wenn Sie so viele Daten abrühren, sollten Sie die Daten meiner Meinung nach in einer externen Datenquelle speichern und dann in Drupal integrieren.

Mein erster Gedanke wäre, zwei Datenbanken für die externen Daten zu verwenden, damit Sie den wöchentlichen Import ohne störende Dinge zu viel tun können. Mit anderen Worten, setzen Sie die Datenbank A in Betrieb und importieren Sie sie in B. Wenn der Import abgeschlossen ist, machen Sie B zur Live-Quelle. Dann wischen und in A importieren.

Ich habe viele externe Datenquellen in Drupal integriert, und es ist wirklich nicht so schwer. Ich gab Drupal einen Überblick in Transition Plan für PHP5 Abomination . Das galt für Drupal 6, aber das Gleiche gilt grundsätzlich für Drupal 7. Im Wesentlichen simulieren Sie, was die CCK / Fields-API mit Ihrer eigenen Oberfläche macht.

Das Fehlen einer UUID für die wöchentliche Datenbank ist jedoch eine echte Herausforderung. Dieser Teil erfordert jedoch viel, mehr, das in einem solchen Q / A-Forum bereitgestellt werden kann.

Wenn Sie wirklich den Importweg einschlagen möchten, würde ich auf Feeds und Migrate verzichten und Ihr eigenes Importskript schreiben. Grundsätzlich führen Sie den ersten Bookstrap-Prozess aus index.php aus, fragen Ihre Datenquelle ab, erstellen Ihre Knoten und speichern sie dann. Das programmgesteuerte Erstellen von Knoten ist einfach.

Der beste Weg, um damit zu beginnen, besteht darin, einen Knoten mit der Benutzeroberfläche zu erstellen, ihn dann auszudrucken und das Objekt mit Code in Ihrem Importskript zu replizieren. Taxonomie, Dateien und Noderefs sind schwierige Teile, aber Sie müssen sich nur mit diesen Teilen der API vertraut machen, um diese Objekteigenschaften aufzubauen. Sobald Sie ein gültiges Knotenobjekt haben, können Sie einfach eine node_save () ausführen. Stellen Sie sicher, dass Sie mit set_time_limit () ein sehr großes Limit festlegen, damit Ihr Skript ausgeführt wird.

BEARBEITEN SIE UNTEN AN DIE ADRESSENKLÄRUNG / ERWEITERUNG:

Persönlich haben wir vor einiger Zeit aufgehört, die auf Contrib-Modulen basierenden Ansätze für Datenimporte zu verwenden. Sie funktionieren größtenteils gut, aber wir haben viel zu viel Zeit damit verbracht, sie zu bekämpfen, und festgestellt, dass das Kosten-Nutzen-Verhältnis zu niedrig war.

Wenn Sie die Daten in Drupal wirklich benötigen, hat sich meine Meinung zu einem benutzerdefinierten Importskript nicht geändert. Eines der Module, auf die Sie verweisen, kann als Ausgangspunkt für die Erstellung der Knotenobjekte verwendet werden. Durchlaufen Sie dann einfach Ihre Datenerstellungsknoten und speichern Sie sie. Wenn Sie eine PK haben, können Sie einfach Logik hinzufügen, um die Datenbank und node_load () zu durchsuchen, zu ändern und zu speichern. Ein Importskript ist wirklich nur ein paar Stunden Arbeit, wenn Sie die Drupal-API kennen.

Wenn die Ansichtenintegration ein Schlüssel ist (und es sich so anhört, als ob sie auf der Bearbeitung basiert) und Sie den Ansatz für externe Tabellen ausführen möchten, sollten Sie am besten ein benutzerdefiniertes Modul ausführen und hook_views_data implementieren zu , um Ihre Daten in Ansichten zu integrieren. Höchstwahrscheinlich werden Sie sowieso ein benutzerdefiniertes Modul verwenden, um Ihre Datenquelle zu unterstützen. Das Hinzufügen dieses Hooks sollte also nicht viel mehr Arbeit bedeuten. Die TW- und Data-Module sollten einige Beispiele enthalten, um Sie zum Laufen zu bringen.

Persönlich habe ich die Integration von Views in externe Daten jedoch nie als wirklich lohnenswert empfunden. In den Fällen, in denen ich darüber nachgedacht habe, waren die Daten einfach zu "unterschiedlich", um mit einem auf Ansichten basierenden Ansatz gut zu funktionieren. Am Ende verwende ich einfach die Methode, die ich oben unter "Abomination" beschrieben habe.

Ich denke, ein knotenbasierter (oder sogar entitätsbasierter) Ansatz wird Ihren Server mit Millionen von Knoten ausbrennen. Wenn Sie sich außerdem Ihren stündlichen Import ansehen, bedeutet dies, dass Sie mindestens einmal pro Sekunde eine node_save () durchführen. Das ist zu viel für Drupal und verursacht ein Leistungsproblem.

Der Grund dafür ist, dass Sie für diese Inhalte keinen Hook-Mechanismus benötigen, kein Pathauto benötigen (Sie können jedoch einen Alias ​​manuell erstellen, dies ist viel billiger als bei Pathauto), keine Felder benötigen ... Schreiben Sie eine einfache "INSERT" -Abfrage ist 100x schneller als node_save () oder entity_save ().

1 / IMHO die beste Option ist eine benutzerdefinierte Tabelle und ein benutzerdefiniertes Modul für Ihren Datenimport, dann schreiben Sie Views-Handler für die Drupal-Integration.

2 / Der Datenbankcache wird während des stündlichen Imports ungültig. Wenn es zu lange dauert, können Sie über eine Replikation nachdenken. Erstellen Sie in der einfachsten Form zwei identische Tabellen, verwenden Sie die erste, importieren Sie die zweite, ändern Sie Ihre Drupal-Konfiguration, um die zweite Tabelle zu verwenden, synchronisieren Sie die zweite Tabelle mit der ersten (und wechseln Sie dann optional wieder zur ersten). Eine andere Lösung besteht darin, in Ihrem benutzerdefinierten Importskript die INSERT / UPDATE-Abfragen vorzubereiten und zu gruppieren und sie dann nur am Ende in einer Transaktion zu senden, um die Schreibzeit für die Datenbank zu verkürzen.