Os sistemas contábeis corporativos são caracterizados por um aumento gradual no volume de bancos de dados devido ao acúmulo de informações históricas. Com o tempo, o tamanho do banco de dados pode atingir tais dimensões que provoca vários problemas com desempenho, manutenção, espaço em disco disponível e muito mais. Hoje, consideramos duas abordagens para solucionar esse problema: aumentar os recursos de hardware e dobrar dados históricos.
1. Introdução
Este artigo discute o problema de dobrar bancos de dados especialmente grandes na plataforma MS SQL Server. A solução para esse problema é descrita usando a tecnologia de replicação DBREPLICATION da Softpoint.
Edição
Cada tipo de sistema contábil pode começar a manifestar suas próprias características específicas. Por exemplo, em sistemas baseados na plataforma 1C, surgem problemas com operações de rotina como atualização da configuração, atualização da plataforma 1C. À medida que o banco de dados cresce, a situação piora gradualmente; mais cedo ou mais tarde, são necessárias medidas.
Abordagem nº 1: hardware
A solução mais óbvia e tecnicamente transparente é aumentar os recursos de hardware. Pode ser a compra de servidores mais produtivos, armazenamento em disco etc., ou o aluguel de equipamentos mais poderosos em um data center ou nuvem de terceiros.
Se você seguir esse caminho, uma boa opção é colocar o banco de dados na nuvem do Microsoft Azure. O Azure fornece várias opções de arquitetura para hospedar o banco de dados: MS SQL na máquina virtual do Azure e três opções para o Banco de Dados SQL do Azure na nuvem. Portanto, é possível escolher a opção de posicionamento ideal, dependendo das características de um banco de dados específico e de suas condições operacionais.
O Azure tem várias vantagens em comparação com a compra de seu próprio equipamento. Um dos principais são os enormes recursos de hardware que o Azure pode fornecer. Além de uma abordagem flexível para o uso dessas capacidades, dependendo da carga real. Por exemplo, você pode comprar capacidades adicionais durante o período da "alta temporada" da sua empresa ou no final do período do relatório, para que os picos possam passar sem problemas. E o resto do tempo, use uma configuração mais orçamentária de recursos. Assim, por um lado, no momento certo, você tem acesso ao enorme potencial de recursos do Azure (que, a propósito, está crescendo o tempo todo) e, por outro lado, não pode pagar a mais por excesso de capacidade quando não precisar deles.
No entanto, apesar de sua relativa simplicidade, aumentar os recursos de hardware não é uma solução universal. Em primeiro lugar, o efeito positivo costuma estar longe de ser proporcional aos investimentos financeiros (há muitos investimentos - há pouco efeito). Em segundo lugar, o efeito é temporário, pois a base continua a crescer e requer mais recursos, mais investimentos financeiros.
De qualquer forma, essa abordagem tem direito à vida e é amplamente usada. Mas não vamos mais insistir nisso, já que o principal objetivo do artigo não é uma abordagem de "hardware", mas uma abordagem de "software", descrita abaixo.
Abordagem nº 2: convolução da base
Uma solução mais radical é a convolução do banco de dados, ou seja, a remoção de dados históricos não relevantes dele. No banco de dados recolhido, existem apenas dados para um período operacional relativamente pequeno, geralmente não mais que um ou dois anos. Obviamente, o grau de redução em cada caso é diferente e é difícil nomear números específicos. E, no entanto, para uma diretriz, tomaremos um indicador de uma redução na base de 50 a 70%, ou seja, cerca de 2-3 vezes, aproximadamente a mesma quantidade com mais frequência e, na prática, acontece menos ou vice-versa mais - é raro.
Não vamos nos debruçar sobre os ganhos resultantes. Obviamente, se a base for reduzida em 2-3 ou mais vezes, o efeito no desempenho será muito poderoso e de longo prazo, e investimentos adicionais no componente de hardware poderão ser evitados. E o mecanismo de convolução, uma vez desenvolvido e rodado, pode ser reutilizado no futuro. Em geral, esta é uma ótima solução eficaz com resultados garantidos.
A complexidade da implementação da convolução
Mas, apesar de toda a sua eficácia, a convolução tem um grande problema. E nem se trata de desenvolver o próprio mecanismo de convolução. Sim, esse desenvolvimento também é uma tarefa difícil, mas de alguma forma está resolvida. A coisa é diferente. Quando o banco de dados tem um tamanho de várias centenas de gigabytes ou ultrapassa a linha de terabytes, verifica-se que é simplesmente fisicamente muito difícil executar a operação de dobragem. Inevitavelmente, surge todo um complexo de dificuldades interconectadas, vamos considerá-las.
- Intensidade de recursos das operações de dobragem - o equipamento está muito carregado.
- Durante a convolução, não apenas uma grande variedade de dados é excluída fisicamente, mas também são executadas muitas operações relacionadas a recursos intensivos: várias seleções, verificações, agrupamentos, indexação, registro, movimentação de dados entre tabelas e assim por diante. Esse fato é especialmente importante porque o banco de dados recolhível, como regra, já está muito carregado e não possui excesso de capacidade.
- Interferência para os usuários.
- É extremamente difícil ou impossível executar a convolução diretamente no banco de dados de trabalho em paralelo com o trabalho do usuário devido à alta carga adicional e bloqueios criados pelo processo de convolução.
- Não há janela tecnológica.
- Uma janela tecnológica de duração suficiente, quando os usuários não trabalham, simplesmente não está disponível para convolução. Afinal, o processo de dobragem para bancos de dados desse tamanho é geralmente dezenas de horas ou vários dias.
- Altos riscos ao dobrar diretamente na base de trabalho.
- A abordagem, quando o algoritmo de convolução é aplicado diretamente à base de trabalho, é altamente arriscada por várias razões. Um deles - as possibilidades de verificação final dos resultados da convolução são muito limitadas (sem tempo).
- Duração inaceitável de uma abordagem iterativa.
- Você pode tentar evitar um gargalo - uma janela tecnológica e executar iterações em partes iterativamente pequenas diretamente na base produtiva, selecionando o tamanho de cada parte para que ela se encaixe nas janelas tecnológicas existentes. Mas esse caminho também costuma não ser aplicável, porque, em primeiro lugar, o processo de corte se estende por um período inaceitavelmente longo (muitas semanas ou meses) e, em segundo lugar, a complexidade do mecanismo de dobra aumenta acentuadamente, o custo total para garantir um processo de corte ininterrupto por tanto tempo , os riscos do projeto como um todo estão aumentando radicalmente.
- Como comprimir vazios em um arquivo de dados!?
- Durante a remoção de informações históricas do banco de dados, seu arquivo de dados não diminui (e geralmente aumenta um pouco), simplesmente cria enormes vazios dentro dele. E você precisa de alguma forma se livrar deles para que o arquivo de dados seja reduzido. Caso contrário, o ganho será perdido em termos de espaço em disco. Uma opção é executar um SHRINK típico. E em tais volumes, é um procedimento muito demorado (muitas horas ou até dezenas de horas).
Assim, a convolução é uma tarefa muito não trivial. Não basta desenvolver um mecanismo de convolução, ele também precisa ser aplicado. Além disso, o aplicativo geralmente se torna um gargalo.
Nota: Em seguida, deixamos de lado os colchetes o desenvolvimento do próprio mecanismo de convolução (em outras palavras, o algoritmo para excluir dados históricos), independentemente do significado de sua criação. E nos concentramos apenas na aplicação do mecanismo já implementado em batalha.
Solução usando DBREPLICATION
Parece um beco sem saída. Mas ainda existem soluções. Existe uma técnica eficaz que permite desvendar todo o emaranhado de dificuldades, remover riscos e garantir a consecução do objetivo. Envolve o uso da tecnologia de troca de dados DBREPLICATION. A solução é adequada para a opção de infraestrutura tradicional e para o Microsoft Azure baseado em nuvem. Resumidamente, a essência é a seguinte.
- Um clone do banco de dados é criado, a troca de dados unidirecional entre o clone e o banco de dados principal é configurada usando DBREPLICATION. É permitido que o banco de dados principal e / ou seu clone estejam localizados (ambos ou um deles) na nuvem do Microsoft Azure.
- No clone, os usuários não funcionam, aí o processo de convolução começa. Como o processo de dobragem não incomoda ninguém, ele pode durar o dia inteiro sem interrupções pelo tempo que for necessário. Assim, o link para a duração da janela tecnológica desaparece!
- Usuários sem interferência trabalham no banco de dados principal. E a tecnologia DBREPLICATION transfere automaticamente todas as alterações do banco de dados principal para o dobrável em alta velocidade. Assim, o clone está atualizado em termos de dados operacionais.
- Após a conclusão da convolução, via de regra, é realizada uma verificação detalhada do resultado com o envolvimento de especialistas técnicos e usuários comerciais do Cliente. E esse processo pode durar bastante tempo (várias horas ou dias). Na metodologia em questão, praticamente não há limite de tempo, portanto, a verificação pode ser alocada o tempo necessário.
- Após a conclusão da convolução e verificação, todos os usuários passam para o clone recortado e, a partir desse momento, ele se torna a base principal. E a base não circuncidada original serve como um arquivo de dados históricos.
- Uma vantagem adicional é a capacidade de alternar a replicação na direção oposta quando os usuários alternam para um banco de dados minimizado. Isso fornece segurança adicional, porque se "algo der errado", você poderá rapidamente mudar os usuários de volta para o banco de dados não circuncidado sem perder os dados inseridos.
- Se houver necessidade de manter o banco de dados de arquivo atualizado, você poderá alternar a replicação na direção oposta e transferir as alterações do banco de dados minimizado para o arquivo.
Fig. 1. Diagrama esquemático do corte de banco de dados usando a tecnologia DBREPLICATION.
Fig. 2. Opção para hospedar bancos de dados recolhíveis na nuvem do MS Azure.
Assim, a técnica de convolução descrita no banco de dados clone expande todos os gargalos. Elimina a dependência da janela tecnológica. No clone, o pacote não incomoda ninguém e ninguém a incomoda. Você pode usar com segurança os recursos máximos do clone e também prestar atenção suficiente à verificação final.
Resta entender que tecnologia de troca pode ser usada nesse esquema? Por que DBReplication?
Por que DBReplication?
Na metodologia descrita, o elemento chave é a tecnologia de troca, que garante a sincronização do banco de dados aparado com o principal. Em princípio, a tecnologia de troca pode ser qualquer se satisfizer três condições essenciais:
- Compatibilidade com a plataforma de aplicativos de negócios, cuja base está em colapso.
Exemplo: se recolhermos o banco de dados 1C, nem toda tecnologia de troca é compatível com a estrutura base 1C, em particular, o clássico MS Transaction Replication não é compatível, pois faz alterações na estrutura da tabela.
- Performance. A tecnologia de troca deve ser garantida para lidar com o fluxo de alterações que ocorrem na base de trabalho durante a convolução.
Explicação: neste artigo, queremos dizer principalmente bancos de dados altamente carregados com uma alta taxa de alteração de dados. A convolução durará dezenas de horas, talvez vários dias, talvez até haja mais de uma iteração da convolução. Durante esse período, os usuários farão grandes alterações. Muitas tecnologias de compartilhamento simplesmente não conseguem lidar com isso. E você não precisa apenas lidar, é aconselhável lidar com o suprimento.
- A principal aplicabilidade às condições do problema.
Explicação: talvez esse ponto pareça óbvio, mas, no entanto, podemos destacá-lo. A saber: não esqueça que os dados no banco de dados de origem e no clone não são iguais entre si! Esse fato varre automaticamente toda uma classe de tecnologias poderosas e produtivas baseadas na sincronização de logs de transações - sempre ativada, envio de logs, espelhamento etc.
Além disso, a tecnologia de troca deve ser eficaz em termos de outros indicadores:
- Confiabilidade e autonomia de funcionamento. Como estamos falando da transferência de grandes quantidades de dados, e por um longo período de tempo, a equipe do projeto simplesmente não terá a capacidade física de lidar manualmente com problemas de troca, colisões e falhas, controle de qualidade dos dados etc. Portanto, a tecnologia de troca deve ser o mais confiável possível em termos de qualidade dos dados transmitidos, o mais autônoma e automatizada possível.
- Interfaces de qualidade para controle e gerenciamento.
- Fácil de implantar e configurar. A tecnologia de intercâmbio não deve impor requisitos excessivamente altos às qualificações de especialistas para seu ajuste.
Sem essas qualidades, a tecnologia de troca ameaça passar de um elemento-chave da metodologia para seu "elo fraco", apresenta sérios riscos e ameaça todo o projeto. E então a idéia original perde seu significado.
No entanto, a tecnologia de duplicação da DBR certamente satisfaz todos os requisitos e garante o sucesso do projeto de rollup.
Observe os principais fatores devido aos quais a duplicação de DBR é bem-sucedida nesta tarefa:
- Taxa de câmbio muito alta. Observe alguns recursos que fornecem velocidade:
- DBReplication é uma replicação transacional, cada alteração começa a ser transmitida imediatamente após a transação ser confirmada;
- A arquitetura interna do subsistema de transporte usa soluções como processamento paralelo de filas multiencadeadas, uma abordagem em pipeline, compactação de fluxo, processamento de transações em lote, o uso de Inserção em Massa e outros.
- Transporte implementado com base nos serviços do Windows, equipado com muitos recursos para garantir uma operação suave. Isso inclui: recuperação automática de trocas após interrupções de comunicação, trabalho em canais de comunicação instáveis fracos, processamento automático de conflitos de versão (para troca bidirecional), adaptação automática em caso de alterações na estrutura de tabelas de um aplicativo de negócios e outros.
- Mecanismo de entrega de dados garantido. Adesão estrita à integridade transacional e consistência na transferência de alterações.
- Não modifica a estrutura da tabela do aplicativo de negócios. Portanto, em particular, ele pode ser usado com êxito ao dobrar bancos de dados 1C.
- Interface de usuário desenvolvida que permite gerenciar centralmente o sistema de troca "de uma janela", todas as informações de serviço são coletadas e exibidas online.
- Fácil de implantar e configurar.
- Adaptado para a plataforma 1C. O usuário não trabalha com tabelas, mas com objetos de metadados familiares 1C.
- Qualquer versão do MS SQL, a partir de 2005, do Standard ao Enterprise, implantados localmente e localizados na nuvem do MS Azure; do ponto de vista do Azure, são permitidas as opções de hospedagem de máquina virtual e de hospedagem de banco de dados SQL do Azure, incluindo uma instância gerenciada do Banco de Dados SQL do Azure ( Instância Gerenciada ).
- A DBReplication é uma solução confiável pronta para uso que foi testada por muitos projetos em uma variedade de condições e tarefas.
- Se DBREPLICATION for usado no modo de troca unidirecional, a direção da troca poderá ser alterada.
Além disso, notamos mais um recurso importante:
- O DBREPLICATION pode operar em um modo de troca bidirecional, quando é possível inserir / alterar dados simultaneamente em todos os bancos de dados participantes da troca. O número de bases que podem ser incluídas no circuito de troca não é limitado.
Exemplo prático de aplicação
Uma grande empresa russa possui um sistema de contabilidade de aplicativos baseado na plataforma 1C 8 + MS SQL Server. A principal base operacional já ultrapassou 2 terabytes e continua a crescer. Ao mesmo tempo, a carga está aumentando cada vez mais: transacional e analítico. No final, várias razões foram formadas para a convolução da base. Decidiu-se cortar os dados históricos para o início de 2017. A técnica descrita aqui usando DBReplication foi selecionada.
Por si só, o algoritmo de convolução foi decidido a ser implementado principalmente pelo TSQL com pequenas inclusões de ferramentas 1C típicas. A tarefa foi complicada pelo fato de que nem todos os objetos aplicados (tabelas) poderiam ser recolhidos até a data programada, pois os recursos de negócios exigiam que em vários dos maiores subsistemas os dados históricos estivessem presentes na íntegra em uma profundidade de 5 a 7 anos. Portanto, do ponto de vista do volume do banco de dados, o efeito da convolução não foi tão grande quanto gostaríamos. Foi realizada uma análise preliminar, que mostrou que, considerando restrições objetivas, cerca de 33% do volume inicial será cortado. Mas isso foi avaliado pelo Cliente como um bom resultado, porque o ganho não está apenas no volume do banco de dados como tal, mas também na velocidade de tabelas individuais, e as tabelas de subsistemas recolhidos diminuíram em volume em mais de 33% - de 46% para 77% (em 2 a 2). 3 vezes).
Vamos dar uma olhada em alguns indicadores e fatos do uso real da convolução. A duração da convolução direta de dados foi de cerca de 12 horas. A sincronização das alterações acumuladas usando DBREPLICATION levou cerca de 1 hora. Um dos pontos principais do projeto foi a verificação final da base minimizada, realizada pelos especialistas do Cliente. É especialmente importante notar sua duração - esse processo levou cerca de 1 semana. Essa duração se deve ao fato de a verificação ser muito profunda e abrangente, com o envolvimento de especialistas de vários perfis, incluindo a construção de um modelo de dados em um sistema externo. Todo esse tempo, a base minimizada foi sincronizada automaticamente com o banco de dados de combate atual através do DBREPLICATION. A verificação foi bem sucedida. E os usuários foram transferidos para um banco de dados recolhido. O banco de dados anterior foi transferido para o status de arquivamento, com acesso somente leitura. Não havia necessidade de sua sincronização subsequente, portanto, a replicação foi desativada.
Resumo do Projeto:
- A técnica aplicada foi totalmente recompensada, graças a que havia tempo suficiente para concluir a convolução em si, além de verificar de forma abrangente os dados, o que minimizou radicalmente os riscos de ignorar certos erros e mudar para um banco de dados em colapso.
- Convolução concluída com sucesso:
- O volume total do banco de dados operacional diminuiu 33%. Não foi possível obter um efeito maior no volume do banco de dados por razões objetivas, devido a restrições na dobragem de alguns subsistemas grandes.
- O volume de tabelas ativamente usadas de subsistemas recolhidos diminuiu 46-77% (2-3 vezes).
Conclusão
A DBReplication é uma solução confiável e pronta para uso que está presente no mercado há muitos anos, testada por muitos projetos em diversas condições. Na técnica de convolução em consideração, o DBReplication assume completamente uma das principais subtarefas - sincronização do banco de dados. No caso de bancos de dados particularmente grandes, requisitos muito rigorosos são impostos ao sistema de intercâmbio e a DBReplication os satisfaz totalmente. Ele resolve sua tarefa de maneira confiável e eficiente, garantindo o sucesso do projeto como um todo.
Para quais outras tarefas você pode usar DBREPLICATION
Um conjunto de recursos e vantagens competitivas permite que a DBReplication seja usada para solucionar vários problemas. Para referência, nós os listamos.
- Redundância de banco de dados e tolerância a falhas.
- Balanceamento de carga: redistribuindo-o entre 2 ou mais instâncias de banco de dados síncronas.
- Transição controlada para novas versões de software (MS SQL, 1C), a técnica é semelhante à técnica de convolução.
- Construindo um sistema de informações distribuídas com troca de alta velocidade com base na replicação DBR. Em particular, a substituição da tecnologia existente de troca de empresas por uma mais produtiva e eficiente - DBREPLICATION.