Diretrizes de planejamento de servidores de banco de dados federados
Criar uma federação de servidores de banco de dados envolve projetar um conjunto de exibições particionadas distribuídas que difundirá os dados entre os servidores. O particionamento funciona bem se as tabelas no banco de dados forem naturalmente divisíveis em partições similares, onde a maior parte das linhas acessadas por qualquer instrução SQL possa ser colocada em um mesmo servidor membro. As tabelas são clusterizadas em unidades relacionadas. Por exemplo, suponha que a entrada de um pedido se refere a tabelas de Pedidos, Clientes e Peças, junto com todas as tabelas que registram as relações entre clientes, pedidos e peças. As partições funcionam melhor se todas as linhas, em um grupo lógico, puderem ser colocadas no mesmo servidor membro.
Partições simétricas
O particionamento será muito mais efetivo se todas as tabelas em um banco de dados puderem ser particionadas simetricamente da seguinte maneira:
Os dados relacionados são colocados no mesmo servidor membro, de modo que a maior parte das instruções SQL direcionadas para o servidor membro correto terão solicitações mínimas, se houver alguma, para os dados nos outros servidores membro. O objetivo de projetar uma exibição particionada distribuída pode ser estabelecido como uma regra 80/20: Projetar partições de modo que a maior parte das instruções possa ser deirecionada a um servidor membro, onde no mínimo 80 por cento dos dados estão naquele servido, e onde as consultas distribuídas são solicitadas por 20 por cento ou menos dos dados. Um bom teste para ver se o objetivo pode ser alcançado é verificar se a partição permite que todas as linhas sejam colocadas no mesmo servidor membro como todas as suas referências às linhas de chave estrangeira. O banco de dados projeta que aquele que dá suporte a esse objetivo é um bom candidato ao particionamento.
Os dados são uniformemente particionados através dos servidores de membro.
Por exemplo, suponha que uma empresa tenha dividido América do Norte em regiões. Cada funcionário trabalha em uma região e os clientes fazem a maior parte de suas compras no estado ou município onde moram. As tabelas de região e funcionário são particionadas ao longo das regiões. Os clientes são particionados entre regiões pelo seu estado. Apesar de algumas consultas exigirem dados de diversas regiões, os dados necessários para a maioria das consultas estão no servidor de uma região. Os aplicativos direcionam as instruções SQL para o servidor membro que contém a região inferida do contexto da entrada do usuário.
Partições assimétricas
Apesar das partições simétricas serem o objetivo ideal, a maioria dos aplicativos tem padrões complexos de acesso de dados que impedem o particionamento simétrico. As partições assimétricas fazem alguns servidores membro assumirem mais funções que outros. Por exemplo, apenas algumas tabelas de um banco de dados podem ser particionadas com as tabelas restantes que não foram particionadas no servidor original. As partições assimétricas podem fornecer muito do desempenho de uma partição simétrica com os seguintes benefícios importantes:
Melhora significativa do desempenho de um banco de dados que não pode ser particionado simetricamente por algum particionamento assimétrico de suas tabelas.
Particionamento bem sucedido de um grande sistema existente, fazendo uma série de melhorias iterativas e assimétricas. As tabelas escolhidas para o particionamento em cada etapa são, geralmente, aquelas que irão dar o maior ganho de desempenho naquele momento.
Em uma abordagem assimétrica, o servidor original geralmente retém algumas tabelas que não se ajustaram ao esquema de particionamento. O desempenho dessas tabelas remanescentes é, de modo geral, mais rápido do que no sistema original porque as tabelas membro se movem para os servidores membro, reduzindo a carga no servidor original.
Muitos bancos de dados podem ser particionados em mais de um modo. As partições específicas escolhidas para a implementação devem ser aquelas que melhor atendem às solicitações do intervalo típico das instruções SQL executadas pela camada de serviços comerciais.