Estou investigando os benefícios de atualizar do MS SQL 2012 para 2014. Um dos grandes pontos de venda do SQL 2014 são as tabelas com otimização de memória, que aparentemente tornam as consultas super rápidas.
Descobri que existem algumas limitações em tabelas com otimização de memória, como:
- Nenhum
(max)campo dimensionado - Máximo ~1 KB por linha
- Nenhum
timestampcampo - Nenhuma coluna computada
- Sem
UNIQUErestrições
Todos eles se qualificam como incômodos, mas se eu realmente quiser contorná-los para obter os benefícios de desempenho, posso fazer um plano.
O verdadeiro problema é o fato de que você não pode executar uma ALTER TABLEinstrução e precisa passar por essa ladainha toda vez que adicionar um campo à INCLUDElista de um índice. Além disso, parece que você precisa excluir os usuários do sistema para fazer alterações de esquema nas tabelas MO no banco de dados ativo.
Acho isso totalmente ultrajante, na medida em que realmente não consigo acreditar que a Microsoft possa ter investido tanto capital de desenvolvimento nesse recurso e deixado sua manutenção tão impraticável. Isso me leva à conclusão de que devo ter entendido errado; Devo ter entendido mal algo sobre tabelas com otimização de memória que me levou a acreditar que é muito mais difícil mantê-las do que realmente é.
Então, o que eu entendi errado? Você já usou tabelas MO? Existe algum tipo de interruptor ou processo secreto que os torna práticos de usar e manter?
Não, a memória realmente não é polida. Se você está familiarizado com o Agile, conhecerá o conceito de "produto mínimo entregável"; in-memory é isso. Tenho a sensação de que a MS precisava de uma resposta para o Hana da SAP e seus semelhantes. Isso é o que eles poderiam obter depurado no prazo para uma versão de 2014.
Como qualquer outra coisa in-memory tem custos e benefícios associados a ela. O principal benefício é o rendimento que pode ser alcançado. Um dos custos é a sobrecarga de gerenciamento de mudanças, como você mencionou. Isso não o torna um produto inútil, na minha opinião, apenas reduz o número de casos em que fornecerá benefícios líquidos. Assim como os índices columnstore agora são atualizáveis e os índices podem ser filtrados, não tenho dúvidas de que a funcionalidade de in-memory melhorará nos próximos lançamentos.
O SQL Server 2016 agora está disponível para todos. Assim como eu supunha, o OLTP In-Memory recebeu vários aprimoramentos. A maioria das mudanças implementa a funcionalidade que as tabelas tradicionais desfrutam há algum tempo. Meu palpite é que os recursos futuros serão lançados ao mesmo tempo para as tabelas in-memory e tradicionais. As tabelas temporais são um exemplo. Novidade nesta versão, é compatível com tabelas in-memory e baseadas em disco .
Um dos problemas com a nova tecnologia - especialmente uma versão V1 que foi divulgada em voz alta como não completa - é que todo mundo entra na onda e assume que é um ajuste perfeito para cada carga de trabalho. Não é. O ponto ideal da Hekaton são as cargas de trabalho OLTP abaixo de 256 GB com muitas pesquisas de pontos em 2-4 soquetes. Isso corresponde à sua carga de trabalho?
Muitas das limitações têm a ver com tabelas na memória combinadas com procedimentos compilados nativamente. É claro que você pode ignorar algumas dessas limitações usando tabelas na memória, mas não usando procedimentos compilados nativamente ou, pelo menos, não exclusivamente.
Obviamente, você precisa testar se o ganho de desempenho é substancial em seu ambiente e, se for, se as compensações valem a pena. Se você está obtendo grandes ganhos de desempenho com as tabelas na memória, não sei por que está preocupado com a quantidade de manutenção que fará nas colunas INCLUDE. Seus índices na memória são, por definição, cobertura. Isso só deve ser realmente útil para evitar pesquisas em intervalos ou varreduras completas de índices não agrupados tradicionais, e essas operações não devem realmente acontecer em tabelas na memória (novamente, você deve criar um perfil de sua carga de trabalho e ver quais operações melhoram e quais não - nem tudo é ganha-ganha). Com que frequência você usa colunas INCLUDE em seus índices hoje?
Basicamente, se ainda não vale a pena para você em sua forma V1, não o use. Essa não é uma pergunta que podemos responder para você, exceto para dizer que muitos clientes estão dispostos a conviver com as limitações e estão usando o recurso com grande benefício, apesar delas.
SQLServer 2016
Se você está a caminho do SQL Server 2016, escrevi no blog sobre os aprimoramentos que você verá no OLTP in-memory, bem como a eliminação de algumas das limitações . Mais notavelmente:
Você não pode clicar com o botão direito do mouse em uma tabela com otimização de memória, para abrir um designer e adicionar novas colunas conforme desejar, de dentro do Sql Server Management Studio. Você também não pode clicar no nome da tabela como forma de renomear a tabela. (SQL 2014 no momento em que escrevi isso.)
Em vez disso, você pode clicar com o botão direito do mouse na tabela e executar o script de um comando de criação para uma nova janela de consulta. Este comando de criação pode ser corrigido adicionando novas colunas.
Portanto, para modificar a tabela, você pode armazenar os dados em uma nova tabela, tabela temporária ou variável de tabela. Em seguida, você pode descartar e recriar a tabela com o novo esquema e, finalmente, copiar de volta os dados reais . Este jogo de 3 contêineres é apenas um pouco menos conveniente para a maioria dos casos de uso.
Mas você não teria motivos para se preocupar com tabelas com otimização de memória se não houvesse um problema de desempenho que estivesse tentando resolver.
Em seguida, você terá que avaliar se as limitações e soluções alternativas valem a pena para o seu caso de uso. Você tem um problema de desempenho? Você já tentou de tudo? Isso melhorará seu desempenho em 10-100x? Usá-lo ou não usá-lo provavelmente acabará sendo um pouco óbvio de qualquer maneira.
você pode usar In-Memory OLTP em Servidores Operacionais sem maiores problemas. utilizamos esta tecnologia em uma empresa de Bancos e Pagamentos,
Em geral, podemos usar tabelas com otimização de memória quando a carga de trabalho é muito alta. usando In-Memory OLTP você pode alcançar um melhor desempenho para 30X! A Microsoft corrige a maioria dessas limitações no SQL Server 2016 e 2017. As tabelas com otimização de memória têm uma arquitetura completamente diferente em comparação com as tabelas baseadas em disco.
tabelas com otimização de memória são de dois tipos. tabelas duráveis e tabelas não duráveis. As tabelas duráveis e não duráveis mantêm os dados da tabela na memória. Além disso, tabelas mais duráveis persistem dados em discos para recuperação de dados e esquema. na maioria dos cenários operacionais, devemos usar tabelas duráveis porque os dados perdidos são críticos aqui. em alguns cenários, por exemplo, carregamento de ETL e armazenamento em cache, podemos usar tabelas não duráveis.
você pode usar esses ebooks e aprender a usar essa tecnologia:
Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp
Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718