Soluções de banco de dados SQL Server sobrecarregadas de alta transação

5

O banco de dados atual do SQL Server está sobrecarregado e muitas transações estão falhando. Os poderes que têm uma solução proposta para construir um banco de dados separado para manipular / armazenar transações e, em seguida, inseri-los de forma assíncrona no sistema atual. Especificamente, persista novas transações para um novo banco de dados e, em seguida, construa rotinas para inserir os dados do novo banco de dados no banco de dados atual / antigo.

Estou procurando o melhor método para implementar essa solução ... devo usar uma tabela não indexada no novo banco de dados proposto para inserção rápida e, em seguida, usar a inserção em massa do newdb - > olddb para mover os dados de volta para o banco de dados principal? Isso é feito da melhor maneira @ intervalos programados ou em tempo real?

Também queria saber se a ampliação / desativação ajudaria aqui (orçamento permitido)? Meu pensamento inicial foi recomendar a compra de um segundo servidor e a configuração de um cluster para reduzir a carga.

Para ser honesto, achei que as transações na web acabariam com o tempo limite e não falhariam (mas eu acho que é basicamente o mesmo)?

    
por bbqchickenrobot 20.04.2012 / 00:45
fonte

3 respostas

2

O CQRS é um bom ângulo a seguir para muitas coisas. Mas não tenho certeza se está bem aqui.

O que eles realmente estão propondo é criar um barramento de serviço de algum tipo. O conceito geral é que a transação ao vivo é gravada em uma fila de mensagens persistente que é processada e enviada para os serviços apropriados. Você pode querer olhar para [presumindo a tag do .NET b / c SQL Server]:

Para começar. Existem muitas opções por aí, mas o modelo proposto é sólido. Lotes de minas terrestres neste espaço, rolando o seu próprio definitivamente não é recomendado.

O outro ângulo aqui é mensurável e instrumentação. Você pode perder muito tempo tentando adivinhar porque as coisas falharam. Saber por que as coisas falharam é inestimável.

    
por 20.04.2012 / 03:36
fonte
1

Sim, esse tipo de coisa funciona, mas geralmente é obtido usando um banco de dados na memória, como TimesTen , fizemos algo assim para entregar quantidades massivas de entradas de CDR uma vez. Dê uma olhada nos whitepapers do site para obter alguns bons conselhos sobre como configurar essa configuração, os mesmos princípios se aplicam se você estiver usando um banco de dados "em disco" em vez de TimesTen.

Você ainda precisará de um segundo servidor para executá-lo, apenas executar 2 instâncias em um único servidor é inútil, seria melhor configurar sua configuração existente do que executar 2 DBs no mesmo hardware. Eu duvido que um cluster ajude, pois ele tem um pouco de sobrecarga na reconciliação das transações gravadas em suas tabelas - mas isso depende da sua carga de trabalho, se cada transação é completamente idempotente ou não.

O tempo limite pode ser considerado um fracasso, mas tecnicamente são coisas diferentes que você pode manipular de diferentes maneiras.

    
por 20.04.2012 / 01:05
fonte
1

Uma solução muito semelhante à sua proposta é "CQRS" e / ou "sourcing de evento", você deve ler em ambos e escolher os aspectos específicos que podem ser aplicados à fatia certa de sua aplicação - supondo que esta seja a resposta correta.

Como uma visão geral simples, separando seu banco de dados OLTP e de relatórios e aplicando "relatórios" como um termo muito mais amplo do que anteriormente. Embora você possa não pensar em "listar todos os produtos que um cliente comprou" como um relatório, uma vez que é uma pequena transação normalmente feita no OLTP, sob o CQRS, é recomendável considerar isso como dados de relatório.

A terceirização de eventos incentiva você a registrar dados de transações e usá-los para compor seus dados para relatórios / outros fins.

Re: clustering - depende dos seus pontos de dor. Se a arquitetura do seu aplicativo não suportar escalonamento, a configuração de um cluster trará benefícios mínimos, talvez a capacidade do servidor 2x traga um aumento de 10% no desempenho devido aos principais gargalos no processamento ou na estrutura de dados. (Lei de Amdahl).

    
por 20.04.2012 / 01:56
fonte