Melhorando a escalabilidade
Os aplicativos de camada intermediária usam freqüentemente um único banco de dados para armazenar os dados, os quais podem causar limitações na expansão à medida que a carga em relação ao banco de dados aumenta. Quando os aplicativos efetuam mais leituras do que gravações, como catálogo baseado em Web, é possível expandir a parte de leitura da carga de trabalho fazendo cache de dados do tipo somente leitura em diversos bancos de dados e conectando os clientes de maneira uniforme pelos bancos de dados para distribuir a carga.
O diagrama a seguir ilustra uma configuração na qual o aplicativo e os servidores de Web usam os dados de qualquer um dos servidores em cache da árvore.
.gif "Usando a replicação para dimensionar a atividade de leitura")
Se o seu aplicativo também requer aumento de disponibilidade e/ou requer que as leituras e atualizações de um determinado usuário fluam para um servidor de aplicativo específico, e em seguida para um servidor específico em cache, consulte o exemplo em Melhorando a escalabilidade e a disponibilidade.
Exemplo Adventure Works Cycles
A Adventure Works Cycles é uma empresa de fabricação fictícia utilizada para demonstrar conceitos e cenários de banco de dados. Para obter mais informações, consulte Bancos de dados de exemplo AdventureWorks.
OAdventure Works Cycles atualizou o site recentemente para incluir os novos recursos a seguir:
Pedido on-line de produtos para os clientes.
Verificação de status de pedido on-line.
Melhores capacidades de pesquisa de literatura de produto.
Permitir pedidos on-line de produtos no site aumentou muito a atividade do único computador da empresa dedicado ao Microsoft SQL Server. Os administradores do Adventure Works decidiram usar este computador como fonte de dados replicados. Toda atividade de leitura foi expandida para três computadores adicionais que executam oSQL Server, os quais fazem cache de dados do computador de origem. Os computadores em cache controlam toda a atividade de leitura, inclusive usuários que navegam e pesquisam o catálogo de produtos, e verificam o status dos pedidos. Toda a atividade de gravação é direcionada ao banco de dados de origem.
Requisitos comuns deste cenário
Aplicativos que usam replicação para expansão normalmente têm os requisitos que seguem, os quais deverão encaminhar uma solução de replicação apropriada:
O sistema deve manter a consistência transacional.
O sistema deveria ter baixa latência: as atualizações na origem devem atingir o cache rapidamente.
O sistema deve ter alta taxa de transferência: deve controlar a replicação de um grande número de transações.
O processamento de replicação deve requerer sobrecarga mínima na origem.
Os dados requeridos no cache podem ser um subconjunto dos dados disponíveis na origem.
O tipo de replicação a ser usado nesse cenário
O SQL Server usa uma metáfora do setor de publicação para descrever os componentes do sistema de replicação. Os componentes incluem o Publicador, Assinantes, publicações e artigos, além de assinaturas. Para obter mais informações sobre os componentes do sistema, consulte Visão geral do modelo de publicação de replicação.
No diagrama acima, a origem é o Publicador. Alguns ou todos os dados da origem estão incluídos na publicação, com cada tabela de dados sendo um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). Cada cache é um Assinante para a publicação, recebendo o esquema e os dados como uma assinatura.
O SQL Server oferece diferentes tipos de replicação para diferentes requisitos de aplicativo: replicação de instantâneo, replicação transacional e replicação de mesclagem. O cenário é implementado da melhor forma com a replicação transacional, a qual fica bem ajustada para controlar os requisitos descritos na seção anterior. Para obter mais informações sobre a replicação transacional, consulte Visão geral da replicação transacional e Como a replicação transacional funciona.
Pelo design, a replicação transacional aborda os requisitos principais deste cenário:
Consistência transacional
Baixa latência
Alta taxa de transferência
Sobrecarga mínima
A opção primária a ser considerada para este cenário é a filtragem. A replicação transacional permite que você filtre as colunas e linhas, de modo que as tabelas dos Assinantes contenham somente os dados requeridos por seu aplicativo. Para obter mais informações, consulte Filtrando dados publicados.
Etapas para implementar este cenário
Para implementar este cenário, você deve primeiro criar uma publicação e assinaturas para depois inicializar cada assinatura. Clique nos links abaixo para obter mais informações sobre cada etapa:
Após a inicialização da assinatura, e com os dados fluindo entre o Publicador e os Assinantes, talvez seja necessário consultar os seguintes tópicos para obter informações sobre as tarefas comuns de administração e monitoramento: