imdg (Газета)

In-memoary processing has been a pretty hot topic lately. Many companies thathistorically would not have considered using in-memory technology because it wascost prohibitive are now changing their core systems’ architectures to takeadvantage of the low-latency transaction processing that in-memory technologyoffers. This is a consequence of the fact that the price of RAM is droppingsignificantly and rapidly and as a result, it has become economical to load theentire operational dataset into memory with performance improvements of over1000x faster. In-Memory Compute and Data Grids provide the core capabilities ofan in-memory architecture.The goal of In-Memory Data Grids (IMDG) is to provide extremely highavailability of data by keeping it in memory and in highly distributed (i.e.parallelized) fashion.

By loading Terabytes of data into memory, IMDGs are ableto work with most of the Big Data processing requirements today.At a very high level IMDG is a distributed object store similar in interface to atypical concurrent hash map. You store objects with keys. Unlike traditionalsystems where keys and values are often limited to byte arrays or strings – withIMDGs you can use any domain object as either value or key. This givestremendous flexibility by allowing to keep exactly the same object your businesslogic is dealing with in the Data Grid without the extra step of marshaling and demarshaling alternative technologies would require. It also simplifies the usage ofdata grid as you can in most cases interface with distributed data store as with asimple hash map.

Being able to work with domain objects directly is one of themain differences between IMDGs and In-Memory Databases (IMDB). With thelatter, users still need to perform Object-To-Relational Mapping which typicallyadds significant performance overhead.There are also some other features in IMDGs that distinguish them from otherproducts, such as NoSql databases, IMDBs, or NewSql databases. One of the maindifferences would be truly scalable Data Partitioning across cluster. EssentiallyIMDGs in their purest form can be viewed as distributed hash maps with every keycached on a particular cluster node - the bigger the cluster, the more data you cancache.

The trick to this architecture is to make sure that you collocate yourprocessing with the cluster nodes where data is cached to make sure that all cacheoperations become local and that there is no (or minimal) data movement withinthe cluster. In fact, when using well-designed IMDGs, there should be absolutelyno data movement on stable topologies - the only time when some of the data ismoved is when new nodes join in or some existing nodes leave, hence causingsome data repartitioning within the cluster.The picture below shows a classic IMDG with a key set of {k1, k2, k3} where eachkey belongs to a different node.

The external database component is optional. Ifpresent, then IMDGs will usually automatically read data from the database orwrite data to it.Another distinguishing characteristic of IMDGs is Transactional ACID support.Generally a 2-phase-commit (2PC) protocol is used to ensure data consistencywithin cluster. Different IMDGs will have different underlying lockingmechanisms, but usually more advanced implementations will provide concurrentlocking mechanisms (like MVCC - multi-version concurrency control) and reducenetwork chattiness to a minimum, hence guaranteeing transactional ACIDconsistency with very high performance.Data consistency is one of the main differences between IMDGs and NoSQLdatabases. NoSQL databases are usually designed on top of Eventual Consistency(EC) approach where data is allowed to be inconsistent for a period of time as longas it will become consistent *eventually*.

Generally, the writes on EC-basedsystems are somewhat fast, but reads are slow (or to be more precise, as fast aswrites are). Latest IMDGs with an *optimized* 2PC should at least match if notoutperform EC-based systems on writes, and be significantly faster on reads. It isinteresting to note that the industry has made a full circle moving from a then-slow2PC approach to the EC approach, and now from EC to an *optimized* 2PC whichoften is significantly faster.Different products provide different 2PC optimizations, but generally the purposeof all optimizations is to increase concurrency, minimize network overhead, andreduce the number of locks a transaction requires to complete.

As an example,Google's distributed global database, Spanner, is based on a transactional 2PCapproach simply because 2PC provided a faster and more straightforward way toguarantee data consistency and high throughput compared to MapReduce or EC.Even though IMDGs usually share some common basic functionality, there aremany features and implementation details that are different between vendors.When evaluating an IMDG product pay attention to eviction policies, (pre)loadingtechniques, concurrent repartitioning, memory overhead, etc... Also pay attentionto the ability to query data at runtime.

Some IMDGs, such as GridGain forexample, allow users to query in-memory data using standard SQL, includingsupport for distributed joins, which is pretty rare.The typical use for IMDGs is to partition data across the cluster and then sendcollocated computations to the nodes where the data is.

Since computations areusually part of Compute Grids and have to be properly deployed, load-balanced,failed-over, or scheduled, the integration between Compute Grids and IMDGs isvery important. It is especially beneficial if both In-Memory Compute and DataGrids are part of the same product and utilize the same APIs, which removes theneed of integration and usually renders utmost performing and reliable systems.IMDGs (together with Compute Grids) are used throughout a wide spectrum ofindustries in applications as diverse as Risk Analytics, Trading Systems, BioInformatics, eCommerce, or Online Gaming.

Essentially every project thatstruggles with scalability and performance can benefit from In-Memory Processingand IMDG architecture..