Importación de grandes fuentes de datos de archivos planos con Drupal 7 con integración con Views 3

Mi objetivo es producir un método rápido, confiable y automatizado para acceder a datos de solo lectura contenidos en varias fuentes de datos de archivos planos muy grandes ( CSV , ancho fijo y documentos XML) usando Drupal 7 que se puede consultar usando el Views 3 módulo. Preferiría usar módulos ya disponibles, pero construir un módulo personalizado también es una opción.

Para ayudar a descartar módulos y métodos no adecuados para la tarea, aquí están las estadísticas de los archivos con los que estoy trabajando:

• Importación anual: archivo CSV de 8,500,000 líneas . (Purgado y recargado anualmente. Tiene clave primaria).
• Importación semanal: archivo de ancho fijo de 350,000 líneas. (Purgado y recargado semanalmente. Sin clave primaria ).
• Importación por hora: archivo CSV de 3.400 líneas . (Me gustaría actualizar y sincronizar con la mayor frecuencia posible, pero no más de cada 20 minutos. Tiene clave principal)
• Importación diaria: archivo XML de 200 elementos. (Purgado y recargado diariamente. Tiene clave primaria)

La conversión entre los tres formatos no es un problema y se puede hacer si mejora el rendimiento de importación o permite que haya mejores herramientas disponibles. ( AWK para Fixed Width a CSV , etc.) La automatización de recuperación y conversión es fácil a través de los scripts cron y sh , pero aún necesita automatizar la integración de Drupal 7. El uso de tablas personalizadas también es posible siempre que las vistas puedan hacer referencia a los datos mediante relaciones.

¿Cuál sería la mejor práctica para lograr este tipo de integración de datos con Drupal 7? Además, ¿estoy omitiendo detalles importantes con respecto a los datos o lo que estoy tratando de lograr?

Aquí hay algunos proyectos que estoy buscando para encontrar una solución. Me gustaría ampliar esto para ayudar a otros a decidir qué ruta tomar al trabajar con importaciones de datos más grandes.

Importar datos a nodos:

• Feeds (actualmente Alpha para D7)

Los feeds importarán los datos de manera confiable. La velocidad es razonable para las fuentes de datos más pequeñas, pero es demasiado lenta para las tablas de más de 300k.

Automatización disponible usando cron y Job Scheduler (Actualmente Alpha para D7).

• Emigrar

No tener un índice o clave única disponible en los datos de origen hace que esto sea difícil de usar. Es más rápido que los feeds, pero aún así es lento para importar tablas muy grandes.

La automatización está disponible a través de drush y cron.

Tablas personalizadas en lugar de nodos

• Módulo de datos (actualmente Alpha para D7)

El módulo de datos parece muy prometedor, pero en este momento es muy defectuoso para D7. Los requisitos de automatización y velocidad de importación se cumplirían fácilmente utilizando datos, pero falta confiabilidad. La integración de vistas (el enlace es para D6) parece muy prometedora.

• Asistente de tabla (no disponible para D7)

Se agregó esto como referencia. No hay un candidato D7 en este momento, pero podría servir como punto de partida para un módulo personalizado.

• Esquema de vistas (Abandonado, solo D6)

Se agregó esto como referencia. Esto parece haber sido absorbido por Table Wizard en Drupal 6. Nuevamente, agregado solo como referencia.

• Importador (RC2 para D7)

Parece requerir el Asistente de tabla (solo D6) para la integración de Vistas . Se agregó como referencia, pero no cumple con el requisito de Vistas.

@MPD: se agregaron "Tablas personalizadas" como una posible solución y módulos ampliados. Gracias por esta adición

Mi instinto me dice que este plan hará que sus servidores se incendien ...

En serio, si está produciendo esa cantidad de datos, creo que necesita mantener los datos en una fuente de datos externa y luego integrarlos con Drupal.

Mi pensamiento inicial sería utilizar dos bases de datos para los datos externos, de modo que pueda realizar la importación semanal sin demasiadas cosas perturbadoras. En otras palabras, ponga en funcionamiento la base de datos A y luego importe a B. Cuando termine la importación, haga de B la fuente en vivo. Luego limpie e importe en A.

He hecho mucha integración de fuentes de datos externas en Drupal, y realmente no es tan difícil. Di una visión general en el plan de transición para la abominación PHP5 a Drupal . Eso fue para Drupal 6, pero lo mismo se aplica básicamente a Drupal 7. Esencialmente, simulas lo que hace CCK / Fields API con tu propia interfaz.

Sin embargo, no tener un UUID para la base de datos semanal realmente pone una llave en marcha. Sin embargo, esa parte requiere mucho, más que se puede proporcionar en un foro de preguntas y respuestas como este.

Si realmente quiere ir por la ruta de importación, pagaría Feeds and Migrate y escribiría su propio script de importación. Básicamente, realiza el proceso inicial de la librería desde index.php, consulta su fuente de datos, crea sus nodos y luego los guarda. Hacer nodos mediante programación es fácil.

La mejor manera de comenzar con esto es crear un nodo con la interfaz de usuario, luego imprimirlo y replicar el objeto con código en su script de importación. La taxonomía, los archivos y los noderefs son partes difíciles, pero solo necesita familiarizarse con estas partes de la API para construir estas propiedades de objeto. Una vez que tenga un objeto de nodo válido, puede hacer un node_save (). Asegúrese de establecer un límite muy grande con set_time_limit () para que se ejecute su script.

EDITAR ABAJO A LA CLARIFICACIÓN / EXPANSIÓN DE DIRECCIONES:

Personalmente, dejamos de usar los enfoques basados ​​en el módulo contrib para importar datos hace un tiempo. Funcionan principalmente bien, pero terminamos pasando demasiado tiempo luchando contra ellos y decidimos que el costo / beneficio era demasiado bajo.

Si realmente necesita los datos en Drupal propiamente dicho, mi opinión sobre un script de importación personalizado no ha cambiado. Uno de los módulos a los que hace referencia podría usarse como punto de partida sobre cómo construir los objetos del nodo, luego simplemente recorrer sus nodos de compilación de datos y guardarlos. Si tiene una PK, puede agregar fácilmente la lógica para buscar en la base de datos y node_load (), modificar y guardar. Un script de importación es realmente solo unas pocas horas de trabajo si conoce la API de Drupal.

Si la integración de vistas es una clave (y parece que se basa en la edición) y desea realizar el enfoque de tablas externas, entonces su mejor opción es hacer un módulo personalizado e implementar hook_views_data para obtener sus datos en vistas. Lo más probable es que de todas formas personalizará el módulo para admitir su fuente de datos, por lo que agregar este gancho no debería ser mucho más trabajo. Los módulos TW y Data deberían tener algún ejemplo para que pueda comenzar.

Sin embargo, personalmente, nunca he encontrado que la integración de las vistas con datos externos sea realmente valiosa. En los casos en que lo he considerado, los datos eran demasiado "diferentes" para funcionar bien con un enfoque basado en puntos de vista. Acabo de usar el método que describí en el enlace de "abominación" anterior.

Creo que un enfoque basado en nodos (o incluso basado en entidades) quemará su servidor con millones de nodos. Además, al mirar su importación por hora, eso significa que hará un node_save () al menos una vez por segundo. Eso es demasiado para Drupal y causa un problema de rendimiento.

La razón detrás de eso es por ese contenido, no necesitará ningún mecanismo de enlace, no necesitará pathauto (pero puede crear manualmente un alias, es mucho más barato que pathauto), no necesitará campos ... Escriba un La consulta simple "INSERTAR" es 100 veces más rápida que node_save () o entity_save ().

1 / En mi humilde opinión, la mejor opción es una tabla personalizada y un módulo personalizado para la importación de datos, luego escriba controladores de vistas para la integración de Drupal.

2 / La memoria caché de la base de datos se invalida durante la importación por hora. Si lleva demasiado tiempo, puede pensar en una replicación. En la forma más fácil, cree dos tablas idénticas, use la primera, importe a la segunda, cambie su configuración de Drupal para usar la segunda tabla, sincronice la segunda tabla con la primera (luego, opcionalmente, vuelva a la primera). Otra solución está en su script de importación personalizado, prepare y agrupe las consultas INSERT / UPDATE, luego solo envíelas al final en una transacción para reducir el tiempo de escritura de la base de datos.