Importando grandes fontes de dados de arquivo simples com a integração do Drupal 7 com Views 3

Meu objetivo é produzir um método rápido, confiável e automatizado para acessar dados somente leitura contidos em várias fontes de dados de arquivos simples muito grandes ( CSVs , documentos de largura fixa e XML) usando o Drupal 7 que pode ser consultado usando as Exibições 3 módulo. Eu preferiria usar módulos já disponíveis, mas criar um módulo personalizado também é uma opção.

Para ajudar a descartar módulos e métodos não adequados para a tarefa, aqui estão as estatísticas dos arquivos com os quais estou trabalhando:

• Importação anual: arquivo CSV de 8.500.000 linhas . (Eliminado e recarregado anualmente. Possui chave primária.)
• Importação semanal: arquivo de largura fixa de 350.000 linhas. (Limpado e recarregado semanalmente. Nenhuma chave primária .)
• Importação por hora: arquivo CSV de 3.400 linhas . (Gostaria de atualizar e sincronizar o mais rápido possível, mas não mais que a cada 20 minutos. Possui chave primária)
• Importação diária: arquivo XML de 200 itens. (Eliminado e recarregado diariamente. Possui chave primária)

A conversão entre os três formatos não é um problema e pode ser feita se melhorar o desempenho da importação ou permitir que melhores ferramentas sejam disponibilizadas. ( AWK para largura fixa para CSV etc.) A automação de recuperação e conversão é fácil por meio de scripts cron e sh , mas ainda precisa automatizar a integração do Drupal 7. O uso de tabelas personalizadas também é possível desde que os vews possam fazer referência aos dados usando relacionamentos.

Qual seria a melhor prática para realizar esse tipo de integração de dados com o Drupal 7? Além disso, estou deixando de fora alguns detalhes importantes sobre os dados ou o que estou tentando realizar?

Aqui estão alguns projetos que estou procurando atualmente para encontrar uma solução. Gostaria de expandir isso para ajudar outras pessoas a decidir qual caminho seguir ao trabalhar com importações de dados maiores.

Importando dados para nós:

• Feeds (atualmente Alpha para D7)

Os feeds importam os dados de maneira confiável. A velocidade é razoável para as fontes de dados menores, mas é muito lenta para as tabelas de mais de 300k.

Automação disponível usando cron e Job Scheduler (atualmente Alpha para D7).

• Migrar

Não ter um índice ou chave exclusiva disponível nos dados de origem está dificultando o uso. É mais rápido que os feeds, mas ainda é lento para importar tabelas muito grandes.

A automação está disponível via drush e cron.

Tabelas personalizadas em vez de nós

• Módulo de dados (atualmente Alpha para D7)

O módulo Data parece muito promissor, mas é muito problemático para o D7 no momento. Os requisitos de velocidade de automação e importação seriam facilmente atendidos usando dados, mas falta confiabilidade. A integração de visualizações (link para D6) parece muito promissora.

• Assistente de tabela (não disponível para D7)

Adicionado isso para referência. Não há candidato a D7 neste momento, mas poderia servir como ponto de partida para um módulo personalizado.

• Esquema de exibições (abandonado, apenas D6)

Adicionado isso para referência. Isso parece ter sido absorvido pelo Table Wizard no Drupal 6. Novamente, adicionado apenas para referência.

• Importador (RC2 para D7)

Parece exigir o Assistente de Tabela (somente D6) para a integração do Views . Adicionado para referência, mas não atende ao requisito de Visualizações.

@MPD - Adicionadas "tabelas personalizadas" como uma possível solução e módulos expandidos. Obrigado por esta adição.

Meu intestino me diz que esse plano fará seus servidores pegarem fogo ...

Sério, se você está produzindo tantos dados, acho que precisa manter os dados em uma fonte de dados externa e depois integrá-los ao Drupal.

Meu pensamento inicial seria usar dois bancos de dados para os dados externos, para que você possa fazer a importação semanal sem atrapalhar muito as coisas. Em outras palavras, instale o banco de dados A em funcionamento e importe-o para B. Quando a importação estiver concluída, torne B a fonte ativa. Em seguida, limpe e importe para A.

Fiz muita integração de fontes de dados externas no Drupal, e isso realmente não é tão difícil. Dei uma visão geral no plano de transição para abominação do PHP5 para o Drupal . Isso foi para o Drupal 6, mas a mesma coisa se aplica basicamente ao Drupal 7. Essencialmente, você simula o que a API CCK / Fields faz com sua própria interface.

Porém, não ter um UUID para o banco de dados semanal realmente gera uma chave de fendas nos trabalhos. Essa parte requer muito, porém, mais do que isso pode ser fornecido em um fórum de perguntas e respostas como este.

Se você realmente deseja seguir a rota de importação, eu daria um soco no Feeds e Migrar e escrevia seu próprio script de importação. Basicamente, você faz o processo inicial de bookstrap em index.php, consulta sua fonte de dados, cria seus nós e os salva. Criar nós de forma programática é fácil.

A melhor maneira de começar com isso é criar um nó com a interface do usuário, imprimi-lo e replicar o objeto com o código em seu script de importação. Taxonomia, arquivos e noderefs são partes difíceis, mas você só precisa se familiarizar com essas partes da API para criar essas propriedades do objeto. Depois de ter um objeto de nó válido, você pode simplesmente fazer um node_save (). Certifique-se de definir um limite muito grande com set_time_limit () para que seu script seja executado.

EDITE ABAIXO PARA ENDEREÇAR À CLARIFICAÇÃO / EXPANSÃO:

Pessoalmente, paramos de usar as abordagens baseadas no módulo contrib para importação de dados há um tempo atrás. Eles funcionam muito bem, mas acabamos gastando muito tempo lutando com eles e decidimos que o custo / benefício era muito baixo.

Se você realmente precisa dos dados no Drupal, então minha opinião sobre um script de importação personalizado não mudou. Um dos módulos aos quais você se refere pode ser usado como ponto de partida para como construir os objetos do nó, basta percorrer os nós da construção de dados e salvá-los. Se você tiver uma PK, poderá adicionar facilmente lógica para pesquisar no banco de dados e node_load (), modificar e salvar. Um script de importação é realmente apenas algumas horas de trabalho, se você conhece a API Drupal.

Se a integração de visualizações é uma chave (e parece que é baseada na edição) e você deseja fazer a abordagem de tabelas externas, sua melhor opção é fazer um módulo personalizado e implementar hook_views_data para obter seus dados em visualizações. Muito provavelmente, você personalizará o módulo de qualquer maneira para dar suporte à sua fonte de dados; portanto, adicionar esse gancho não deve ser muito mais trabalhoso. Os módulos TW e Data devem ter algum exemplo para você continuar.

Pessoalmente, nunca achei que a integração de visualizações com dados externos valesse a pena. Nos casos em que eu considerei, os dados eram "diferentes" demais para funcionar bem com uma abordagem baseada em visualizações. Acabei usando o método que descrevi no link "abominação" acima.

Eu acho que uma abordagem baseada em nó (ou mesmo baseada em entidade) queimará seu servidor com milhões de nós. Além disso, observando sua importação horária, isso significa que você criará um node_save () pelo menos uma vez por segundo. Isso é demais para o Drupal e causa um problema de desempenho.

A razão por trás disso é para esse conteúdo, você não precisará de nenhum mecanismo de gancho, não precisará de pathauto (mas você pode criar alias manualmente, é muito mais barato que pathauto), não precisará de campos ... uma consulta simples "INSERT" é 100x mais rápida que node_save () ou entity_save ().

1 / IMHO, a melhor opção é uma tabela personalizada e um módulo personalizado para sua importação de dados e, em seguida, escreva manipuladores de Views para integração com o Drupal.

2 / O cache do banco de dados é invalidado durante a importação horária. Se demorar muito, você pode pensar em uma replicação. Na forma mais fácil, crie duas tabelas idênticas, use a primeira, importe para a segunda, alterne sua configuração do Drupal para usar a segunda tabela, sincronize a 2ª tabela com a 1ª (opcionalmente, volte para a primeira). Outra solução está no seu script de importação personalizado, prepare e agrupe as consultas INSERT / UPDATE e envie-a apenas no final de uma transação para reduzir o tempo de gravação do banco de dados.