In-Memory es un conjunto de conceptos para almacenar datos cuando se almacenan en la RAM de la aplicación y el disco se utiliza para realizar copias de seguridad. En los enfoques clásicos, los datos se almacenan en el disco y la memoria se almacena en la caché. Por ejemplo, una aplicación web con un backend para procesar datos los solicita y los almacena: los recibe, los transforma y muchos datos se transfieren a través de la red. En In-Memory, los cálculos se envían a los datos, al almacenamiento, donde se procesan y la red está menos cargada.
¿Qué otras posibilidades están disponibles con In-Memory y qué tipo de enfoque es este? Vladímir Pligin - ingeniero en GridGain. Este material de revisión será útil para los desarrolladores backend de aplicaciones web que no han trabajado con In-Memory y quieren probar, o están interesados en las tendencias modernas en el desarrollo de software y el diseño de arquitectura.
Nota. El artículo se basa en la transcripción del informe de Vladimir en la conferencia #GetIT. Antes de la introducción del autoaislamiento, celebramos periódicamente reuniones y conferencias para desarrolladores en Moscú y San Petersburgo: discutimos tendencias, problemas actuales de desarrollo, problemas y sus soluciones. No es posible realizar una conferencia ahora, pero es hora de compartir materiales útiles de conferencias anteriores.
Quién usa In-Memory y cómo
En memoria se utiliza con mayor frecuencia cuando se requiere una interacción rápida del usuario o el procesamiento de grandes cantidades de datos.
- Bancos utilice In-Memory, por ejemplo, para reducir los retrasos cuando los clientes utilizan las aplicaciones o para analizar al cliente antes de emitir un préstamo.
- Fintech utiliza In-Memory para mejorar el rendimiento de los servicios y aplicaciones de los bancos que subcontratan el procesamiento y análisis de datos.
- Compañías de seguros: para calcular riesgos, por ejemplo, analizando los datos de los clientes durante varios años.
- Empresas de logística. Procesan muchos datos, por ejemplo, para calcular rutas óptimas para el transporte de mercancías y pasajeros con miles de parámetros y realizar un seguimiento del estado de los envíos.
- Minorista. Las soluciones In-Memory ayudan a atender a los clientes más rápido y procesar grandes volúmenes de información: envíos, facturas, transacciones, la presencia de miles de mercancías en almacenes y preparar informes analíticos.
- В IoT In-Memory reemplaza las bases de datos tradicionales.
- Farmacéutico las empresas utilizan In-Memory, por ejemplo, para clasificar combinaciones de composiciones de medicamentos.
Le contaré algunos ejemplos de cómo nuestros clientes utilizan las soluciones In-Memory y cómo puede implementarlas usted mismo.
En memoria como almacenamiento principal
Uno de nuestros clientes es un gran proveedor de equipos científicos médicos de EE. UU. Utilizan una solución In-Memory como principal almacenamiento de datos. Todos los datos se almacenan en el disco y el subconjunto de datos que se utiliza activamente se guarda en la RAM. Los métodos de acceso al almacenamiento son estándar: GDBC (Generic Database Connector) y lenguaje de consulta SQL.
En conjunto, esto se denomina base de datos en memoria (IMDB) o almacenamiento centrado en la memoria. Esta clase de soluciones tiene muchos nombres, estos no son los únicos.
Características de IMDB:
- Los datos que se almacenan en memoria y a los que se accede a través de SQL son los mismos que en otros enfoques. Están sincronizados, sólo que la forma de presentarlos, la forma de abordarlos es diferente. La transaccionalidad funciona entre datos.
- IMDB es más rápido que las bases de datos relacionales porque es más rápido recuperar información de la RAM que del disco.
- Los algoritmos de optimización internos tienen menos instrucciones.
- Los IMDB son adecuados para gestionar datos, eventos y transacciones en aplicaciones.
Los IMDB soportan parcialmente ACID: Atomicidad, Consistencia y Aislamiento. Pero no admiten la "durabilidad": cuando se corta la alimentación, se pierden todos los datos. Para resolver el problema, puede utilizar instantáneas: una "instantánea" de la base de datos, análoga a una copia de seguridad de la base de datos en un disco duro, o registrar transacciones (registros) para restaurar datos después de un reinicio.
Para crear aplicaciones tolerantes a fallos
Imaginemos la arquitectura clásica de una aplicación web tolerante a fallos. Funciona así: todas las solicitudes se distribuyen mediante un equilibrador web entre servidores. Este sistema es estable porque los servidores se duplican entre sí y realizan copias de seguridad en caso de incidencias.
El equilibrador dirige todas las solicitudes de una sesión estrictamente a un servidor. Este es un mecanismo de sesión permanente: cada sesión está asociada con un servidor donde se almacena y procesa localmente.
¿Qué sucede cuando uno de los servidores falla?
El servicio no se verá afectado porque la arquitectura está duplicada. Pero perderemos un subconjunto de las sesiones del servidor inactivo.. Y al mismo tiempo, los usuarios que están vinculados a estas sesiones. Por ejemplo, un cliente hace un pedido y de repente lo echa de la oficina. No estará contento cuando vuelva a iniciar sesión y descubra que habrá que hacer todo de nuevo.
Se requiere que una aplicación web soporte una gran cantidad de usuarios y no ralentice para que puedan trabajar cómodamente. Pero si se rechaza, con cada solicitud posterior aumentará el tiempo necesario para comunicarse con el almacén de sesiones. Esto aumenta la latencia promedio para otros usuarios. Pero no quieren esperar más de lo que están acostumbrados.
Este problema se puede resolver como nuestro otro cliente, un gran proveedor de PASS de EE. UU. Utiliza In-Memory para agrupar sesiones web. Para ello, no los almacena localmente, sino de forma centralizada, en un clúster en memoria. En este caso las sesiones están disponibles mucho más rápido porque ya están en la RAM.
Cuando un servidor falla, el equilibrador envía solicitudes desde el servidor fallado a otros servidores, como en la arquitectura clásica. Pero hay una diferencia importante: las sesiones se almacenan en un clúster en memoria y los servidores tienen acceso a las sesiones del servidor caído.
Esta arquitectura aumenta la tolerancia a fallos de todo el sistema. Además, es posible abandonar por completo el mecanismo de sesión permanente.
Procesamiento analítico transaccional híbrido (HTAP)
Normalmente, los sistemas transaccionales y analíticos se mantienen separados. Cuando se separan, la base principal queda bajo carga. Para el procesamiento analítico, los datos se copian en una réplica para que el procesamiento analítico no interfiera con los procesos transaccionales. Pero la copia se produce con un retraso: es imposible replicar sin un retraso. Si hacemos esto de forma sincrónica, también ralentizará la base principal y no obtendremos ninguna ganancia.
En HTAP, todo funciona de manera diferente: el mismo almacén de datos se utiliza para la carga transaccional de las aplicaciones y para consultas analíticas que pueden tardar mucho en completarse. Cuando los datos están en la RAM, las consultas analíticas se ejecutan más rápido y el servidor con la base de datos está menos cargado (en promedio).
Un enfoque híbrido derriba el muro entre el procesamiento de transacciones y el análisis. Si realizamos análisis en el mismo almacenamiento, las consultas analíticas se lanzan sobre los datos de la RAM. Son mucho más precisos, más interpretables y adecuados.
Integración de soluciones en memoria
Una forma (relativamente) sencilla: desarrollar todo desde cero. Mantenemos los datos en el disco y almacenamos los datos activos en la memoria. Esto ayuda a sobrevivir a reinicios o interrupciones del servidor.
Hay dos escenarios principales en juego aquí cuando los datos se almacenan en el disco. En el primero, queremos sobrevivir a fallas o reinicios regulares del clúster o de sus partes; queremos usarlo como una base de datos simple. En el segundo escenario, cuando hay demasiados datos, algunos de ellos están en la memoria.
Si no es posible construir todo desde cero, es posible integrar In-Memory en un sistema ya arquitectura existente. Pero no todas las soluciones In-Memory son adecuadas para esto. Hay tres condiciones obligatorias. La solución In-Memory debe admitir:
- forma estándar de conectarse a la base de datos que se ubicará debajo (por ejemplo, MySQL);
- un lenguaje de consulta estándar, para no reescribir ni cambiar la lógica de interacción con el almacenamiento;
- transaccional: preservar la semántica de la interacción.
Si se cumplen las tres condiciones, entonces la integración es posible. Colocamos el In-Memory Data Grid entre la aplicación y la base de datos. Ahora las solicitudes de escritura se delegarán a la base de datos subyacente y las solicitudes de lectura se delegarán a la base de datos subyacente si los datos no están en el caché.
Si para usted es importante el acceso rápido a los datos y su procesamiento, por ejemplo, para análisis de negocios, puede pensar en implementar In-Memory. Y para la implementación, puede utilizar ambos métodos al diseñar una nueva arquitectura.
Fuente: habr.com