Tabelas otimizadas para memória - elas podem ser realmente difíceis de manter?

Estou investigando os benefícios da atualização 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 nas tabelas com otimização de memória, como:

• (max)Campos sem tamanho
• ~ 1 KB máximo por linha
• Sem timestampcampos
• Nenhuma coluna computada
• Sem UNIQUErestrições

Tudo isso se qualifica como incômodo, mas se eu realmente quiser contorná-los para obter os benefícios de desempenho, posso fazer um plano.

O verdadeiro kicker é o fato de que você não pode executar uma ALTER TABLEdeclaração e precisa passar por esse rigmarole toda vez que adicionar um campo à INCLUDElista de um índice. Além disso, parece que você precisa desligar os usuários do sistema para fazer alterações no esquema das tabelas MO no banco de dados ativo.

Eu acho isso totalmente ultrajante, na medida em que eu realmente não posso acreditar que a Microsoft possa ter investido tanto capital de desenvolvimento nesse recurso, e a manutenção de tão impraticável. Isso me leva à conclusão de que devo ter chegado ao fim errado do bastão; 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 mudança ou processo secreto que os torna práticos de usar e manter?

Não, na memória isso realmente é polido. Se você estiver familiarizado com o Agile, conhecerá o conceito de "produto mínimo expedível"; na memória é isso. Tenho a sensação de que a MS precisava de uma resposta ao Hana da SAP e à sua laia. Isso é o que eles poderiam obter depurados no prazo para uma versão de 2014.

Como em qualquer outra coisa, a memória tem custos e benefícios associados. O principal benefício é o rendimento que pode ser alcançado. Um dos custos é a sobrecarga para o 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ício líquido. 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 da memória melhorará nas próximas versões.

O SQL Server 2016 agora está geralmente disponível. Assim como eu supunha, o OLTP na memória recebeu vários aprimoramentos. A maioria das alterações implementa funcionalidades que as tabelas tradicionais desfrutam há algum tempo. Meu palpite é que os recursos futuros serão lançados ao mesmo tempo para as tabelas tradicionais e na memória. Tabelas temporais é um exemplo. Novo nesta versão, ele é suportado pelas tabelas In-Memory e baseada em disco .

Um dos problemas com a nova tecnologia - especialmente uma versão V1 que foi divulgada em voz alta por não ter recursos completos - é que todo mundo pula na onda e assume que é o 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 ótimos ganhos de desempenho com as tabelas na memória, não sei por que você está preocupado com a quantidade de manutenção que fará nas colunas INCLUDE. Seus índices na memória são por definição. Isso só deve ser realmente útil para evitar pesquisas no intervalo ou em varreduras completas de índices tradicionais sem cluster, e essas operações não devem estar acontecendo nas tabelas na memória (novamente, você deve analisar sua carga de trabalho e ver quais operações melhoram. e quais não - nem tudo é ganha-ganha). Com que frequência você mexe com as colunas INCLUDE em seus índices hoje?

Basicamente, se ainda não vale a pena para você na forma V1, não a use. Essa não é uma pergunta que possamos responder, 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.

SQL Server 2016

Se você estiver no caminho do SQL Server 2016, escrevi em blog sobre os aprimoramentos que você verá no OLTP na memória, bem como a eliminação de algumas das limitações . Mais notavelmente:

• Aumento no tamanho máximo durável da tabela: 256 GB => 2 TB
• Colunas LOB / MAX, índices em colunas anuláveis, remoção de requisitos de intercalação BIN2
• Alterar e recompilar procedimentos
• Algum suporte para ALTER TABLE - ele estará offline, mas você deverá poder alterar e / ou eliminar / recriar índices (no entanto, isso não parece ser suportado nas versões atuais do CTP, portanto, não tome isso como garantia)
• Gatilhos DML, restrições de FK / verificação, MARS
• OU NÃO EXISTE, DISTINTA, UNIÃO, JUNTA EXTERNA
• Paralelismo

Você não pode clicar com o botão direito do mouse em uma tabela com otimização de memória, para criar um designer e adicionar novas colunas como desejar, no Sql Server Management Studio. Você também não pode clicar no nome da tabela como forma de renomear a tabela. (SQL 2014 na minha redação deste.)

Em vez disso, você pode clicar com o botão direito do mouse na tabela e criar um script de comando para uma nova janela de consulta. Este comando de criação pode ser alterado 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 soltar e recriar a tabela com o novo esquema e, finalmente, copiar novamente os dados reais . Este jogo de 3 contêineres é apenas um pouco menos conveniente para a maioria dos casos de uso.

Porém, você não teria motivos para se preocupar com as tabelas com otimização de memória se não houver um problema de desempenho que você esteja tentando resolver.

Em seguida, você terá que ponderar se as limitações e soluções alternativas valem a pena para o seu caso de uso. Você tem algum problema de desempenho? Você já tentou de tudo? Isso melhorará seu desempenho em 10 a 100x? Usá-lo ou não usá-lo provavelmente acabará sendo um pouco sem cérebro de qualquer maneira.

você pode usar o OLTP na memória em servidores operacionais sem nenhum problema grave. usamos essa 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 o OLTP na memória, você pode obter 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 dois tipos. tabelas duráveis ​​e tabelas não duráveis. Tabelas duráveis ​​e não duráveis ​​mantêm os dados da tabela residentes na memória. Mais tabelas duráveis ​​persistem dados em Discos para recuperação de dados e esquema. Na maior parte do cenário operacional, devemos usar tabelas duráveis, porque os dados perdidos são críticos aqui. em algum cenário, por exemplo, carregamento de ETL e cache, podemos usar tabelas não duráveis.

você pode usar estes e-books e aprender como usar esta tecnologia:

Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718