IMPORTAR ARQUIVO TXT GRANDE
Autor Tópico: IMPORTAR ARQUIVO TXT GRANDE (Lida 6617 vezes)
jose_rsantos
« Online: Janeiro 29, 2016, 12:51:32 am »
Pessoal tem uma forma de importar mais rapido para o banco um arquivo txt cujo tamanho e 83 mb
if($arquivo == false)
echo "Arquivo não enviado.";
$file = fopen($_SESSION['scriptcase']['control']['glo_nm_path_doc'].'/'.{Arquivo}, 'r');
echo "Processando Leitura";
sc_exec_sql("DELETE FROM CRONO");
if(!empty($Linha))
$Conta = substr($Linha, 0,7);
$Nome = substr($Linha, 8,40);
$valor = substr($Linha, 118,15);
$pos =substr($Linha, 61,1);
if ($pos =='3')
sc_exec_sql("INSERT INTO CRONO (CONTA,ASSOCIADO,VALOR) VALUES ('$Conta','$Nome', '$valor')");
// echo $Nome;
importa mas demora uma eternidade mais de 30 minutos
Re:IMPORTAR ARQUIVO TXT GRANDE
« Responder #1 Online: Janeiro 29, 2016, 07:33:31 am »
83 mbs todo dia?
Você pode compactar o arquivo antes em .zip fazer o upload para uma pasta na hospedagem e usar o php na hospedagem
para descompactar e importar ele lá diretamente.
Ou se o seu servidor for VPS criar um script para fazer isso lá também acionado pelo php para importar direto pelo mysql.
« Responder #2 Online: Janeiro 29, 2016, 07:46:31 am »
INSERT para cada registro é assim mesmo, ao menos com o PostgreSQL.
Em particular uso o COPY em tabela temporária, e depois faz o processamento. E dependendo do caso é melhor fazer isto direto no BD.
marcusbelempa
« Responder #3 Online: Março 09, 2016, 08:22:42 pm »
Importação de arquivos txt, csv muito grandes no MySQL
« Responder #4 Online: Março 09, 2016, 10:55:28 pm »
Olha! Temo dizer isto e os trolls pegarem seus tacapes.
Mas, a dupla Mysql e seu Fork MariaDb são uma B0$tª para fazer insert de arquivos grandes.
E não estou dizendo isto para desmerecer o Mysql / MariaDB.
Uma vez tive que recuperar uma base em torno de 20Gb no meu servidor.
Script sql pronto para fazer um restore e popular a base nova.
Não importava o que fizesse levou mais de 4 horas para que carregasse os dados.
E sim! Há maneiras de dizer a essa B0$tª do Mysql ou MariaDB para dar prioridade aos inserts e updates no my.cnf ou my.ini.
Fiz isso e continuou a mesma B0$tª.
Isto ocorre principalmente nos tipos de tabelas INNODB e seu fork XTRADB.
Irá notar que tabelas MYISAM são mais rápidas para carregar.
Isto ocorre por causa da integridade referencial no INNODB / XTRADB.
Vide comparativo entre bancos onde no MySQL foi usado INNODB e MYISAM -> http://blog.hallanmedeiros.com/2013/02/19/benchmark-h2-firebird-postgresql-mysql/ onde cito:
"O MySQL, por exemplo, sempre é citado como "o mais rápido". Porém, como muitos sabem, o MySQL trabalha com "engines" (motores) diferentes. As duas mais utilizadas sao MYISAM e INNODB.
MYISAM realmente é rápida, porém nela não existe funções básicas como verificação de chave estrangeira.
INNOBD é mais robusta, mas o desempenho cai drasticamente se comparado a qualquer outro SGBD."
Por isto afirmo que o MySQL ou MariaDB são bons para ambientes onde selects são mais importantes que insert e updates.
Em ambientes de alta concorrência de insert e update estes dois (Mysql/MariaDB) abrem o bico.
E para os trolls que não concordam comigo procurem no tio google comparativo entre os bancos como estes aqui: http://www.firebase.com.br/imgdocs/tcc_fbmysql.pdf e http://blog.hallanmedeiros.com/2013/02/19/benchmark-h2-firebird-postgresql-mysql/
Cito uma das tabelas do estudo:
Notem que diferença fica gritante a medida que o arquivo ou quantidades de insert é maior.
É claro que seu cliente que tem 10 pc´s fazendo insert no dia a dia não vai fazer diferença.
Agora tenta colocar em produção com muitos insert´s concorrentes? Vai ficar no suporte respondendo porque o sistema está lento!!! E de noite tentando saber o que fez de errado procurando no Google alguma solução!!! Hahahaha
Voltando ao teor do post!
Já vi muitos relatos de que o uso de uma tabela temporária para este fim irá acelerar a carga do arquivo!
« Última modificação: Janeiro 26, 2018, 07:43:19 pm por Alexandre Pereira Bühler »
« Responder #5 Online: Março 10, 2016, 08:41:17 am »
Sim, eu confesso... eu uso muitas tabelas MyISAM na modelagem, as que não são muito críticas de terem muitos updates ao mesmo tempo por usuários diferentes, e FK e PK é luxo, kkkkk igual vc falou podem 'bater' kkkkk
« Última modificação: Março 10, 2016, 08:46:39 am por Jailton »
« Responder #6 Online: Março 10, 2016, 02:12:53 pm »
E isto ai Jailton.
Agora sabe porque MYISAM é rápido?
MyISAM é herdado do ISAM. Usado, por exemplo, pelo COBOL.
Mas não tem comparação a velocidade.
E que venham os trolls!
« Responder #7 Online: Março 10, 2016, 03:04:10 pm »
Citação de: Alexandre Pereira Bühler em Março 10, 2016, 02:12:53 pm
Sim esse assunto é tipo aquela palavra 'TABU'.
http://www.significados.com.br/tabu/
« Responder #8 Online: Agosto 12, 2016, 08:39:24 pm »
Reabrindo para uma consulta!
Ok Alexandre, mas pela sua experiência e sabendo que não é uma resposta simples e definitiva, qual seria a sua aposta na opção de banco que trabalha bem com o SC para atender projetos com algumas tabelas grandes?
« Responder #9 Online: Agosto 12, 2016, 11:17:14 pm »
Citação de: joni morais em Agosto 12, 2016, 08:39:24 pm
Segue o raking dos SGDB mais usados do mercado:
Se for usar bancos FREE com uma ótima hospedagem com SSD e memória ECC essa seria minha escolha:
1-MySQL/MariaDB Esse tem 100% de compatibilidade com o SC garantida.
2-PostgreSQL
3-Firebird
http://soluverti.com.br/noticia/evidencias-de-escalabilidade-com-firebird/
https://www.4linux.com.br/case/caixa-economica-federal-suportando-milhoes-de-transacoes-por-dia-com-o-banco-de-dados
Agora se tiver $$
2-MSSQL
3-DB2
Alternativas EXÓTICAS mais funcionam muito bem banco de DADOS que roda direto na RAM o HANA da SAP:
http://itforum365.com.br/34038/porque-o-hana-se-tornou-a-paixao-da-sap/
« Última modificação: Agosto 12, 2016, 11:22:10 pm por Jailton »
« Responder #10 Online: Agosto 13, 2016, 12:13:47 am »
Eu pensei muito na forma de responder esta pergunta.
O melhor SGDB para tabelas grandes e que trabalha bem com Scriptcase é: TODOS E NENHUM!
.TODOS os SGDB´s tem bases com 400GB ou mais rodando pelo mundo com performance.
Seja Firebird, a tripa sertaneja MySQL/MariaDB/Percona, Postgresql, Microsoft SQL Server, Oracle e etc.
Se não tivessem performance com bancos ou tabelas grandes estariam fora do mercado em instantes.
.E NENHUM deles está isento de bugs, má configuração, ausência de um DBA, hardware sofrível, sistema operacional mal configurado, bugs do scriptcase, select * from em tabelas grandes e etc.
Mas vou te dizer como achar o melhor SGDB para seu caso. E para isto vou de dar uma notícia boa e outra ruim.
Vamos a notícia boa primeiro.
Você faz parte dos 10% mais ricos.
Contrate um excelente DBA e um cara de TI que saiba os hacks do sistema operacional usado e que mantenha seu hardware voando.
Escolha uma linguagem de programação e faça suas POGS (traduzindo para os noobs -> programação orientada a gambiarras). Enfim seja feliz.
Os caras acima que se virem para fazer o sistema voar. E acredite eles farão! E de quebra irão dizer onde você está errando nas suas POGS.
Vamos a notícia ruim.
Você como eu faz parte dos 90% mais... pobressss!
1) Escolha um SGDB que você goste/use e pela primeira vez na vida leia o manual dele. E quando digo ler o manual quero dizer todo ele.
Acredite que fazer insert, update, delete, criar FK, UNIQUE, PK, campos e etc até meu filho de 9 anos fará se eu ensinar.
Mas saber os recursos que o SGDB oferece, em qual situação determinado tipo de campo deve ser usado. Quais as variáveis nos arquivos de configuração devem ser mexidas. Que tipo de engine devo usar. O segredos da entrelinha do manual e etc. Bem, são poucas as pessoas que tem este conhecimento.
Olhe que muitos nem sabem a diferença entre a dupla char/varchar e quando usar um ou outro conforme o SGDB.
Ou mesmo qual o melhor tipo de campo para valores monetários.
Que tipo de índice criar e onde usar.
Até mesmo otimizar ou normalizar o banco.
Tem curiosos que desconhecem o "explain" e para que serve.
Não ler o manual de uma ferramenta de trabalho e como jogar futebol com uma bola feita de meias velhas.
Você joga, se diverte, faz gol, corre o campo todo atrás da bola, ri com os amigos, volta satisfeito para casa no final da partida. Mas ainda assim jogou com uma bola feita de meias velhas.
2) Leia o manual da linguagem de programação que você vai usar. Sim! Leia todo também.
Vou dizer exemplos pequenos:
Você usa pascal é acha que a diferença entre read e readln é quem um lê o que foi digitado e vai para linha de baixo e o outro permanece na mesma linha.
Usa PHP e acha que os comparadores == e === são mesma coisa com os mesmos resultados.
Crê que echo e print no php fazem o mesmo e não tem diferença, mas como a maioria usa echo eu também uso.
Somente tenho a dizer vixe! Nem suas POGS irão de salvar!
O detalhe e que ninguém para nos exemplos pequenos não é? Todos gostamos de complicar.
É ai que começa os seus problemas. Usar o que todo mundo usa sem saber o porque é a receita do grande desastre.
Pode levar anos. Mas ele acontecerá.
3) Aprenda o máximo do sistema operacional que você usa para instalar o SGDB.
E não estou falando de abrir word, navegador ou fazer uma planilha, instalar o SGDB com next, next e next.
Estou falando que um dia sua tripa sertaneja MySQL,MariaDB,Percona vai precisar que você configure o SGDB para poder abrir mais arquivos que o padrão porque seu bancos e tabelas cresceram junto com sua clientela.
Tudo bem né? Ai você vai e coloca no my.cnf ou my.ini open_files_limit = 256000
Tá resolvido né?
Mas esquece, por exemplo, que o GNU/Linux ou Windows costuma ter por padrão abrir uns... chutando 65535 arquivos. Este valor não costuma ser fixo no GNU/Linux mas é baixo. E ai?
CRASHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHh.
Onde você vai aumentar este limite no GNU/Linux, Windows...?
4) Invista em Hardware.
Não adianta investir R$ 15.000,00 em um servidor e ele ser uma droga.
Por exemplo: Aprenda que uma controladora de disco com cache via software e uma com cache real podem ser a diferença entre um SGDB lerdo e um que seja um avião.
E acredite tem muita empresa que compra servidores de R$ 15000,00 com controladora via software e vem perguntar: Não entendo comprei o melhor, porque a lentidão?
5) Seja mesquinho. Ajude no óbvio. Somente o que é fácil achar no tio Google. Mas guarde o que você leu nos manuais e em suas pesquisas para cobrar como consultoria.
Acredite que em 100 programadores pelo menos 99 não lê, não pesquisa, não te ajudará quando você precisar naquele problema complexo e está doido para pagar sua consultoria.
Porque somente sabem usar select, insert, update e echo "hello word". Não querem perder tempo investindo na capacitação como você fez.
6) Depois disto poderá escolher qualquer SGDB. Todos irão trabalhar bem com bases grandes.
E de quebra poderá usar o Scriptcase pois você saberá as limitações dele, o que cobrar da netmake e quais POGS fazer em php puro para que tudo funcione bem.
Não se preocupe em decorar o manual. Seu cérebro quando precisar irá indicar que existe a solução e onde encontrar. Algo do tipo: já vi isto em algum lugar e acho que é aqui.
Eu pessoalmente acho que o Scriptcase tem mais familiaridade com a tripa sertaneja, mas ele é um framework que possui abstração a dados então tem que ser bom com qualquer SGDB.
O detalhe é que nunca usei a tripa sertaneja nos meus projetos pessoais. Somente quando o cliente exige. Eu prefiro Firebird e Postresql.
« Última modificação: Agosto 13, 2016, 07:47:39 am por Alexandre Pereira Bühler »
« Responder #11 Online: Agosto 13, 2016, 09:14:42 am »
Perfeita explicação, Alexandre!!! Muito boa mesmo!!!
« Responder #12 Online: Agosto 13, 2016, 01:51:31 pm »
E isso ai Alexandre parabéns perfeita analise, ficou tão perfeita que parece uma monografia.
« Última modificação: Agosto 13, 2016, 01:55:32 pm por Jailton »
« Responder #13 Online: Agosto 13, 2016, 08:20:32 pm »
Muito obrigado Jailton e Alexandre. Bem esclarecedor mesmo. Na verdade o que procurei com essa pergunta era justamente isso: tentar identificar o SGBD que o pessoal tem usado, de forma "genérica", com o SC. Realmente, Alexandre, SGBD é algo bem mais complexo. Venho trabalhando num projeto que acredito se tornar bem grande e tenho usado o SC para desenhar a ideia. E nesse tempo o SC me surpreendeu (positivamente). Claro, contornando um bug aqui uma funcionalidade não tão bem implementada pela NM ali, e vamos seguindo. É uma pena que me enquadro nos 90%, senão, contrataria pessoas como vocês, Alexandre e Jailton, para ver esse projeto decolar. Realmente não dá para fazer tudo! No momento só o que posso é tentar achar pessoas que estejam dispostas a comprar a ideia e seguir juntos e ver no que dá. De qualquer modo mais uma vez obrigado.
« Última modificação: Agosto 13, 2016, 08:24:12 pm por joni morais »
« Responder #14 Online: Abril 20, 2018, 07:37:05 am »
O grande problema das importações linha a linha independente do banco são os commits dados a cada linha, isso implica na atualização de indice a cada novo insert, uma forma de melhorar a performance é dar commit a cada X registros, eu coloco por exemplo a cada 500 ou 1000 dependendo da quantidade de registros e memoria do servidor, pois manter uma transação com muitos inserts poder ocupar muita memoria, não vou considerar a qui a linguagem a ser usada pois isso independe, então vou colocar um exemplo em "portugol"
Inicia transação
abre arquivo texto
começa leitura
insere registro
se contador >= 500
comita transação
Inicia transação novamente
se contador > 0
comita transacao
Por padrão o Postgres e MySQL o AutoCommit fica habilitado dependendo da linguagem usada, por exemplo o PHP