Imagine um fluxo de dados que é "rajada", ou seja, pode ter 10.000 eventos chegando muito rapidamente, seguidos por nada por um minuto.
Seu conselho de especialista: como posso escrever o código de inserção C# para o SQL Server, de forma que haja uma garantia de que o SQL armazene tudo imediatamente em sua própria RAM, sem bloquear meu aplicativo por mais do que o necessário para alimentar os dados na referida RAM? Para conseguir isso, você conhece algum padrão de configuração do próprio servidor SQL ou padrões para configurar as tabelas SQL individuais nas quais estou escrevendo?
Claro, eu poderia fazer minha própria versão, que envolve construir minha própria fila na RAM - mas não quero reinventar o Machado de Pedra Paleolítico, por assim dizer.
Você já tentou apenas escrever e ver o que acontece? Você tem um gargalo conhecido?
Se você precisar impedir que seu aplicativo seja bloqueado, uma maneira seria enfileirar as gravações para adiar a chamada do banco de dados. No entanto, espero que a fila seja limpa em um segundo ou 2: então, você precisa de uma fila se estiver tudo bem?
Ou você pode spool para uma mesa de preparação e, em seguida, liberar mais tarde? Usamos essa técnica para lidar com gravações contínuas de milhões de novas linhas por minuto (na verdade, usamos um banco de dados de teste com recuperação simples): mas não a implementamos até termos experiência de apenas escrever linhas.
Nota: Cada gravação no SQL Server irá para o disco como parte do protocolo Write Ahead Logging (WAL). Isso se aplica à entrada t-log para essa gravação.
A página de dados com a linha irá para o disco em algum momento (com base no tempo, uso, pressão de memória, etc.), mas geralmente seus dados estarão na memória de qualquer maneira. Isso é chamado de "Checkpointing" e não remove dados da memória, apenas libera as alterações (editado em 24 de novembro de 2011)
Editar:
Para todas as considerações, com base no último parágrafo acima, mude seu LDF para este banco de dados para um conjunto dedicado de discos para obter mais desempenho. O mesmo vale para um banco de dados de preparação (um para MDF/LDF). É bastante comum ter uma dúzia ou 3 volumes diferentes (através de uma SAN normalmente) para o seu servidor de banco de dados
A menos que esteja faltando alguma coisa, isso violaria o requisito de durabilidade do ACID ( http://en.wikipedia.org/wiki/ACID ). Ou seja, se seu aplicativo "gravar" os dados na RAM e o servidor travar, seus dados serão perdidos.
Portanto, o que você procura é um sistema não banco de dados que sirva como uma fila para eventual armazenamento em um banco de dados ou um sistema de banco de dados suficientemente rápido para o que você está fazendo. Sugiro tentar o último primeiro e ver se é suficiente; não tome problemas emprestados.
Eu usei uma vez um conjunto de dados para isso. Eu estava inserindo linhas no conjunto de dados conforme elas chegavam e havia outro thread que liberava as linhas a cada 2 segundos ou mais para o banco de dados. Você também pode usar o documento xml para fazer o cachin e depois passar o xml para o banco de dados em uma chamada, isso pode ser ainda melhor.
Cumprimentos
Piotr