Eu tenho um banco de dados SQL Server, que é quase um banco de dados somente leitura (o procedimento de gravação acontecerá no horário agendado, normalmente duas vezes por dia). Eu descobri recentemente sobre a tabela na memória (sou um desenvolvedor, não um especialista em DBA) e me pergunto se pode ser uma boa ideia mover o banco de dados para uma versão "na memória"; e quais são os problemas gerais desta configuração.
Tabelas na memória são um tópico novo para mim, estou bastante confuso sobre o fato de se essas tabelas são boas para acelerar apenas a operação de IO ou também consultas simples (em particular consultas que já são discretas). Também estou curioso para entender se esta tecnologia é uma boa escolha também quando o SQL Server pode usar SSD discretamente rápido. Não quero ser muito amplo em minha pergunta, mas também estou curioso sobre possíveis problemas conhecidos que podem ocorrer durante a migração para essa tecnologia.
PS: Para lhe dar um pouco de experiência, a ideia me veio à mente, porque estou enfrentando um pequeno problema de desempenho. As consultas já têm bastante desempenho, mas tenho algumas (já otimizadas o máximo que posso) que levam aproximadamente 0,2-0,3s, muito para minha necessidade. Só por curiosidade, acrescentarei que essa necessidade de tempo se deve ao fato de que essas consultas "lentas" estão vinculadas a uma solicitação da web, que deve ser concluída em menos de um segundo.
As tabelas na memória parecem uma ótima ideia em teoria, mas há vários problemas e limitações com elas na prática, que geralmente são boas apenas para casos de uso muito específicos que a maioria das pessoas não possui.
Aqui estão alguns documentos da Microsoft sobre suas limitações:
Recursos do SQL Server sem suporte para OLTP na memória
Construções Transact-SQL não suportadas pelo OLTP na memória
Tipos de dados com suporte para OLTP na memória
Algumas das limitações notáveis incluem:
DATETIMEOFFSETouXMLSe você deseja evitar as dificuldades e limitações das tabelas in-memory, mas ainda se beneficiar das operações e do fluxo de trabalho otimizados para memória, basta adicionar uma quantidade adequada de memória ao seu servidor, conforme discutido em Como implementar o OLTP in-memory de forma rápida e fácil . (Existem também alguns outros bons links sobre problemas encontrados com o recurso de tabelas In-Memory, como escrever sua própria lógica de detecção e repetição de conflitos .) Quanto mais memória disponível para sua instância do SQL Server, mais tabelas e páginas de os dados serão automaticamente armazenados em cache na memória para você. Não há necessidade de gerenciá-lo sozinho.
Eu não sigo esta declaração totalmente. 200ms já é menos de 1 segundo. Se houver outras coisas não relacionadas ao banco de dados que adicionam mais tempo a essa solicitação da Web, fazendo com que demore mais de um segundo, você deve concentrar seus esforços na otimização da maior parte da torta do gargalo. Caso contrário, como outros disseram nos comentários, as tabelas na memória provavelmente não são a solução para sua latência de 200 ms (especialmente se você estiver vendo isso nas execuções subsequentes da mesma consulta, quando as páginas de dados já devem estar armazenadas em cache na memória).
O melhor caminho a seguir seria otimizar as consultas ou reprojetar o banco de dados. Seu banco de dados é minúsculo com base no seu comentário " minhas tabelas são bem pequenas, cerca de 100 mil entradas por tabela (as maiores). O banco de dados inteiro tem cerca de 2,5 GB ". Portanto, tenho certeza de que seu problema é de consulta ou arquitetura, e os planos de execução provavelmente exporiam os principais gargalos. Você pode enviar os planos de consulta para Colar o plano e vinculá-los em sua postagem, se desejar mais ajuda.