In-Memory é un conxunto de conceptos para almacenar datos cando se almacenan na memoria RAM da aplicación e o disco utilízase para a copia de seguridade. Nos enfoques clásicos, os datos almacénanse no disco e a memoria almacénase na caché. Por exemplo, unha aplicación web con backend para procesar datos pídelles para almacenar: recíbeo, transfórmao e transfírese moitos datos pola rede. En In-Memory, os cálculos envíanse aos datos, ao almacenamento, onde se procesan e a rede está menos cargada.
Que outras posibilidades hai dispoñibles con In-Memory e que tipo de enfoque é este? Vladimir Pligin - enxeñeiro en GridGain. Este material de revisión será útil para os desenvolvedores de backend de aplicacións web que non traballaron con In-Memory e queiran probar ou estean interesados nas tendencias modernas no desenvolvemento de software e deseño de arquitectura.
Nota. O artigo baséase na transcrición do informe de Vladimir na #GetIT Conf. Antes da introdución do autoillamento, realizabamos regularmente reunións e conferencias para desenvolvedores en Moscova e San Petersburgo: discutimos tendencias, problemas actuais de desenvolvemento, problemas e as súas solucións. Non é posible realizar unha conferencia agora, pero é hora de compartir materiais útiles das anteriores.
Quen usa In-Memory e como
In-Memory úsase con máis frecuencia cando se require unha rápida interacción do usuario ou o procesamento de grandes cantidades de datos.
- Bancos use In-Memory, por exemplo, para reducir os atrasos cando os clientes usan aplicacións ou para analizar o cliente antes de emitir un préstamo.
- Fintech utiliza In-Memory para mellorar o rendemento dos servizos e aplicacións dos bancos que subcontratan o procesamento e análise de datos.
- Compañías de seguros: para calcular riscos, por exemplo, analizando os datos dos clientes durante varios anos.
- Empresas de loxística. Procesan moitos datos, por exemplo, para calcular rutas óptimas para o transporte de mercadorías e pasaxeiros con miles de parámetros e rastrexar o estado dos envíos.
- Venda ao por menor. As solucións In-Memory axudan a atender aos clientes máis rápido e procesar grandes volumes de información: envíos, facturas, transaccións, a presenza de miles de mercadorías en almacéns e elaborar informes analíticos.
- В Internet das cousas In-Memory substitúe as bases de datos tradicionais.
- Farmacéutico as empresas usan In-Memory, por exemplo, para clasificar combinacións de composicións de medicamentos.
Vouche contar algúns exemplos de como os nosos clientes usan as solucións In-Memory e de como podes implementalas ti mesmo.
In-Memory como almacenamento principal
Un dos nosos clientes é un gran provedor de equipos médicos científicos dos Estados Unidos. Usan unha solución In-Memory como principal almacenamento de datos. Todos os datos gárdanse no disco e o subconxunto de datos que se usa activamente gárdase na memoria RAM. Os métodos de acceso ao almacenamento son estándar: GDBC (Generic Database Connector) e linguaxe de consulta SQL.
Colectivamente, isto chámase Base de datos en memoria (IMDB) ou Almacenamento centrado na memoria. Esta clase de solucións ten moitos nomes, estes non son os únicos.
Características IMDB:
- Os datos que se almacenan en In-Memory e aos que se accede a través de SQL son os mesmos que noutros enfoques. Están sincronizados, só é diferente a forma de presentación, a forma de abordalas. A transaccionalidade funciona entre os datos.
- IMDB é máis rápido que as bases de datos relacionais porque é máis rápido recuperar información da RAM que do disco.
- Os algoritmos de optimización internos teñen menos instrucións.
- Os IMDB son axeitados para xestionar datos, eventos e transaccións en aplicacións.
Os IMDB admiten parcialmente ACID: atomicidade, consistencia e illamento. Pero non admiten a "durabilidade": cando se apaga a alimentación, pérdense todos os datos. Para resolver o problema, pode usar instantáneas: unha "instantánea" da base de datos, análoga a unha copia de seguridade da base de datos nun disco duro, ou gravar transaccións (rexistros) para restaurar os datos despois dun reinicio.
Para crear aplicacións tolerantes a fallos
Imaxinemos a arquitectura clásica dunha aplicación web tolerante a fallos. Funciona así: todas as solicitudes son distribuídas por un equilibrador web entre servidores. Este sistema é estable porque os servidores duplícanse e fan unha copia de seguridade en caso de incidencias.
O equilibrador dirixe todas as solicitudes dunha sesión estrictamente a un servidor. Este é un mecanismo de sesión stick: cada sesión está asociada a un servidor onde se almacena e procesa localmente.
Que pasa cando falla un dos servidores?
O servizo non se verá afectado porque a arquitectura está duplicada. Pero perderemos un subconxunto das sesións do servidor morto. E ao mesmo tempo, os usuarios que están vinculados a estas sesións. Por exemplo, un cliente fai un pedido e de súpeto bótao da oficina. Será infeliz cando inicie sesión de novo e descubra que todo terá que facerse de novo.
Requírese unha aplicación web para soportar un gran número de usuarios e non ralentizar para que poidan traballar con comodidade. Pero se se rexeita, con cada solicitude posterior aumentará o tempo que tarda en comunicarse co almacenamento da sesión. Isto aumenta a latencia media para outros usuarios. Pero non queren esperar máis do que están acostumados.
Este problema pódese resolver como o noso outro cliente, un gran provedor de PASS dos EUA. Usa In-Memory para agrupar sesións web. Para iso, gárdaos non localmente, senón centralmente, nun clúster en memoria. Neste caso, as sesións están dispoñibles moito máis rápido porque xa están na memoria RAM.
Cando un servidor falla, o equilibrador envía solicitudes desde o servidor fallido a outros servidores, como na arquitectura clásica. Pero hai unha diferenza importante: as sesións almacénanse nun clúster en memoria e os servidores teñen acceso ás sesións do servidor caído.
Esta arquitectura aumenta a tolerancia a fallos de todo o sistema. Ademais, é posible abandonar o mecanismo de sesión de stick por completo.
Procesamento analítico transaccional híbrido (HTAP)
Normalmente, os sistemas transaccionais e analíticos mantéñense separados. Cando se separan, a base principal está sometida a carga. Para o procesamento analítico, os datos cópianse nunha réplica para que o procesamento analítico non interfira cos procesos transacionais. Pero a copia prodúcese cun atraso; é imposible replicar sen un atraso. Se o facemos de forma sincronizada, tamén ralentizará a base principal e non obteremos ningunha ganancia.
En HTAP, todo funciona de forma diferente: o mesmo almacén de datos utilízase para a carga transaccional das aplicacións e para consultas analíticas que poden levar moito tempo. Cando os datos están na memoria RAM, as consultas analíticas execútanse máis rápido e o servidor coa base de datos está menos cargado (de media).
Un enfoque híbrido rompe o muro entre o procesamento de transaccións e a analítica. Se realizamos análises no mesmo almacenamento, lánzanse consultas analíticas sobre os datos da memoria RAM. Son moito máis precisos, máis interpretables e adecuados.
Integración de solucións In-Memory
Un xeito (relativamente) sinxelo - desenvolver todo dende cero. Gardamos os datos no disco e almacenamos os datos quentes na memoria. Isto axuda a sobrevivir aos reinicios ou interrupcións do servidor.
Aquí hai dous escenarios principais cando os datos se almacenan no disco. No primeiro, queremos sobrevivir a fallos ou reinicios regulares do clúster ou das partes; queremos usalo como unha simple base de datos. No segundo escenario, cando hai demasiados datos, algúns están na memoria.
Se non é posible construír todo desde cero, é posible integrar In-Memory nun arquitectura existente. Pero non todas as solucións en memoria son adecuadas para iso. Hai tres condicións obrigatorias. A solución In-Memory debe admitir:
- forma estándar de conectarse á base de datos que estará situada debaixo dela (por exemplo, MySQL);
- unha linguaxe de consulta estándar, para non reescribir e cambiar a lóxica de interacción co almacenamento;
- transaccional - preservar a semántica da interacción.
Se se cumpren as tres condicións, entón a integración é posible. Colocamos a cuadrícula de datos en memoria entre a aplicación e a base de datos. Agora as solicitudes de escritura delegaranse na base de datos subxacente e as solicitudes de lectura delegaranse na base de datos subxacente se os datos non están na caché.
Se o acceso rápido aos datos e o seu procesamento é importante para ti, por exemplo, para a análise de empresas, podes pensar en implementar In-Memory. E para a implementación, pode usar ambos métodos ao deseñar unha nova arquitectura.
Fonte: www.habr.com