Converter NDJSON para SQL

O mapeamento é exatamente tão direto quanto parece. Toda linha não vazia da origem produz um statement INSERT, então a saída tem tantos statements quanto a entrada tem registros, e wc -l num arquivo ou no outro dá o mesmo número. Não há cabeçalho a considerar e nada nos dados pode produzir uma quebra de linha.

Essa previsibilidade é o motivo de este par ser agradável de trabalhar. Se uma carga relata 412.000 linhas inseridas e o arquivo tinha 412.000 linhas, a carga foi completa — sem reconciliação, sem questão de linha parcial.

Este é o único lugar onde um formato de origem em streaming não compra uma conversão em streaming. A lista de colunas tem que ser idêntica em todo statement, e é construída da união das chaves em todas as linhas — então um campo que aparece só no último registro ainda vira uma coluna.

A consequência é um teto de memória em vez de um nível de tamanho: o arquivo inteiro existe na aba enquanto está sendo convertido. Dezenas de megabytes é tranquilo, várias centenas é onde um navegador começa a forçar, e além disso a resposta é dividir o arquivo.

Um fluxo de log que emite requisições, erros e conclusões de trabalho num arquivo só tem três conjuntos de chave diferentes nele. A reconciliação lida com isso sem descartar nada — toda chave vira uma coluna, e uma linha sem ela recebe NULL — e a tabela que você acaba declarando é a união dos três esquemas.

Para uma tarde de análise isso costuma ser aceitável. Para algo que vai viver mais tempo, filtrar o arquivo por tipo de evento e carregar três tabelas produz um esquema que dá para indexar sensatamente.

A saída não tem DDL nenhum, de propósito. JSON diz que um valor é um número e não diz se a coluna é inteiro ou numeric com duas casas decimais, se é anulável, qual é a chave primária ou quão longo o texto pode ser.

O ciclo prático é converter, ler a lista de colunas do primeiro statement, escrever a tabela para combinar, então rodar. Um aviso que importa mais aqui do que em arquivos menores: derive as colunas de uma conversão do arquivo inteiro, nunca de uma amostra.

Registros de log estruturados se aninham — um objeto de requisição com método e caminho, um bloco de contexto com um ID de rastreamento — e uma tabela relacional não. O caminho é dobrado no nome da coluna com sublinhados, então request.method vira request_method.

Um ou dois níveis produzem uma tabela que você ficaria feliz de declarar, o que cobre a maioria das bibliotecas de logging. Um registro carregando um payload serializado inteiro produz uma coluna por campo dentro dele.

Valores são escritos como literais SQL: números sem aspas, booleanos como TRUE e FALSE, nulos como NULL, e texto entre aspas simples com aspas simples internas dobradas. Dobrar é a forma portável e todo motor a lê.

Barras invertidas são escritas intactas, o que é correto sob o padrão SQL e não é como o MySQL lê uma string com suas configurações padrão, onde uma barra invertida inicia uma sequência de escape. Dados de log são incomumente cheios delas.

Os statements chegam um por linha sem transação ao redor. Rodar isso como está contra um banco de dados torna todo statement sua própria transação com seu próprio commit e sua própria viagem de ida e volta, o jeito mais lento possível de inserir meio milhão de linhas.

Duas edições mudam a aritmética. Envolver o arquivo em BEGIN e COMMIT é uma linha em cada ponta e costuma ser a melhoria única mais significativa disponível. Descartar os índices antes da carga e recriá-los depois é a segunda.

Existe um tamanho além do qual statements são o instrumento errado independentemente de como são agrupados. Todo motor tem um caminho de carga em massa — COPY no Postgres, LOAD DATA no MySQL — que lê um arquivo delimitado diretamente e pula a análise de statement por completo, e para um milhão de linhas a diferença é minutos contra horas.

Converter o mesmo NDJSON para CSV ou TSV e usar esse caminho é o plano melhor acima de aproximadamente cem mil linhas.

Se qualquer linha não é JSON válido, a conversão falha e a mensagem nomeia o número da linha. Nada parcial é produzido, o que é o comportamento que você quer aqui: um arquivo de statement parcial carregado numa tabela é consideravelmente pior que nenhum arquivo.

Uma linha malformada num log costuma significar uma escrita truncada em vez de um erro de digitação — um processo morto no meio de um flush, um arquivo rotacionado cortado numa fronteira. Saber qual linha significa que você pode aparar a cauda e carregar o resto deliberadamente.

Os statements são gerados por JavaScript nesta aba do navegador. O arquivo não é enviado, não há conta nem fila, e o plano gratuito aceita até 100 MB, com memória como a restrição prática pelo motivo descrito acima.

Essa propriedade faz trabalho real para este par. Logs de evento são um dos arquivos comuns mais sensíveis que um engenheiro lida — endereço IP, identificador de sessão, caminho de requisição, às vezes um token numa query string — e o motivo de converter um costuma ser um incidente.