Importazione di origini dati di file flat di grandi dimensioni con Drupal 7 con integrazione di Views 3

Il mio obiettivo è quello di produrre un metodo rapido, affidabile e automatizzato per accedere ai dati di sola lettura contenuti in diverse fonti di dati di file flat di grandi dimensioni ( CSV , larghezza fissa e documenti XML) utilizzando Drupal 7 su cui è possibile eseguire query con l'utilizzo di Views 3 modulo. Preferirei utilizzare i moduli già disponibili, ma la costruzione di un modulo personalizzato è anche un'opzione.

Per aiutare a escludere moduli e metodi non adatti all'attività, ecco le statistiche sui file con cui sto lavorando:

• Importazione annuale: file CSV di 8.500.000 righe . (Eliminato e ricaricato ogni anno. Ha la chiave primaria.)
• Importazione settimanale: file a larghezza fissa di 350.000 righe. (Eliminato e ricaricato settimanalmente. Nessuna chiave primaria .)
• Importazione oraria: file CSV a 3.400 righe . (Vorrebbe aggiornare e sincronizzare il più spesso possibile, ma non più di ogni 20 minuti. Ha la chiave primaria)
• Importazione giornaliera: file XML di 200 elementi. (Eliminati e ricaricati quotidianamente. Ha la chiave primaria)

La conversione tra i tre formati non è un problema e può essere eseguita se migliorerà le prestazioni di importazione o consentirà di rendere disponibili strumenti migliori. ( AWK per Fixed Width to CSV , ecc.) Il recupero e l'automazione della conversione sono facili tramite gli script cron e sh , ma devono comunque automatizzare l'integrazione di Drupal 7. L'uso di tabelle personalizzate è anche possibile fintanto che vews può fare riferimento ai dati usando le relazioni.

Quale sarebbe la migliore pratica per realizzare questo tipo di integrazione dei dati con Drupal 7? Inoltre, sto tralasciando alcuni dettagli importanti riguardanti i dati o ciò che sto cercando di realizzare?

Ecco alcuni progetti che sto attualmente guardando per trovare una soluzione. Vorrei approfondire questo aspetto per aiutare gli altri a decidere quale strada prendere quando si lavora con importazioni di dati più grandi.

Importazione di dati in nodi:

• Feed (attualmente Alpha per D7)

I feed importeranno i dati in modo affidabile. La velocità è ragionevole per le origini dati più piccole ma è troppo lenta per le tabelle da 300k +.

Automazione disponibile utilizzando cron e Job Scheduler (attualmente Alpha per D7).

• Migrare

Non avere un indice o una chiave univoca disponibile nei dati di origine rende questo difficile da usare. È più veloce dei feed, ma è ancora lento per importare tabelle molto grandi.

L'automazione è disponibile via drush e cron.

Tabelle personalizzate anziché nodi

• Modulo dati (attualmente Alpha per D7)

Il modulo dati sembra molto promettente, ma al momento è molto difettoso per D7. I requisiti di velocità di automazione e importazione verrebbero facilmente soddisfatti utilizzando i dati, ma manca l'affidabilità. L' integrazione delle viste (link è per D6) sembra molto promettente.

• Procedura guidata tabella (non disponibile per D7)

Aggiunto questo per riferimento. Non esiste un candidato D7 a questo punto, ma potrebbe fungere da punto di partenza per un modulo personalizzato.

• Schema visualizzazioni (abbandonato, solo D6)

Aggiunto questo per riferimento. Questo sembra essere stato assorbito dalla Creazione guidata Tabella in Drupal 6. Ancora una volta, aggiunto solo come riferimento.

• Importatore (RC2 per D7)

Sembra richiedere la Creazione guidata tabella (solo D6) per l' integrazione di Views . Aggiunto come riferimento, ma non soddisfa i requisiti di Views.

@MPD - Aggiunte "Tabelle personalizzate" come possibile soluzione e moduli espansi. Grazie per questa aggiunta.

Il mio istinto mi dice che questo piano farà incendiare i tuoi server ...

Seriamente, se stai sfornando così tanti dati, penso che devi conservare i dati in un'origine dati esterna e quindi integrarli con Drupal.

Il mio pensiero iniziale sarebbe di usare due database per i dati esterni, in modo da poter fare l'importazione settimanale senza disturbare troppo le cose. In altre parole, avviare il database A, quindi importarlo in B. Al termine dell'importazione, impostare B come sorgente live. Quindi cancellare e importare in A.

Ho fatto molta integrazione di origini dati esterne in Drupal, e non è poi così difficile. Ho dato una panoramica in piano di transizione per l'abominio PHP5 a Drupal . Questo era per Drupal 6, ma sostanzialmente lo stesso vale per Drupal 7. In sostanza, simuli cosa fa l'API CCK / Fields con la tua interfaccia.

Tuttavia, non avere un UUID per il database settimanale è davvero una chiave. Quella parte richiede molto però, più che può essere fornita in un forum di domande e risposte come questo.

Se vuoi davvero seguire la strada dell'importazione, salterei su Feed e Migrate e scriverò il tuo script di importazione. Fondamentalmente, esegui il processo iniziale di bookstrap da index.php, esegui una query sull'origine dati, crea i tuoi nodi e quindi li salvi. La creazione di nodi a livello di programmazione è semplice.

Il modo migliore per iniziare è creare un nodo con l'interfaccia utente, quindi stamparlo e replicare l'oggetto con il codice nello script di importazione. Tassonomia, file e noderef sono parti difficili, ma è sufficiente acquisire familiarità con queste parti dell'API per creare queste proprietà degli oggetti. Una volta che hai un oggetto nodo valido, puoi semplicemente fare un node_save (). Assicurati di impostare un limite molto grande con set_time_limit () in modo che lo script venga eseguito.

MODIFICA SOTTO PER INDIRIZZARE CHIARIMENTO / ESPANSIONE:

Personalmente, abbiamo smesso di usare gli approcci basati sul modulo contrib per l'importazione dei dati qualche tempo fa. Funzionano principalmente bene, ma alla fine abbiamo trascorso troppo tempo a combatterli e abbiamo deciso che il rapporto costi / benefici era troppo basso.

Se hai davvero bisogno dei dati in Drupal, la mia opinione su uno script di importazione personalizzato non è cambiata. Uno dei moduli a cui fai riferimento potrebbe essere utilizzato come punto di partenza per come creare gli oggetti nodo, quindi scorrere semplicemente i nodi di generazione dei dati e salvarli. Se si dispone di un PK, è possibile aggiungere facilmente una logica per cercare nel database e node_load (), modificare e salvare. Uno script di importazione funziona davvero solo per poche ore se conosci l'API Drupal.

Se l'integrazione delle viste è una chiave (e sembra che si basi sulla modifica) e desideri seguire l' approccio delle tabelle esterne, l'opzione migliore è fare un modulo personalizzato e implementare hook_views_data per ottenere i tuoi dati nelle viste. Molto probabilmente, dovrai comunque personalizzare il modulo per supportare l'origine dati, quindi aggiungere questo hook non dovrebbe essere molto più lavoro. I moduli TW e Data dovrebbero avere qualche esempio per iniziare.

Personalmente, tuttavia, non ho mai trovato davvero utile l'integrazione delle viste con i dati esterni. Nei casi in cui l'ho considerato, i dati erano troppo "diversi" per funzionare bene con un approccio basato sulle viste. Finisco semplicemente con il metodo che ho descritto nel link "abomination" sopra.

Penso che un approccio basato sul nodo (o addirittura basato sull'entità) brucerà il tuo server con milioni di nodi. Inoltre, osservando la tua importazione oraria, ciò significa che eseguirai un node_save () almeno una volta al secondo. Questo è troppo per Drupal e causa un problema di prestazioni.

Il motivo è che per quel contenuto, non avrai bisogno di alcun meccanismo di aggancio, non avrai bisogno di pathauto (ma puoi creare manualmente alias, è molto più economico di pathauto), non avrai bisogno di campi ... Scrivi un la semplice query "INSERT" è 100 volte più veloce di node_save () o entity_save ().

1 / IMHO l'opzione migliore è una tabella personalizzata e un modulo personalizzato per l'importazione dei dati, quindi scrivere i gestori Views per l'integrazione di Drupal.

2 / La cache del database viene invalidata durante l'importazione oraria. Se impiega troppo tempo, puoi pensare a una replica. Nella forma più semplice, crea due tabelle identiche, usa la prima, importa nella seconda, cambia la tua configurazione Drupal per usare la seconda tabella, sincronizza la seconda tabella con la prima (quindi, facoltativamente, ritorna alla prima). Un'altra soluzione è nello script di importazione personalizzato, preparare e raggruppare le query INSERT / UPDATE, quindi inviarlo solo alla fine in una transazione per ridurre il tempo di scrittura del database.