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

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 très grandes sources de données de fichiers plats ( CSV , Fixed Width et XML docs) en utilisant Drupal 7 qui peut être interrogé à l'aide de Views 3 module. Je préférerais utiliser des modules déjà disponibles, mais la construction 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: fichier CSV de 8 500 000 lignes . (Purgé et rechargé chaque année. Dispose d'une clé primaire.)
• Importation hebdomadaire: fichier à largeur fixe de 350 000 lignes. (Purgé et rechargé chaque semaine. Pas de clé primaire .)
• Importation horaire: fichier CSV de 3 400 lignes . (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 pour Fixed Width en CSV , etc.) L'automatisation de la récupération et de la conversion est facile via les scripts cron et sh , mais doit encore automatiser l'intégration de Drupal 7. L'utilisation de tableaux personnalisés 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 lors de l'utilisation d'importations de données plus importantes.

Importation de données dans des nœuds:

• Flux (actuellement Alpha pour D7)

Les flux importeront les données de manière fiable. La vitesse est raisonnable pour les petites sources de données, mais elle est trop lente pour les tables de 300k +.

Automatisation disponible avec 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 Data 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. L' intégration des vues (lien est pour D6) semble très prometteuse.

• 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 des vues (abandonné, D6 uniquement)

Ajouté ceci pour référence. Cela semble avoir été absorbé par l'assistant de table dans Drupal 6. Encore une fois, ajouté uniquement pour référence.

• Importateur (RC2 pour D7)

Semble nécessiter l' assistant de table (D6 uniquement) pour l' intégration des vues . Ajouté pour référence, mais ne répond pas aux exigences de vues.

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

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, de sorte que vous puissiez faire 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 du plan de transition pour l'abomination PHP5 vers Drupal . C'était pour Drupal 6, mais la même chose s'applique fondamentalement à Drupal 7. Essentiellement, vous simulez ce que fait l'API CCK / Fields avec votre propre interface.

Le fait de 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 qui peut être fourni dans un forum Q / A comme celui-ci.

Si vous voulez vraiment emprunter la voie d'importation, je serais sur 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_r 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 nœud_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, 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 des objets de nœud, puis parcourez simplement vos nœuds 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 vraiment que quelques heures 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 de toute façon 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.

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 allez faire un node_save () au moins une fois par seconde. C'est trop pour Drupal et cela cause 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 ... une simple requête "INSERT" est 100 fois plus rapide que node_save () ou entity_save ().

1 / À mon humble avis, la meilleure option est un tableau personnalisé 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 revenez éventuellement à 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 uniquement à la fin en une seule transaction pour réduire le temps d'écriture de la base de données.