In-Memory é um conjunto de conceitos para armazenar dados quando eles são armazenados na RAM do aplicativo e o disco é usado para backup. Nas abordagens clássicas, os dados são armazenados em disco e a memória é armazenada em cache. Por exemplo, uma aplicação web com back-end para processamento de dados os solicita para armazenamento: ela os recebe, os transforma e muitos dados são transferidos pela rede. No In-Memory, os cálculos são enviados para os dados - para o armazenamento, onde são processados e a rede fica menos carregada.
Que outras possibilidades estão disponíveis com o In-Memory e que tipo de abordagem é essa? Vladimir Pligin - engenheiro da GridGain. Este material de revisão será útil para desenvolvedores de back-end de aplicativos da web que não trabalharam com In-Memory e desejam experimentar ou estão interessados nas tendências modernas em desenvolvimento de software e design de arquitetura.
Nota. O artigo é baseado na transcrição do relatório de Vladimir na #GetIT Conf. Antes da introdução do auto-isolamento, realizávamos regularmente encontros e conferências para desenvolvedores em Moscou e São Petersburgo: discutimos tendências, questões atuais de desenvolvimento, problemas e suas soluções. Não é possível realizar uma conferência agora, mas é hora de compartilhar materiais úteis de conferências anteriores.
Quem usa o In-Memory e como
In-Memory é mais frequentemente usado onde é necessária uma interação rápida do usuário ou processamento de grandes quantidades de dados.
- Bancos use o In-Memory, por exemplo, para reduzir atrasos quando os clientes usam aplicativos ou para analisar o cliente antes de emitir um empréstimo.
- Fintech usa In-Memory para melhorar o desempenho de serviços e aplicações para bancos que terceirizam processamento e análise de dados.
- Companhias de seguros: para calcular riscos, por exemplo, analisando dados de clientes ao longo de vários anos.
- Empresas de logística. Eles processam muitos dados, por exemplo, para calcular rotas ideais para transporte de cargas e passageiros com milhares de parâmetros e rastrear o status das remessas.
- Varejo. As soluções In-Memory ajudam a atender os clientes com mais rapidez e a processar grandes volumes de informações: remessas, faturas, transações, presença de milhares de mercadorias em armazéns e preparar relatórios analíticos.
- В Internet das coisas In-Memory substitui bancos de dados tradicionais.
- Farmacêutico as empresas usam o In-Memory, por exemplo, para classificar combinações de composições de medicamentos.
Vou lhe contar alguns exemplos de como nossos clientes usam soluções In-Memory e como você mesmo pode implementá-las.
In-Memory como armazenamento primário
Um de nossos clientes é um grande fornecedor de equipamentos médicos científicos dos EUA. Eles usam uma solução In-Memory como principal armazenamento de dados. Todos os dados são armazenados em disco e o subconjunto de dados usado ativamente é mantido na RAM. Os métodos de acesso ao armazenamento são padrão - GDBC (Generic Database Connector) e linguagem de consulta SQL.
Coletivamente, isso é chamado de banco de dados na memória (IMDB) ou armazenamento centrado na memória. Esta classe de soluções tem muitos nomes, estes não são os únicos.
Recursos do IMDB:
- Os dados armazenados na memória e acessados por meio de SQL são os mesmos de outras abordagens. Eles estão sincronizados, só a forma de apresentação, a forma de abordá-los é diferente. A transacionalidade funciona entre dados.
- O IMDB é mais rápido que os bancos de dados relacionais porque é mais rápido recuperar informações da RAM do que do disco.
- Algoritmos de otimização interna possuem menos instruções.
- IMDBs são adequados para gerenciar dados, eventos e transações em aplicativos.
IMDBs suportam parcialmente ACID: Atomicidade, Consistência e Isolamento. Mas eles não suportam “durabilidade” - quando a energia é desligada, todos os dados são perdidos. Para resolver o problema, você pode usar instantâneos - um “instantâneo” do banco de dados, análogo a um backup de banco de dados em um disco rígido, ou registrar transações (logs) para restaurar dados após uma reinicialização.
Para criar aplicativos tolerantes a falhas
Vamos imaginar a arquitetura clássica de uma aplicação web tolerante a falhas. Funciona assim: todas as solicitações são distribuídas por um balanceador web entre servidores. Este sistema é estável porque os servidores se duplicam e fazem backup em caso de incidentes.
O balanceador direciona todas as solicitações de uma sessão estritamente para um servidor. Este é um mecanismo de sessão fixa: cada sessão está associada a um servidor onde é armazenada e processada localmente.
O que acontece quando um dos servidores falha?
O serviço não será afetado porque a arquitetura está duplicada. Mas perderemos um subconjunto das sessões do servidor morto. E ao mesmo tempo, os usuários que estão vinculados a essas sessões. Por exemplo, um cliente faz um pedido e de repente o expulsa do escritório. Ele ficará infeliz quando fizer login novamente e descobrir que tudo terá que ser feito novamente.
Um aplicativo da web é necessário para oferecer suporte a um grande número de usuários e não ficar lento para que possam trabalhar confortavelmente. Mas se for recusado, a cada solicitação subsequente o tempo de comunicação com o armazenamento da sessão aumentará. Isso aumenta a latência média para outros usuários. Mas eles não querem esperar mais do que estão acostumados.
Este problema pode ser resolvido como nosso outro cliente, um grande fornecedor de PASS dos EUA. Ele usa In-Memory para agrupar sessões da web. Para fazer isso, ele os armazena não localmente, mas centralmente - em um cluster In-Memory. Nesse caso, as sessões ficam disponíveis muito mais rapidamente porque já estão na RAM.
Quando um servidor trava, o balanceador envia solicitações do servidor travado para outros servidores, como na arquitetura clássica. Mas há uma diferença importante: as sessões são armazenadas em um cluster In-Memory e os servidores têm acesso às sessões do servidor caído.
Esta arquitetura aumenta a tolerância a falhas de todo o sistema. Além disso, é possível abandonar completamente o mecanismo de sessão stick.
Processamento Analítico Transacional Híbrido (HTAP)
Normalmente, os sistemas transacionais e analíticos são mantidos separados. Quando eles se separam, a base principal fica sob carga. Para processamento analítico, os dados são copiados para uma réplica para que o processamento analítico não interfira nos processos transacionais. Mas a cópia ocorre com atraso – é impossível replicar sem atraso. Se fizermos isso de forma síncrona, também desacelerará a base principal e não obteremos nenhum ganho.
No HTAP, tudo funciona de maneira diferente – o mesmo armazenamento de dados é usado para carga transacional de aplicativos e para consultas analíticas que podem levar muito tempo para serem concluídas. Quando os dados estão na RAM, as consultas analíticas são executadas mais rapidamente e o servidor com o banco de dados fica menos carregado (em média).
Uma abordagem híbrida derruba a barreira entre o processamento de transações e a análise. Se realizarmos análises no mesmo armazenamento, as consultas analíticas serão iniciadas nos dados da RAM. Eles são muito mais precisos, mais interpretáveis e adequados.
Integração de soluções In-Memory
Uma maneira (relativamente) simples - desenvolver tudo do zero. Mantemos os dados no disco e armazenamos os dados importantes na memória. Isso ajuda a sobreviver a reinicializações ou interrupções do servidor.
Existem dois cenários principais em ação aqui quando os dados são armazenados em disco. No primeiro, queremos sobreviver a travamentos ou reinicializações regulares do cluster ou de partes - queremos usá-lo como um banco de dados simples. No segundo cenário, quando há muitos dados, alguns deles ficam na memória.
Caso não seja possível construir tudo do zero, é possível integrar o In-Memory em um já arquitetura existente. Mas nem todas as soluções In-Memory são adequadas para isso. Existem três condições obrigatórias. A solução In-Memory deve suportar:
- forma padrão de conexão com o banco de dados que estará localizado abaixo dele (por exemplo, MySQL);
- uma linguagem de consulta padrão, para não reescrever e alterar a lógica de interação com o armazenamento;
- transacional - preserva a semântica da interação.
Se todas as três condições forem satisfeitas, a integração será possível. Colocamos o In-Memory Data Grid entre o aplicativo e o banco de dados. Agora, as solicitações de gravação serão delegadas ao banco de dados subjacente e as solicitações de leitura serão delegadas ao banco de dados subjacente se os dados não estiverem no cache.
Se o acesso rápido aos dados e seu processamento for importante para você, por exemplo, para análise de negócios, você pode pensar em implementar o In-Memory. E para implementação, você pode usar ambos os métodos ao projetar uma nova arquitetura.
Fonte: habr.com