Importation de grandes sources de données de fichier plat avec Drupal 7 avec intégration de Views 3

Question

Mon objectif est de produire une méthode rapide, fiable et automatisée pour accéder aux données en lecture seule contenues dans plusieurs sources de données très volumineuses ( CSV s, largeur fixe et documents XML) en utilisant Drupal 7 qui peut être interrogé en utilisant le module Views . Je préférerais déjà utiliser modules disponibles, mais la création d'un module personnalisé est également une option.

Pour vous aider à exclure les modules et méthodes non adaptés à la tâche, voici les statistiques sur les fichiers avec lesquels je travaille:

Importation annuelle: 8 500 000 lignes CSV fichier. (Purgé et rechargé chaque année. Dispose d'une clé primaire.)
Importation hebdomadaire: fichier de largeur fixe de 350 000 lignes. (Purgé et rechargé chaque semaine. Pas de clé primaire .)
Importation horaire: 3 400 lignes CSV fichier. (Voudrait mettre à jour et synchroniser aussi souvent que possible, mais pas plus que toutes les 20 minutes. Dispose d'une clé primaire)
Importation quotidienne: fichier XML de 200 éléments. (Purgé et rechargé quotidiennement. Dispose d'une clé primaire)

La conversion entre les trois formats n'est pas un problème et peut être effectuée si elle améliore les performances d'importation ou permet de mettre à disposition de meilleurs outils. ( AWK for Fixed Width to CSV , etc.) L'automatisation de la récupération et de la conversion est facile via cron et sh scripts, mais doit encore automatiser l'intégration Drupal 7. L'utilisation de tables personnalisées est également possible tant que vews peut référencer les données à l'aide de relations.

Quelle serait la meilleure pratique pour réaliser ce type d'intégration de données avec Drupal 7? De plus, est-ce que je laisse de côté des détails importants concernant les données ou ce que j'essaie d'accomplir?

Voici quelques projets que j'examine actuellement pour trouver une solution. Je voudrais développer cela pour aider les autres à décider de la route à suivre lorsque vous travaillez avec des importations de données plus importantes.

Importation de données dans des nœuds:

Flux (actuellement Alpha pour D7)

Feeds importera les données de manière fiable. La vitesse est raisonnable pour les sources de données plus petites mais est trop lente pour les tables de 300k +.

Automatisation disponible en utilisant cron et Job Scheduler (actuellement Alpha pour D7).

Migrer

Le fait de ne pas avoir d'index ou de clé unique disponible dans les données source rend cette utilisation difficile. Il est plus rapide que les flux, mais reste lent à importer les très grandes tables.

L'automatisation est disponible via drush et cron.

Tables personnalisées au lieu de nœuds

Module de données (actuellement Alpha pour D7)

Le module de données semble très prometteur, mais est très bogué pour D7 pour le moment. Les exigences d'automatisation et de vitesse d'importation seraient facilement satisfaites à l'aide des données, mais la fiabilité fait défaut. intégration des vues (le lien est pour D6) semble très prometteur.

Assistant de table (Non disponible pour D7)

Ajouté ceci pour référence. Il n'y a pas de candidat D7 à ce stade, mais pourrait servir de point de départ pour un module personnalisé.

Schéma de vues (abandonné, D6 uniquement)

Ajouté ceci pour référence. Cela semble avoir été absorbé par le tableau Wizard in Drupal 6. Encore une fois, ajouté uniquement pour référence.

Importateur (RC2 pour D7)

Semble exiger Assistant Tablea (D6 uniquement) pour l'intégration Views . Ajouté pour référence, mais ne répond pas aux exigences de vues.

@MPD - Ajout de "Tableaux personnalisés" comme solution possible et extension des modules. Merci pour cet ajout.

mpdonadio · Accepted Answer

Mon instinct me dit que ce plan fera prendre feu à vos serveurs ...

Sérieusement, si vous générez autant de données, je pense que vous devez conserver les données dans une source de données externe, puis l'intégrer à Drupal.

Ma pensée initiale serait d'utiliser deux bases de données pour les données externes, afin que vous puissiez faire trop de l'importation hebdomadaire sans trop de choses dérangeantes. En d'autres termes, installez la base de données A, puis importez-la dans B. Une fois l'importation terminée, définissez B comme source active. Ensuite, essuyez et importez dans A.

J'ai fait beaucoup d'intégration de sources de données externes dans Drupal, et ce n'est vraiment pas si difficile. J'ai donné un aperçu dans Plan de transition pour l'abomination PHP5 vers Drupal . C'était pour Drupal 6, mais la même chose s'applique essentiellement à Drupal 7. Essentiellement, vous simulez ce que l'API CCK/Fields fait avec votre propre interface).

Ne pas avoir d'UUID pour la base de données hebdomadaire jette vraiment une clé dans les travaux, cependant. Cette partie nécessite cependant beaucoup plus, ce qui peut être fourni dans un forum Q/A comme celui-ci.

Si vous voulez vraiment emprunter la voie de l'importation, je serais prêt à utiliser Feeds and Migrate et j'écrirais votre propre script d'importation. Fondamentalement, vous effectuez le processus de création de liens initiaux à partir d'index.php, interrogez votre source de données, créez vos nœuds, puis enregistrez-les. Faire des nœuds par programmation est facile.

La meilleure façon de commencer est de créer un nœud avec l'interface utilisateur, puis de l'imprimer et de répliquer l'objet avec du code dans votre script d'importation. La taxonomie, les fichiers et les noderefs sont des parties difficiles, mais il vous suffit de vous familiariser avec ces parties de l'API pour créer ces propriétés d'objet. Une fois que vous avez un objet nœud valide, vous pouvez simplement faire un node_save (). Assurez-vous de définir une très grande limite avec set_time_limit () pour que votre script s'exécute.

MODIFIER CI-DESSOUS POUR ADRESSER LA CLARIFICATION/L'EXTENSION:

Personnellement, nous avons cessé d'utiliser les approches basées sur le module contrib pour les importations de données il y a quelque temps. Ils fonctionnent généralement bien, mais nous venons de passer beaucoup trop de temps à les combattre et avons décidé que le rapport coût/bénéfice était trop faible.

Si vous avez vraiment besoin des données dans Drupal proprement dit, mon opinion sur un script d'importation personnalisé n'a pas changé. L'un des modules que vous référencez pourrait être utilisé comme point de départ pour la construction de la des objets de noeud, puis parcourez simplement vos noeuds de génération de données et enregistrez-les. Si vous avez un PK, vous pouvez facilement ajouter de la logique pour rechercher la base de données et node_load (), modifier et enregistrer. Un script d'importation ne prend en réalité que quelques heures fonctionne si vous connaissez l'API Drupal.

Si l'intégration des vues est une clé (et qu'il semble qu'elle soit basée sur la modification) et que vous souhaitez faire l'approche des tables externes, votre meilleure option est de faire un module personnalisé et d'implémenter hook_views_data pour obtenir vos données en vues. Plus que probablement, vous aurez quand même un module personnalisé pour prendre en charge votre source de données, donc l'ajout de ce crochet ne devrait pas être beaucoup plus de travail. Les modules TW et Data devraient avoir un exemple pour vous aider à démarrer.

Personnellement, cependant, je n'ai jamais trouvé que l'intégration des vues avec des données externes valait vraiment la peine. Dans les cas où je l'ai considéré, les données étaient tout simplement trop "différentes" pour bien fonctionner avec une approche basée sur les vues. Je finis par utiliser la méthode que j'ai décrite dans le lien "abomination" ci-dessus.

jcisio · Answer

Je pense qu'une approche basée sur un nœud (ou même une entité) brûlera votre serveur avec des millions de nœuds. De plus, en regardant votre importation horaire, cela signifie que vous ferez un node_save () au moins une fois par seconde. C'est trop pour Drupal et provoquer un problème de performances.

La raison derrière cela est pour ces contenus, vous n'aurez besoin d'aucun mécanisme de hook, vous n'aurez pas besoin de pathauto (mais vous pouvez créer manuellement un alias, c'est beaucoup moins cher que pathauto), vous n'aurez pas besoin de champs ... la simple requête "INSERT" est 100 fois plus rapide que node_save () ou entity_save ().

1/À mon humble avis, la meilleure option est une table personnalisée et un module personnalisé pour l'importation de vos données, puis écrivez des gestionnaires de vues pour l'intégration Drupal.

2/Le cache de la base de données est invalidé lors de l'importation horaire. Si cela prend trop de temps, vous pouvez penser à une réplication. Dans la forme la plus simple, créez deux tables identiques, utilisez la première, importez dans la seconde, changez votre configuration Drupal pour utiliser la deuxième table, synchronisez la 2ème table avec la 1ère (puis basculez éventuellement retour à la première) .Une autre solution est dans votre script d'importation personnalisé, préparez et groupez les requêtes INSERT/UPDATE, puis envoyez-le à la fin en une seule transaction pour réduire le temps d'écriture de la base de données.