🥇In-memory architecture for web services: technology fundamentals and principles

In-Memory is a set of data storage concepts where data is kept in the application's RAM, while the disk is used for backup. In traditional approaches, data is stored on disk with memory serving as cache. For example, a web application with a backend for data processing requests data from storage: it retrieves, transforms, and transmits large amounts of data over the network. In In-Memory computing, computations are sent to the data—located in storage—where they are processed, reducing network load.

Thanks to its architecture, In-Memory significantly accelerates data access speed, sometimes by orders of magnitude. For example, bank analysts want to view a report on issued loans in daily dynamics over the past year in an analytical application. This process on a traditional DBMS would take minutes, whereas with In-Memory it appears almost instantly. This is because the approach allows for caching much more information, which is stored in RAM 'at hand.' The application doesn't need to request data from the hard drive, which is limited by the speed of the network and disk.

What other possibilities are available with In-Memory and what this approach entails will be discussed by Vladimir Pligin — an engineer at GridGain. This overview material will be useful for backend web application developers who have not worked with In-Memory and wish to try it, or are curious about modern trends in software development and architectural design.

Note. The article is based on a transcript of Vladimir's presentation at the #GetIT Conf conference. Before the introduction of self-isolation, we regularly held meetups and conferences for developers in Moscow and St. Petersburg, discussing trends, relevant development issues, problems, and their solutions. Now that conferences cannot be held, it's the perfect time to share valuable materials from the past.

Who uses In-Memory and how

In-Memory is most commonly used where fast user interaction or processing large amounts of data is required.

Banks use In-Memory, for example, to reduce latency for customers using applications or for client analysis before granting a loan.
Fintech uses In-Memory to enhance the performance of services and applications for banks that outsource data processing and analysis.
Insurance companies: for risk calculation, for example, by analyzing client data over several years.
Logistics companies. They process large amounts of data, for instance, to calculate optimal routes for freight and passenger transportation with thousands of parameters, tracking the status of shipments.
Retail. In-Memory solutions help to serve customers faster and process large volumes of information: shipments, invoices, transactions, availability of thousands of products in warehouses, and preparing analytical reports.
In IoT In-Memory replaces traditional databases.
Pharmaceutical companies use In-Memory, for example, to iterate through combinations of drug compositions.

I will share several examples of how our clients use In-Memory solutions and how you can implement them in your organization.

In-Memory as a primary storage

One of our clients is a major supplier of medical scientific equipment from the USA. They use an In-Memory solution as their primary data storage. All data is stored on disk, while a subset of actively used data is kept in RAM. Access methods to the storage are standard — GDBC (Generic Database Connector) and SQL query language.

All together this is referred to as In-Memory Database (IMDB) or Memory-Centric Storage. This class of solutions has many names, and these are not the only ones.

IMDB features:

The data stored in In-Memory and accessible via SQL are the same as in other approaches. They are synchronized, differing only in the way they are presented and how to access them. There is transactional consistency among the data.

IMDB is faster than relational databases because retrieving information from RAM is quicker than from disk.
The internal optimization algorithms have fewer instructions.
IMDBs are suitable for managing data, events, and transactions in applications.

IMDB partially supports ACID: atomicity, consistency, and isolation. However, they do not support 'durability' — when power is lost, all data is lost. To mitigate this issue, snapshots can be used — a 'snapshot' of the database, similar to a database backup to a hard drive, or logging transactions to recover data after a reboot.

To create fault-tolerant applications

Let’s consider the classic architecture of a fault-tolerant web application. It works like this: a web load balancer distributes all requests among the servers. This system is robust because the servers duplicate each other and provide backup during incidents.

The load balancer directs all requests from a single session strictly to one server. This is the sticky session mechanism: each session is bound to server, where it is stored and processed locally.

What happens when one of the servers?

The service remains unaffected because the architecture is duplicated. However, we lose a subset of sessions from the failed server. Along with that, users linked to these sessions are also lost. For example, a client places an order and suddenly gets thrown out of their account. They will be dissatisfied when they log in again and find that they have to redo everything.

The web application must support a large number of users without ‘lagging’ so they can work comfortably. However, in case of a failure, with each subsequent request, the time spent communicating with the session storage will increase. This raises the average latency for other users. But they do not want to wait longer than they are accustomed to.

This problem can be solved, as with another client of ours—a large PaaS provider from the USA. They use In-Memory to cluster web sessions. For this, they store them not locally, but centrally—in an In-Memory cluster. In this case, sessions are accessible much faster because they are already in RAM.

When a server crashes, the load balancer redirects requests from the failed server to other servers, just as in the classic architecture. But there’s an important difference: sessions are stored in the In-Memory cluster and the servers have access to the sessions of the failed server.

This architecture increases the fault tolerance of the entire system. Moreover, it is even possible to completely abandon the sticky session mechanism.

Hybrid transactional-analytical processing (HTAP)

Typically, transactional and analytical systems are kept separate. When they are separated, the main database is under load. To process data analytically, the data is copied into a replica to prevent analytical processing from interfering with transactional processes. However, the copying occurs with a delay—replication cannot be done without lag. If we were to do this synchronously, it would also slow down the main database without yielding any benefits.

In HTAP, everything works differently— the same data store is used for transactional loads from applications and for analytical queries that may take a long time to execute. When data resides in memory, analytical queries are executed faster, and the database server is less burdened (on average).

The hybrid approach 'breaks down the wall' between transaction processing and analytics. When we perform analytics on the same storage, analytical queries are run on data from memory. They are much more accurate, interpretable, and relevant.

Integration of In-Memory Solutions

A relatively simple way is to develop everything from scratch.We keep data on disk, while hot data is stored in memory. This helps to withstand server restarts or outages.

There are two main scenarios when data is stored on disk. In the first, we want to withstand crashes or scheduled restarts of the cluster or parts—we want to use it just like a simple database. In the second scenario, when there is too much data, a portion of it resides in memory.

If it is not possible to build everything from scratch, it is possible to integrate In-Memory into the already existing architecture.But not all In-Memory solutions are suitable for this. There are three mandatory conditions. An In-Memory solution must support:

a standard way to connect to the database that will be underneath it (for example, MySQL);
a standard query language, so that logic for interacting with the storage does not need to be rewritten and modified;
transactionality—to maintain the semantics of interaction.

If all three conditions are met, then integration is possible. We place the In-Memory Data Grid between the application and the database. Now, write queries will be delegated to the lower-level database, and read queries will go to the database if the data is not in the cache.

If fast data access and processing are important to you, for instance for business analytics, you might consider implementing In-Memory. You can use both methods when designing a new architecture.

Source: habr.com