Carregando Big Data? Para mais velocidade, pré-classificação e carregamento em massa
Encontrar mais velocidade ao carregar big data é um desafio no índice ETL, reorg e banco de dados muito grande (VLDB) povoar as operações. Uma maneira de carregar big data mais rapidamente é pré-classificando-o, para que o banco de dados não precise classificar. A IBM e outros provedores de banco de dados de mainframe dão esse conselho há décadas, e ainda é verdade em bancos de dados relacionais em uso no Unix e em outros “sistemas abertos” hoje, incluindo Oracle, DB2, Sybase e SQL Server. Os benchmarks nesta área mostram melhorias em cargas não classificadas dependendo do volume, mas fornecedores de classificação como a IRI afirmam que o desempenho da carga melhorou entre duas e dez vezes. No relatório da TUSC Consulting “Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle”, apenas um teste de inserção de índice único de 100.000 linhas mostrou que os dados pré-ordenados foram carregados 58% mais rápido e exigiu 49% menos espaço:
- O carregamento em ordem classificada teve uma taxa de carregamento contínuo de linhas/segundos 42% menor
- Inserções não classificadas em índices forçam mais trabalho interno do banco de dados (gerenciamento de blocos e reorganização de espaço) a ser feito
- Em índices classificados por carga, o fator de agrupamento será próximo ao número de blocos folha
- A ordem dos dados carregados é fundamental para o desempenho do carregamento.
Muitos anos depois, no capítulo 13 de seu guia “Expert Oracle Database 11g Administration”, Sam R. Alapati (Miro Consulting) recomendou a pré-classificação em conjunto com cargas de caminho direto como a maneira mais rápida de carregar Oracle em massa (versus inserts):
“O carregamento de caminho direto opção não usa a instrução SQL INSERT para colocar dados em tabelas; em vez disso, ele formata blocos de dados Oracle e os grava diretamente nos arquivos do banco de dados. Esse processo de gravação direta elimina grande parte da sobrecarga envolvida na execução de instruções SQL para carregar tabelas. Como o método de carregamento de caminho direto não disputa recursos de banco de dados, ele carregará dados muito mais rápido do que um carregamento de dados convencional. Para cargas de dados maiores, o método de carregamento de caminho direto é melhor, e pode ser o único método viável de carregar dados em tabelas pelo simples motivo de que um carregamento convencional pode exigir mais tempo do que o disponível.”
Para os administradores de VLDBs de hoje, é aí que entra o CoSort, pois:
“Além das vantagens óbvias de um tempo de carregamento mais curto, o carregamento direto também ajuda a reconstruir índices e pré-classificar dados da tabela.”
CoSort é tradicionalmente usado na pré-classificação externa de um arquivo simples que será a importação para uma carga especificando “direct=true” e esta opção:
“SORTED INDEXES:O parâmetro SORTED_INDEXES sinaliza ao SQL*Loader que os dados são classificados em um índice especificado, o que melhora o desempenho do carregamento.”
Da mesma forma, a documentação do Microsoft SQL Server especifica a pré-classificação do arquivo como um dos “Métodos para otimizar a importação em massa”:
Por padrão, uma operação de importação em massa pressupõe que um arquivo de dados não seja ordenado. Se a tabela tiver um índice clusterizado, o bcp utilitário, instrução BULK INSERT e função OPENROWSET(BULK…) (Transact-SQL) permitem especificar como os dados no arquivo de dados são classificados durante uma operação de importação em massa. É opcional que os dados no arquivo de dados sejam classificados na mesma ordem da tabela. No entanto, você pode melhorar o desempenho da operação de importação em massa se especificar a mesma ordem para o arquivo de dados que a tabela.
O campo /KEY em um script CoSort SortCL normalmente seria a chave de índice (primária) mais longa na tabela, mas não precisa ser. De acordo com a TUSC, para colunas semelhantes:
- Menos índices mais longos são preferíveis a índices mais curtos
- A coluna principal impulsiona o custo de carregamento do índice
Observe também que:
- Por Vertica e outros primers RDBMS, manter colunas em ordens classificadas otimiza o desempenho da consulta. Até mesmo o velho conselho do DEC's Rdb/VMS Guide to Database Maintenance and Performance ainda é verdadeiro:
“Pré-classifique os registros que você planeja armazenar em uma tabela por valor de chave primária antes de carregá-los no banco de dados. Quando os registros são carregados, eles estarão fisicamente adjacentes uns aos outros, ou agrupados, até que registros adicionais sejam armazenados no banco de dados. Manter esse arranjo beneficia as consultas que selecionam linhas com base em um intervalo de valores ou que unem muitas linhas de uma tabela com linhas na mesma tabela.”
- A pré-classificação de dados em tabelas também pode economizar tempo nas visualizações. De acordo com “Oracle Database 10g:The Complete Reference” de Kevin Loney:
“Ter os dados classificados na visualização pode simplificar o desenvolvimento de seu aplicativo. Por exemplo, se o seu código passar por um conjunto de registros, ter esses registros pré-classificados pode simplificar o processamento e a verificação de erros. No desenvolvimento do seu aplicativo, você saberá que os dados sempre serão devolvidos a você de forma ordenada.”
- Sr. Alapati avisa os DBAs sobre uma limitação de cargas de caminho direto:
“Nota:Em uma carga direta, você não pode usar nenhuma função SQL. Se você precisar realizar uma grande carga de dados e também transformar os dados durante o carregamento, você tem um problema. O carregamento de dados convencional permitirá que você use funções SQL para transformar dados, mas o método é muito lento em comparação com o carregamento direto. Assim, para grandes cargas de dados, você pode considerar o uso de uma das técnicas de carregamento/transformação mais recentes, como tabelas externas ou funções de tabela.”
No entanto, o programa SortCL do CoSort pode transformar os dados de carregamento durante a pré-classificação; ou seja, combinando o mesmo tipo de funções SQL no mesmo script de trabalho e passagem de E/S, incluindo:junções, agregações, cálculos cruzados, pesquisas, selecionar/filtrar, funções de substring e instring e muitos destinos de reformatação e relatórios personalizados — nessa mesma operação de pré-classificação.
- O novo utilitário de reorganização offline no IRI Workbench (Eclipse GUI) usa IRI FACT (Fast Extract) para descarregar dados de tabela rapidamente via OCI, usa CoSort para pré-classificar na chave primária e grava e executa SQL*Loader diretamente cargas de caminho para otimizar e combinar cada uma dessas etapas.
