it-swarm.com.de

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

Mein Ziel ist es, eine schnelle, zuverlässige und automatisierte Methode für den Zugriff auf schreibgeschützt Daten zu erstellen, die in mehreren sehr großen Flat-File-Datenquellen enthalten sind ( [~ # ~] csv [~ # ~] s, feste Breite und XML-Dokumente) mit Drupal 7, die gegen die Verwendung der Views abgefragt werden können 3 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 nicht für die Aufgabe 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 fester Breite von 350.000 Zeilen. (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 gelöscht 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.) Abruf- und Konvertierungsautomatisierung ist einfach über cron und sh Skripte, muss aber noch die Integration von Drupal 7) automatisieren. Die Verwendung von benutzerdefinierten Tabellen ist auch möglich, solange vews kann die Daten über Beziehungen referenzieren.

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, die ich gerade suche, 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 sollen.

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 über 300.000 Tabellen jedoch zu langsam.

Automatisierung mit cron und Job Scheduler (derzeit Alpha für D7) verfügbar.

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

Die Automatisierung erfolgt über Drush und Cron.

Benutzerdefinierte Tabellen anstelle von Knoten

Das Datenmodul sieht sehr vielversprechend aus, ist aber momentan für D7 sehr fehlerhaft. Die Anforderungen an die Automatisierungs- und Importgeschwindigkeit würden mithilfe von Daten leicht erfüllt, aber es mangelt an Zuverlässigkeit. Die Ansichten Integration (Link ist für D6) sieht sehr vielversprechend aus.

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

Dies wurde als Referenz hinzugefügt. Dies scheint von Table Wizard in Drupal 6. Auch hier nur als Referenz hinzugefügt) übernommen worden zu sein.

Scheint Tabellenassistent (nur D6) für die Integration von Ansichten zu erfordern. 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.

13
Citricguy

Mein Bauch sagt mir, dass dieser Plan Ihre Server in Brand setzen wird ...

Im Ernst, wenn Sie so viele Daten verarbeiten, müssen Sie die Daten meiner Meinung nach in einer externen Datenquelle aufbewahren und dann in Drupal integrieren.

Mein erster Gedanke war, zwei Datenbanken für die externen Daten zu verwenden, damit Sie den wöchentlichen Import durchführen können, ohne die Dinge zu sehr zu stören. Mit anderen Worten: Starten Sie die Datenbank A 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 viel externe Datenquellen in Drupal integriert, und es ist wirklich nicht so schwer. Ich gab einen Überblick in Übergangsplan für PHP5-Abscheulichkeit zu Drupal . Das war für Drupal 6, aber das Gleiche gilt grundsätzlich für Drupal 7. 7. Im Wesentlichen simulieren Sie, was die CCK/Fields-API mit Ihrer eigenen Schnittstelle macht.

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

Wenn Sie wirklich den Importweg beschreiten möchten, würde ich auf Feeds and Migrate verzichten und Ihr eigenes Importskript schreiben. Grundsätzlich führen Sie den ersten Bookstrap-Prozess über index.php durch, 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 zu drucken 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 ein 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, UM DIE KLARIFIKATION/ERWEITERUNG ZU ADRESSIEREN:

Persönlich haben wir vor einiger Zeit die Verwendung der Contrib-Modul-basierten Ansätze für Datenimporte eingestellt. Sie funktionieren meistens gut, aber wir haben einfach viel zu viel Zeit damit verbracht, sie zu bekämpfen, und entschieden, dass Kosten/Nutzen zu niedrig waren.

Wenn Sie die Daten in Drupal richtig) 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 des verwendet werden Knotenobjekte, dann durchlaufen Sie einfach Ihre Datenerstellungsknoten und speichern 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 dauert wirklich nur wenige Stunden funktionieren, wenn Sie die API Drupal API) kennen.

Wenn die Integration von Ansichten 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, ist es am besten, ein benutzerdefiniertes Modul zu erstellen und hook_views_data zu implementieren, um abzurufen Ihre Daten in Ansichten. Höchstwahrscheinlich werden Sie ohnehin ein benutzerdefiniertes Modul verwenden, um Ihre Datenquelle zu unterstützen. Das Hinzufügen dieses Hooks sollte also nicht viel mehr Arbeit bedeuten. Die Module TW und Data sollten ein Beispiel enthalten, um Sie zum Laufen zu bringen.

Persönlich habe ich jedoch nie festgestellt, dass sich die Integration von Ansichten in externe Daten wirklich lohnt. 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 nur die Methode, die ich oben im Link "Abomination" beschrieben habe.

8
mpdonadio

Ich denke, ein knotenbasierter (oder sogar entitätsbasierter) Ansatz wird Ihren Server mit Millionen von Knoten ausbrennen. Wenn Sie sich Ihren stündlichen Import ansehen, bedeutet dies außerdem, dass Sie mindestens einmal pro Sekunde einen node_save () erstellen. 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 (aber Sie können manuell einen Alias ​​erstellen, es ist viel billiger als Pathauto), Sie brauchen keine Felder ... Schreiben Sie ein Die einfache "INSERT" -Abfrage ist 100x schneller als node_save () oder entity_save ().

1/IMHO ist die beste Option eine benutzerdefinierte Tabelle und ein benutzerdefiniertes Modul für Ihren Datenimport. Schreiben Sie dann Views-Handler für die Integration 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 in die zweite, wechseln Sie Ihre Drupal Konfiguration, um die zweite Tabelle zu verwenden, synchronisieren Sie die 2. Tabelle mit der 1. (und wechseln Sie dann optional zurück zum ersten). Eine andere Lösung besteht in Ihrem benutzerdefinierten Importskript. Bereiten Sie die INSERT/UPDATE-Abfragen vor und gruppieren Sie sie. Senden Sie sie dann nur am Ende in einer Transaktion, um die Schreibzeit der Datenbank zu verkürzen.

2
jcisio