Recentemente, testamos a abordagem que chamamos de QDM ao trabalhar com grandes quantidades de dados - centenas de gigabytes. Como parte da tarefa, processamos 12 a 24 milhões de registros e comparamos o desempenho da solução de quinteto com funcionalidades semelhantes em tabelas comuns.
Não fizemos novas descobertas, mas confirmamos as hipóteses que expressamos anteriormente: quanto o designer universal nas mãos do “bule” condicional perde para um banco de dados configurado profissionalmente.
Agora também sabemos o que fazer em tal situação - a solução é bastante simples e confiável e temos experiência na organização de uma solução de compromisso para dados arbitrariamente grandes.
Durante o desenvolvimento do sistema de reconciliação de relatórios, precisamos fazer o download dos dados de um dos formulários de relatório, que contêm até 24 milhões de registros em cada data do relatório. Deve haver dados para 7 anos de cálculos diários. Volumes, francamente, não para um projetista universal, mas para um sistema altamente especializado, mas já nos envolvemos nesse empreendimento e tivemos que procurar uma solução.
Os usuários trabalham com esse grande conjunto de dados apenas em uma data de relatório, portanto, no sistema de referência, tudo isso é armazenado em uma tabela particionada nessa data. Os índices para os 26 campos de dados restantes não são usados para este formulário.
A primeira coisa que fizemos, é claro, foi criar a estrutura de dados desejada no construtor e carregar várias datas lá. O download de uma das menores datas leva cerca de 14 horas, o que é inaceitavelmente longo: 12,5 milhões de registros com 27 atributos, colocados em meio bilhão de registros de 5 campos com a construção de três índices, dois dos quais são compostos.
A quantidade total desses dados no disco é ligeiramente superior a 18 GB.
Vale ressaltar duas características deste formulário:
- Quase não se presta à normalização, ao contrário, por exemplo, do Formulário 110, discutido em uma publicação anterior
- Ele não usa índices em atributos de registro - é mais lucrativo para o usuário esperar um minuto do que gastar dinheiro em índices
Este pode ser o caso mais radical que você pode escolher para comparação. Na maioria dos casos, a diferença no volume de dados QDM e no banco de dados usual não é tão dramática ou mesmo pequena .
Para comparação, os mesmos dados carregados em uma tabela regular em um banco de dados relacional levam 2,3 GB (8 vezes menos) junto com o índice por data, e seu carregamento dura menos de meia hora (28 vezes mais rápido). Nos dois casos, os dados foram inseridos diretamente do arquivo em porções de 100 mil registros, sem desativar os índices.
Tendo em vista que não é prático usar um construtor para esses volumes de dados, fizemos testes de desempenho: em casos diferentes, comparamos o processamento em massa de registros com o construtor e nossa tabela não indexada. Precisávamos determinar o limite da quantidade de dados para os quais usaremos uma tabela regular a partir de agora e não nosso construtor.
Como esperávamos, trabalhar com pequenos conjuntos de dados, por exemplo, em uma conta ou cliente separado, no designer parece bastante confortável (tempo de resposta em um segundo), em contraste com uma tabela sem índices, na qual é necessário aguardar alguns minutos para responder. Ao mesmo tempo, a principal tarefa do aplicativo - amostragem em massa e agregação de dados em várias seções - pode demorar várias vezes mais no designer.
Abaixo estão os resultados resumidos das amostras que criamos para um volume cada vez maior de dados agregados:
Onde foi possível, fizemos várias medições, após selecionar as estatísticas e selecionar o número de registros pela máscara de número da conta.
A tabela e o gráfico abaixo mostram que a agregação de um conjunto completo de dados em um dia leva muito menos tempo do que a amostragem de mais de 5% dos dados usando o índice. É por isso que os otimizadores de consulta RDBMS ignoram o índice em tal situação, enquanto o mecanismo de nosso serviço no momento é privado dessa oportunidade.
Exibição gráfica dos mesmos resultados usando uma escala logarítmica para comparar números de ordens diferentes:
A velocidade do designer ao processar um conjunto de dados completo é quase uma ordem de magnitude menor que a de uma tabela regular, o que é bastante normal para o designer - é importante evitar uma degradação do desempenho, como uma avalanche, e esse objetivo foi alcançado.
O estudo mostrou que o número de registros no banco de dados praticamente não afeta a velocidade de criação de páginas, navegação e pequenas amostras em um modelo de dados de quinteto. Com a quantidade de dados processados até 10.000 registros (e essa é a seleção máxima de dados relacionados para uma instância de qualquer entidade comercial no sistema de informações), você pode trabalhar confortavelmente com um banco de dados de centenas de gigabytes ou mais.
Em seguida, ensinamos nosso plug-in de tabela (descrito aqui ) a chamar um conector para um banco de dados arbitrário para que ele funcione de forma transparente com o modelo de dados do quinteto e com as tabelas tradicionais.
Do ponto de vista do usuário, ele não se importa com qual fonte de dados ele trabalha, enquanto ele pode fazer o trabalho importante para ele na interface familiar, recebendo seus relatórios:
Agora, removeremos as tabelas enormes semelhantes restantes, que em nosso banco de dados são apenas duas dúzias em centenas, em um armazenamento separado para trabalhar com elas confortavelmente.
Portanto, podemos usar o construtor para tabelas pequenas e médias que exigem pesquisa e agregação intensivas por atributos arbitrários e armazenar objetos grandes não indexados em tabelas tradicionais planas, chamá-los de armazenamento de terceiros ou bancos de dados especializados (Hadoop e outro NoSQL).
O designer é mais adequado para sistemas de CRM e produtos similares, onde o usuário trabalha com um único cliente, conta ou outra entidade, e as funções analíticas são movidas para um armazenamento especializado separado.