Banco de Dados

abr 13, 2020 Ξ Deixe um comentário

Um guia rápido para um projeto de particionamento de dados usando RDBMS

publicado por Paulo Planez

Um pouco de história

Desde os primórdios da computação, o volume de dados armazenado sempre foi um problema para os sistemas de informação. O acumulo de registros fazia com que os sistemas se tornassem progressivamente lentos conforme o tempo ia passando.

Como solução para os problemas relacionados ao volume de registros em arquivos ou tabelas de dados, os programadores começaram a particionar dados, dividindo-os em arquivos ou tabelas diferentes, de maneira que os acessos a estes registros ficassem mais rápidos e levassem menos tempo.

Os programadores particionavam de acordo com dois princípios básicos:

Pelo ciclo de vida: Registros que já não seriam mais úteis para a operação eram movidos para um “arquivo morto” de forma a não impactar o desempenho com os registros ainda em operação
Pelo agrupamento da utilidade: Quando se agrupa grupos específicos de dados em arquivos diferentes, como por exemplo agrupar todos os lotes contábeis de contas a pagar em um arquivo e de contas a receber em outro arquivo.

O grande problema relacionado a esta solução era que todo o tratamento em relação ao particionamento dos dados era tratado no programa, através de complexos códigos que gerenciavam múltiplas origens de dados para o mesmo dado.

A partir de 1997, com a versão 8.0, a Oracle passou a incorporar em seu RDBMS o recurso de particionamento de tabelas e índices, que era feito de forma totalmente transparente para a aplicação. Essa transparência facilitou o desenvolvimento de sistemas e deixou de ser necessário o desenvolvimento de complexos código para a utilização desse recurso.

Posteriormente outros bancos de dados implementaram o recurso de particionamento e hoje é praticamente um padrão para qualquer banco de dados. A diferença entre os múltiplos concorrentes está na implementação do recurso e, principalmente, na disponibilidade de vários métodos de particionamento e na disponibilidade de uma ampla combinação de “Partition Keys” que podem ser utilizadas para implementar o particionamento em uma determinada tabela ou índice, bem como na utilização de particionamento em níveis (partition e subpartition).

O grande benefício por trás desse recurso é a significativa redução do custo de propriedade dos dados, propiciado pela estratégia de armazenamento em camadas, que permite que se mantenha a porção mais antiga dos dados disponíveis para o sistema, até mesmo em dispositivos de armazenamento com menor custo por Megabytes armazenados, sem afetar a disponibilidade e acessibilidade de dados relevantes para a operação do dia a dia da organização.

Este artigo abordará o recurso de particionamento focado no RDBMS Oracle por este ser o recurso mais completo e amplo, com maior flexibilidade na utilização das chaves de particionamento e com maior número de métodos de particionamento disponíveis, porém este recurso também está disponível em vários bancos de dados, apenas com implementações e funcionalidades diferentes, mas utilizando-se do mesmo conceito.

Este estudo também será focado não no aprofundamento sobre o recurso de particionamento, mas no projeto para se particionar tabelas de banco de dados, visto que os recursos e utilização destes são facilmente encontrados nas documentações dos diversos bancos de dados que atualmente implementam esses recursos

É importante ter em mente que, com o constante aumento do volume de dados dos sistemas de informação, este recurso se tornou extremamente estratégico para as organizações e para a gestão de dados, dessa forma os fornecedores estão constantemente aperfeiçoando seus recursos de particionamento e a cada nova versão aparecem avanços significativos nessa área.

Dessa forma, a cada nova versão de seus bancos de dados, é importante rever a documentação para identificar novos recursos e repensar a estratégia de gestão de dados, que no atual cenário de desenvolvimento de tecnologia, se torna algo extremamente dinâmico e não mais aquela visão estática que era válida por muitos anos.

O Recurso de particionamento

Segundo a Oracle (2020, tradução nossa), particionamento é:

uma poderosa funcionalidade que possibilita objetos de banco de dados, como tabelas e índices, serem subdivididas em pequenas partes para serem gerenciadas e acessadas em um nível de granularidade menor

A Oracle ainda relata como principais benefícios dessa funcionalidade:

Incremento de desempenho: Por trabalhar somente com os dados que são relevantes
Aumento da disponibilidade: Através do gerenciamento de partições individuais
Redução de custo: Pelo armazenamento da maneira mais apropriada
Facilidade de implementação: Por não requerer nenhuma alteração em aplicações ou queries

Este recurso foi criado para atender a demanda de VLDB (Very Large Data Bases), que qualifica banco de dados com significativo volume de dados, normalmente extrapolando a casa de dezenas de Terabytes, mas que, se bem aplicados, gera resultados significativos em banco de dados de qualquer tamanho, pois pode ser aplicado a qualquer tipo de sistema transacional, com qualquer volume de dados. Uma utilização correta sempre irá gerar resultados significativos em termos de melhoria do acesso aos dados, o que faz dele um recurso estratégico para a gestão de dados de uma organização.

O ciclo de vida dos dados

Ao se falar em particionamento é extremamente importante conhecer o ciclo de vida dos dados, visto que, muitas vezes, esse é o principal atributo de seu sistema de informação a ser considerado em um projeto de particionamento.

Os dados em um sistema de informação possuem seu ciclo de vida bem dividido em três etapas:

Ciclo operacional

Os dados classificados em ciclo operacional são aqueles que ainda não cumpriram por completo seu objetivo operacional e ainda são operacionalmente úteis para a organização, podendo sofrer alterações ou até mesmo cancelamento.

Alguns exemplos para entender melhor o ciclo operacional:

Um título a pagar que ainda não foi pago se encontra no ciclo operacional.
Um título a receber que ainda não foi recebido se encontra no ciclo operacional.
Uma transação de cartão de crédito que ainda está em período hábil para contestação se encontra no ciclo operacional.
Uma venda que ainda não foi entregue está em ciclo operacional.

Observe que no ciclo operacional os dados são utilizados pela área operacional da organização, podendo sofrer alterações e cancelamentos a qualquer momento. Em muitos casos, a classificação como operacional depende da estrutura do negócio da empresa.

Por exemplo: Em algumas empresas uma venda ainda não entregue pode ser considerada em ciclo operacional, visto que, antes da entrega, ela pode ser cancelada, como por exemplo uma loja de varejo que vende móveis. Para outras empresas, a venda é operacional até o momento que o produto entra em produção, não sendo mais possível cancelar o pedido a partir daí, que é o caso de uma fábrica de aviões.

Ciclo tático

Os dados classificados em ciclo tático são aqueles que já cumpriram por completo seu objetivo operacional e estão aguardando a finalização das operações que dependem desta informação.

Alguns exemplos para entender melhor o ciclo tático:

Um título a pagar que já foi pago e cuja contabilidade relacionada ao período do título ainda não foi fechada.
Um título a receber que já foi recebido e cuja contabilidade relacionada ao período do título ainda não foi fechada.
Uma transação de cartão de crédito que já passou do período hábil para contestação.
Uma venda que, por qualquer razão, não pode mais ser cancelada.

Observe que no ciclo tático os dados já deixam de ser importantes para a área operacional, sendo agora utilizados pelas áreas mais táticas da organização, especialmente a contabilidade, mas também outras áreas como produção, suprimentos, etc. visto que já não existe mais a opção de alterações dos dados em sua essência.

Por exemplo: Uma transação de cartão de crédito que não pode mais ser questionada seguirá para o fechamento da fatura com a definição do valor a ser pago pelo cliente. Esta operação coloca a transação em ciclo tático e a fatura do cartão de crédito em ciclo operacional e assim ficará até o seu pagamento. No caso desta não ser paga, ficará como operacional até uma negociação, seu processo de cobrança ou sua efetiva prescrição, onde já não há mais possibilidades de recebe-la, alterando assim o seu status.

Ciclo estratégico

Os dados classificados em ciclo estratégicos são aqueles que já cumpriram por completo seu objetivo tático e agora farão parte da base histórica de dados utilizada principalmente para a tomada de decisões.

Alguns exemplos para entender melhor o ciclo estratégico:

Um título a pagar que já foi pago e contabilizado e que agora compõe a origem dos dados para alimentar um BI de despesas da organização.
Um título a receber que já foi pago e contabilizado e que agora compõe a origem dos dados para alimentar um BI de receitas da organização.
Uma transação de cartão de crédito que já foi faturada e que agora compõe a origem de dados para alimentar um BI utilizado para avaliação de riscos dos clientes.
Uma venda que já foi finalizada e que agora compõe a origem de dados para aumentar um BI utilizado para avaliação de desempenho comercial da organização.

Observe que no ciclo estratégico os dados não são utilizados nem nas operações nem nos controles, sendo apenas base para alimentação de bases de dados estratégicas como “Data Warehouses”, “Data Marts” ou “BI’s”. A principal característica destes dados é que uma vez extraídos para completar seus objetivos estratégicos, eles raramente são consultados novamente, sendo mantidos exclusivamente por obrigações legais ou por dificuldades de extraí-los do sistema.

A divisão em ciclos nos permite enxergar de forma clara quais são os dados que sobrecarregam o sistema, tornando o acesso aos dados progressivamente lento conforme o tempo passa e o número de transações registradas no sistema se acumula.

O particionamento e o ciclo de vida dos dados

A forma tradicional de tratar os dados estratégicos para que eles não afetem progressivamente o desempenho dos sistemas transacionais é criando complexos subsistemas de extração e consulta de dados históricos.

Esses subsistemas são executados periodicamente, normalmente todo mês após o fechamento contábil, e removem todos os dados que já são considerados estratégicos para um outro banco de dados, geralmente um ambiente ODS (Operational Data Store ou Armazem de dados operacionais), onde ficaram aguardando a execução de um processo de ETL que os levará para um ambiente de dados estratégicos e posteriormente serão consultados de forma muito esporádica, quando alguma necessidade específica para visualizar esse dado se impor, formando assim um custoso arquivo morto.

Com o recurso de particionamento é possível isolar dentro do banco de dados transacional os dados que são operacionais, táticos e estratégicos, armazenando cada um em seus respectivos arquivos de dados que, por sua vez, podem ficar armazenados em Storages diferentes, sendo todos acessados a qualquer momento pelo próprio sistema transacional, não sendo necessário a criação de ambientes específicos para se manter esses dados. Os dados que compõe o “arquivo morto” podem ficar armazenados em partições específicas do sistema, configuradas com o atributo de “somente para leitura”, a um custo muito inferior do de se manter um ambiente ODS.

O isolamento dos dados em arquivos diferentes evita o principal fator de degradação do banco de dados: O crescimento progressivo dos dados e seu respectivo impacto na recuperação de dados do banco de dados.

Com o particionamento, os dados operacionais, que são aqueles mais usados nas transações do dia a dia, terão um volume de registros constantes, garantindo uma estabilidade no acesso aos dados, evitando a degradação progressiva do acesso.

Além disso é possível dimensionar os Storages conforme o ciclo de vida dos dados, a saber:

Dados em ciclo de vida operacional exigem Storages mais eficientes e rápidos, para que o desempenho na recuperação de dados não atrapalhe a operação. Este tipo de Storage é mais caro, dessa forma é possível dimensionar seu equipamento para comportar somente o volume necessário para o ciclo operacional, permitindo comprar um Storage de menor capacidade e melhor tecnologia.
Dados de ciclo de vida tático não exigem Storages tão eficientes como o ciclo operacional assim exige, porém armazena um volume maior, porém também estável, de dados, sendo possível, para este caso, visto que a demanda por dados táticos é significativamente menor que por dados operacionais, investir em um equipamento intermediário, de menor custo, mas com capacidade maior.
Dados de ciclo de vida estratégica não exigem muita eficiência de seus dispositivos de armazenamento, porém exigem disponibilidade para grandes volumes. Desta forma é possível adquirir Storages de menor qualidade e com maior capacidade, visto que a demanda por dados será muito esporádica e limitada.

Quando se desenvolve um sistema a partir do zero é interessante que as tabelas transacionais, aquelas que recebem o maior volume de dados e que, por consequência, a maior demanda de acesso, tenham em seu conjunto de campos uma flag que indica o ciclo operacional no qual o registro se encontra, dessa forma a tabela passa a ter uma chave de particionamento natural que maximizará o resultado do particionamento.

Para aplicar essa flag em sistemas que já estejam em andamento nem sempre é uma tarefa fácil e nem sempre é possível, visto que a utilização dessa flag poderia implicar em alterações significativas de código, dessa forma seria interessante buscar outros campos que pudessem ser utilizadas como chave de particionamento e que oferecessem um aumento significativo no desempenho do acesso aos dados e na estabilidade no volume de dados de cada partição.

O projeto de particionamento

Um erro clássico que se comete ao desenvolver um trabalho de particionamento é a falta de método para a definição dos objetos que serão afetados pelo recurso de particionamento e a definição das chaves de partição utilizadas neste processo.

A utilização do recurso de particionamento pode gerar inúmeros benefícios para o desempenho geral do sistema, porém, quando mal aplicado, pode ter o efeito contrário ao desejado, piorando o desempenho geral do sistema.

A escolha dos objetos a serem particionados é fundamental para que os esforços sejam direcionados aos objetos mais afetados por operações de I/O e acesso concorrente, portanto sua escolha não pode ser aleatória e deve ser baseada em método e princípios e subsidiada por informações extraída do próprio banco de dados de produção.

Mesmo que estejamos tratando do mesmo sistema, por exemplo o Oracle EBS, que está instalado em diversas empresas, não é garantia de que os objetos e as chaves de particionamento utilizados em uma empresa com sucesso oferecerão o mesmo resultado positivo quando utilizados em outra empresa. A maneira como a empresa utiliza o sistema pode mudar de forma significativa a maneira como os objetos são acessados, fazendo com que cada instância da mesma aplicação possua característica diferentes, o que torna necessário adotar estratégias de particionamento diferentes para cada instância da aplicação.

A independência gerada pelas partições individuais, junto com uma eficiente e transparente gestão dos dados operacionais e das partições, são recursos importante para que se maximize o potencial da estratégia de armazenamento por camadas, gerando benefícios para toda a infraestrutura de banco de dados, e para o sistema de forma geral.

Definindo os objetivos da utilização do recurso

Como qualquer projeto, a execução do projeto de particionamento se dá a partir de um objetivo específico, mensurável, atingível e relevante, ou o objetivo SMART. Antes de iniciar o projeto, esse objetivo deve estar bem claro para todos os participantes do projeto. Abaixo alguns objetivos do projeto:

Manter com volume constante as principais tabelas transacionais;
Garantir uma redução mínima de 50% no IO gerado em cima das tabelas transacionais;
Garantir a eliminação dos “IO Waiting Times” sobre as tabelas transacionas.

Observe que foram criados objetivos para o projeto. Em cima desses objetivos se define quais são os indicadores que serão extraídos do sistema. Esses indicadores devem ser extraídos antes, pois servirão de base de comparação, e depois, que serão utilizados para determinar o alcançamento ou não dos objetivos, ainda em tempo de desenvolvimento, e funcionarão como importante fator de decisão sobre qual método e quais chaves de particionamento serão utilizadas.

Observe que dentre os objetivos, existe um que é incompatível com o conceito SMART: O objetivo 3. Por mais esforço que você faça, é praticamente impossível eliminar por completo o IO Waiting Time de um objeto, a menos que você utiliza um recurso de InMemory Database, que no caso foge do escopo do projeto, que é a utilização do recurso de particionamento.

Identificando os Partitioning Candidates

Não é interessante que os administradores saiam particionando toda e qualquer tabela no sistema, os benefícios dessa estratégia não compensam o custo de sua implementação. O ideal é que seja feita uma análise bem profunda da demanda que os objetos sofrem durante a utilização do sistema.

O DBA deverá identificar as tabelas que serão candidatas ao particionamento através de alguns critérios que ele definirá de acordo com o objetivo definido para a utilização do recurso, e poderá contar com o recurso do “SQL Access Advisor” para sua tomada de decisões. É interessante uma análise das variáveis estatísticas de desempenho que o sistema gerenciador de banco de dados oferece e identificar quais dessas variáveis são mais úteis na mensuração dos objetivos definidos para o projeto. De posse das variáveis estatísticas, deve-se buscar no banco de dados a posição atual dessas variáveis, que servirão de base de comparação e identificar quais os objetos com o pior desempenho considerando-se essas variáveis.

Os objetos com pior desempenho são justamente os candidatos naturais a serem particionados, esperando-se que esses indicadores mostrem uma melhora significativa após a aplicação do recurso.

É importante considerar que, geralmente, esse projeto é executado em um ambiente de testes antes de ser executado em um ambiente de produção, o que pode gerar diferença de grandezas nas análises, por exemplo: Enquanto no ambiente de testes os IO por segundo estão na casa de 100 e após a aplicação do recurso essa variável caiu para 50, em produção ela pode estar em 1000, dessa forma espera-se que ela caia para 500.

Outra característica importante a se considerar é que o ambiente de produção se utiliza de dispositivos de qualidade superior em relação a um ambiente de testes, dessa forma uma melhoria de desempenho de 50% em uma variável pode representar ganhos superiores em ambiente de produção. Essa diferença de ambientes deve sempre ser considerada.

Uma dúvida comum nessa fase é como identificar as tabelas visto que o trabalho será executado em ambiente de testes, que não possui a mesma carga do ambiente de produção e, consequentemente, não será possível avaliar as variáveis do banco de dados.

Uma opção a ser considerada neste caso seria a utilização da Option RAT (Real Application Test) para reproduzir a carga de produção em um ambiente de testes. Desta forma o DBA poderá aumentar a efetividade de seu trabalho, garantindo números mais precisos e avaliações mais assertivas.

Avaliando as queries do sistema

Não importa quanto benefício o recurso de particionamento gere, se as queries executadas no sistema tiverem uma péssima qualidade, o sistema nunca irá se beneficiar do recurso de forma integral

Não existe recurso computacional que compense um código mal escrito. A máxima acima demonstra que, por mais benefícios que o recurso de particionamento possa gerar, queries mal escritas nunca aproveitarão todo o potencial que esse recurso pode trazer.

Dessa forma é extremamente importante que, depois de definido quais são os candidatos ao particionamento, seja feito um estudo da qualidade das queries aplicadas sobre esses objetos. O DBA pode se utilizar dos planos de acesso do banco de dados para identificar as queries executadas assim como a qualidade dessas queries e, caso elas estejam muito ruins, propor alterações no sistema com objetivo de melhorar o desempenho geral sobre o objeto antes que o recurso de particionamento seja aplicado.

No caso de se identificar queries de péssima qualidade e aplicar as correções de melhorias, é importante que seja feito novamente o estudo sobre os candidatos a particionamento. Em alguns casos a simples melhoria das queries que se utilizam do objeto já gera uma melhoria significativa no acesso ao objeto, fazendo com que ele deixe de ser um candidato ao particionamento.

Definindo o método e as chaves de particionamento

Esta é a fase mais complexa de todo o processo: Definir como particionar os objetos. O Ideal é que seja feita uma análise das principais queries e, associado aos objetivos do projeto, se defina o método e as chaves. Infelizmente desconheço uma query que possa ser executada e apresente com 100% de garantia o melhor método e a melhor chave para isso. Não que isso não exista, afinal, a versão Autonomous do Oracle faz justamente isso, o ponto é que eu ainda não consegui criar tal query.

Durante o processo de definição de particionamento, que por si só já muda de forma significativa a estrutura de armazenamento dos objetos do banco de dados, é interessante considerar outros recursos e conceitos disponíveis no banco de dados Oracle, como Pruning, Zone Mapping, Table Clustering e Compression. A utilização desses recursos e conceitos tem um forte potencial de maximizar o desempenho geral do banco de dados, reduzindo a carga de I/O e melhorando o tempo das pesquisas e devem ser incluídos no ciclo de testes e ter seus resultados mensurados e divulgados na análise geral do projeto de particionamento.

De qualquer maneira essa é uma análise manual que deve ser executada pelo DBA. O ideal é que ele escolha entre dois ou três métodos e aplique com dois ou três conjuntos de chaves de particionamento e faça uma comparação entre os resultados, de forma a optar por aquele que gere o melhor resultado.

Executando os testes

Definido os métodos a serem aplicados, resta ao DBA executar os testes e mensurar os resultados. Neste ponto, por se tratar de uma tarefa repetitiva, onde a mesma ação será executada várias vezes, e existe uma dependência da base original, a recomendação é que o DBA se utilize do recurso de “Restore Point” do Oracle.

Após a primeira execução, que definirá a base de comparação, cria-se um “Restore Point” e aplique o método com as chaves escolhidas e colete-se as estatísticas. Após concluído, retorna-se o “Restore Point” e aplique-se o próximo método até concluir todos os métodos e todas as chaves. Dessa forma o DBA terá uma maior produtividade na execução dos testes.

Os resultados podem ser compilados em uma planilha para, ao final fazer uma comparação e subsequente decisão sobre qual seria o melhor conjunto método/Chaves de particionamento a ser utilizado em produção.

Aplicando em produção

Após definido o melhor conjunto Método/Chave de particionamento, aplica-se em produção. É possível, não está descartado, que o resultado obtido em produção não seja tão eficiente quando o resultado obtido em teste, dessa forma recomenda-se avaliar os resultados para se identificar as possíveis razões para tal divergência e corrigi-la através da criação de uma nova estrutura de particionamento.

Esse artigo não recomenda a aplicação de particionamento em um grande volume de objetos ao mesmo tempo. Por uma questão de prudência e cautela, recomenda-se que se aplique um objeto por vez e só parta para o próximo objeto após um monitoramento do desempenho tanto geral quanto do objeto específico.

Finalizando o projeto

Após concluir a aplicação do recurso em todos os objetos elencados, e de bom apreço que se elabore uma documentação que demonstre o estado original do sistema e os ganhos obtidos com a utilização do recurso como forma de demonstrar a efetividade do trabalho e os ganhos, especialmente financeiros, da utilização do recurso.

Quando bem aplicado, esse recurso pode retardar em alguns anos a atualização do parque tecnológico, o que representa o adiamento de investimento na infraestrutura do sistema e, consequentemente, ganhos financeiros oriundos desse adiantamento.