Como a bwin está usando SQL Server 2016 In-Memory OLTP para alcançar desempenho e escala sem precedentes.
A bwin (parte do GVC Holdings PLC) é uma das principais marcas de apostas online da Europa e é sinônimo de esportes. Com escritórios situados em vários locais em toda a Europa, Índia e EUA, a bwin é líder em vários mercados, incluindo Alemanha, Bélgica, França, Itália e Espanha.
Para poder alcançar seus objetivos nesses mercados cada vez mais competitivos, a infraestrutura da bwin é constantemente empurrada para atender às demandas de tecnologia de hoje e, às vezes, até mesmo do futuro. Com cerca de 19 milhões de apostas e mais de 250 000 usuários ativos por dia, nossos requisitos de desempenho e escala são extraordinários. Neste blog, vamos discutir como adotamos o OLTP em memória com o SQL Server 2014 para atender a essas demandas.
Nossos sistemas de armazenamento em cache:
Durante anos, dependemos do Microsoft AppFabric e de outros sistemas de cache distribuídos, como a Cassandra ou a Memcached , como uma das peças centrais da nossa arquitetura, para atender aos exigentes requisitos em nossos sistemas. Todos os principais componentes, incluindo apostas esportivas, poker e jogos de cassino, dependem desse cache, o que o torna um componente crítico para nossas necessidades comerciais atuais e futuras. De fato, uma falha neste sistema de cache seria traduzido diretamente para um total apagamento do nosso negócio, tornando-o um dos sistemas mais críticos da missão na arquitetura geral.
Com esta configuração, enfrentamos problemas de escalabilidade, e pior ainda, vimos isso com maiores volumes de transações, a estabilidade de todo o sistema de cache distribuído não conseguiu acompanhar a carga de trabalho. Mesmo na redução da quantidade de nós de cache, ainda enfrentamos problemas de estabilidade, levando a uma degradação de alta disponibilidade.
Por estas razões, para tornar-se mais estável e acompanhar os requisitos de negócios, fomos obrigados a considerar melhores alternativas e soluções globais para a nossa camada de cache.
Esse foi o momento em que percebemos que já tínhamos a solução - codinome project "Hekaton", o mecanismo OLTP In-Memory, construído no SQL Server. Na verdade, esta foi a tecnologia que já estávamos usando para uma solução similar por um tempo, nosso ASP.NET SessionState.
Bwin foi o primeiro cliente a usar o mecanismo OLTP In-Memory para um banco de dados ASP.Net SessionState em produção, com o SQL Server 2014 (muito antes de ser chamado de SQL Server 2014). Para referência, antes do SQL Server 2014, nosso banco de dados SessionState do ASP.NET foi capaz de lidar com cerca de 12.000 solicitações por lotes / seg antes de sofrer a contenção locks. Nós fomos obrigados a implementar 18 bancos de dados SessionState e particionar nossa carga de trabalho para lidar com a carga de usuário necessária. Com o SQL Server 2014 In-Memory OLTP, poderíamos consolidar de volta a uma 7nicúninstância de banco de dados do SQL Server para lidar com ~ 300,000 pedidos em lote / seg, com o gargalo movendo para a divisão de dados, pois não havia suporte de tipos de dados LOB com memória - tabelas otimizadas.
Abaixo está o resumo das melhorias de desempenho que conseguimos usando o OLTP In-Memory para o nosso SessionState do ASP.NET. Também incluímos as solicitações / segundo do lote do monitor de desempenho e as medidas de espera no SQL Server
Com este nível de desempenho e estabilidade alcançados, juntamente com toda a experiência que reunimos durante anos trabalhando com a solução ASPS.NET SessionState, sentimos confiar em podermos utilizar isso como nosso bloco de construção para um novo sistema de cache global baseado no In- Mecanismo OLTP de memória.
Nosso novo sistema de cache global
O sistema de cache global, baseado em nossa implementação do estado da sessão ASP.NET e OLTP em memória, agora é a substituição de todos os nossos sistemas de armazenamento em cache distribuídos. Tendo mudado a arquitetura, agora não podemos acompanhar o desempenho que tivemos com o nosso sistema de cache distribuído, mas superá-lo, usando apenas um único nó de banco de dados, em comparação com os 19 nós de cache de camada intermediária anteriormente utilizados.
Além de reduzir o número de servidores necessários para obter o desempenho que precisamos, também conseguimos vários ganhos de desempenho, conforme mostrado no diagrama abaixo. O gráfico, que vem da nossa solução de monitoramento de aplicativos, mostra três coisas:
Uso : primeiro, os anéis circulares verdes representam todos os produtos diferentes (e as contagens de servidores correspondentes que são representadas pelos números nos círculos) dependentes do cache global. Isso inclui inúmeros produtos de apostas esportivas, jogos de cassino, bingo, todo o caminho para o nosso portal e API de vendas, apenas para citar alguns. Com todos esses componentes acessando o cache, tornou-se ainda mais central em nossa arquitetura do que o ASPS.NET SessionState.
Performance Throughput : Em seguida, você pode ver nossa carga média, cerca de 1,6 milhão de pedidos por minuto. Com a expansão do nosso carregamento do usuário, esperamos ter o dobro do número de solicitações por lotes / seg e esperamos poder controlar até 20 vezes essa carga.
Latência do Desempenho: Finalmente, você pode ver a latência consistente medida pelo cliente em torno do tempo de ida e volta em 1 ms. Este número é ainda mais importante se compararmos diretamente com o sistema de cache distribuído anterior, onde a latência variou o tempo todo, tendo tempos de resposta de 2ms até 200ms.
Fonte: Biljana Lazic (bwin - Senior DBA) e Rick Kutschera (bwin - Gerente de Engenharia). Avaliado por: Mike Weiner (SQLCAT)
Nos próximos tópico falaremos um pouco mais sobre a implementação do In-Memory OLTP
Ferramentas de analise tools AMR para otimização do In-Memory e outros informações ...
