Ultimate Data Platform
In-Memory Database key innovations:
In-Memory Databases (IMDB) are characterized by the fact that they store their data in-memory as opposed to traditional Database Management Systems that utilize disk as their primary storage mechanism. By utilizing system memory rather than spinning disk, IMDBs are typically orders of magnitude faster than traditional DBMS systems.
Keeping data in memory is not the only reason why IMDBs generally perform faster than disk-based databases. The main reason for performance difference is in the actual architecture. IMDBs are specifically designed with memory-first-disk-second architecture where memory is utilized as a primary storage and disk is secondary storage.
Since memory is a much more limited resource than disk, IMDBs are built from ground up with a notion of horizontal scale and ability to add nodes on demand in real-time. IMDBs are designed to linearly scale to hundreds of nodes with strong semantics for data locality and affinity data routing to reduce redundant data noise.
Disk based databases, on the other hand, are designed with disk-first-memory-second architecture and are primarily optimized for disk-based accessed. Since disk capacity is virtually unlimited when compared to memory, most disk-based systems can often hold the whole or most of the data set and are rarely designed to horizontally scale simply because there is no need for it from data storage standpoint. Such architecture makes disk based systems much less suited for parallel processing and often results in database overloading and thrashing.
Ability to collocate computations with the data makes IMDBs much more suited for parallel in-memory processing than traditional disk-based systems.
One of distinguishing features for most IMDBs is the way data replication is supported. There are several common approaches here ranging from no replication at all to full replication where every node sees absolutely identical data set. Perhaps the most interesting approach is the partitioned approach where each node gets a chunk of data it is responsible for.
Systems that support this approach are usually most scalable as with addition of more nodes in the cluster the more data can be stored in memory. However, what makes an IMDB a powerful solution is not efficient support for some replication mode, but ability to use different replication modes together on different data sets within the same application, and ability to easily cross-query between these data sets in real-time.
GridGain IMDB supports local, replicated, and partitioned data sets and allows to freely cross query between these data sets using standard SQL syntax.
Another important characteristic of an IMDB system is data querying and search features of the provided query language. Most IMDBs will provide access to the data by primary key. Much fewer systems will provide a custom expressive query language for richer data querying capabilities. Very few systems will allow to use standard SQL for data querying. Systems which allow for execution of distributed joins on the data are usually the most rare. Ability to execute standard SQL joins in distributed environment is usually one of the hardest features to support, but when done right, provides most elegant and efficient way for accessing data.
GridGain In-Memory Database product supports standard SQL for querying in-memory data including support for distributed SQL joins.
GridGain IMDB has extremely rich feature set. Here’s some of the basic features it provides:
One of the most unique characteristics of GridGain IMDB is the full integration of In-Memory HPC at the core of the database.
Many traditional RDBMS and No/NewSQL databases only address data storage and rudimentary data processing. In this scenario the data is retrieved from the database and has to be moved to some other processing node. Once data is processed, it is usually discarded.Such data movement between different layers, even minimal, is almost always at the core of the scalability and performance problems in highly distributed systems.
GridGain IMDB was designed from the ground up to minimize unnecessary data movements and instead move computations to the data whenever possible – hence its integration of HPC technology is at the very core of the database. Computations are dramatically smaller in size – often by factor of 1000x, they don’t change as often as the data, have strong and easily defined affinity to the data they require, and typically provide only negligible load on network and JVMs.
GridGain IMDB supports MapReduce, distributed SQL, MPP, MPI, RPC, File System, and Document API type of data processing and querying – the deepest and the widest eco-system of HPC processing paradigms provided by any database or HPC framework.
GridGain IMDB is first and foremost based on Java which is an OOP language – so all the GridGain APIs work very well with standard OOP principles. However, you will quickly discover that even when working with Java APIs you are often dealing with functional constructs, like closures or predicates, even though Java is not a functional language. This is one of the unique sides of GridGain IMDBand it leads to extremely elegant and simple to use APIs.
GridGain IMDB provides Functional Programming (FP) APIs for most of the in-memory database operations such as cache projections, predicate-based operations, etc.
Individual caches within database can be configured in different such as LOCAL, REPLICATED, and PARTITIONED. In-memory database can have unlimited number of individual caches and each can be configured differently.
Local mode is the most light weight mode of cache operation, as no data is distributed to other cache nodes. It is ideal for scenarios where data is either read-only, or can be periodically refreshed at some expiration frequency. It also works very well with read-through behavior where data is loaded from persistent storage on misses. Other than distribution, local caches still have all the features of distributed cache, such as automatic data eviction, expiration, disk swapping, data querying, transactions, and more.
Replicated mode provides the utmost availability as data is available on every grid node. However, in this mode every data update must be propagated to all other nodes which can have an impact on performance and scalability. As the same data is stored on all grid nodes, the size of replicated cache is limited by the amount of memory available on a node. This mode is ideal for scenarios where updates are infrequent and data availability is most important.
Partitioned cache is the most scalable distributed cache mode. In this mode the overall data set is divided equally into partitions and all partitions are split equally between participating nodes, essentially creating one huge distributed memory for caching data. This approach allows for storing as much data as can be fit in the total memory available across all nodes, hence allowing for loading gigabytes and terabytes of data into cache memory. Partitioned cache is always fronted by a smaller local cache, also known as Near cache, which stores most recently or most frequently accessed data. Such combination provides for high availability of data that is accessed often together with high scalability of partitioned cache. This mode is ideal for scenarios where data volumes are large and updates are relatively frequent.
GridGain IMDB concurrency is based on advanced implementation of MVCC (MultiVersion Concurrency Control) – the same technology used by practically all database management systems. MVCC provides practically lock free concurrency management by maintaining multiple version of data instead of wide-scope locks.
HyperLocking is one of the main ways to improve performance of GridGain IMDB 2-phase-commit (2PC) transactions. When HyperLocking™ is used, only one lock per transaction is acquired even though a transaction may be modifying 1000s of cache entries. Hyperlocking™ can provide an up to 100x performance boost over standard 2PC approach.
Off-Heap overflow provides a mechanism in grid by which grid cache or any other component can store data outside of JVM heap (i.e. in off-heap memory). By allocating data off-heap, JVM GC does not know about it and hence does not slow down. In fact you can start your Java application with a relatively small heap, e.g. below 512M, and then let GridGain IMDB utilize 100s of Gigabytes of memory as off-heap data cache. Whenever data is first accessed, it gets cached in on-heap memory. Then, after certain period of non-use, it gets placed into off-heap memory cache. If your off-heap memory gets full, the least used data will be optionally evicted to disk-overflow-store, also called swap store. Data indexes can be optionally stored off-heap as well to ensure fast query execution on large data sets.
Swap storage provides a mechanism in database by which database can store data outside of JVM heap (i.e. on disk) and retrieve it later. GridGain IMDB cache uses swap space to overflow data if it cannot fit it in memory.
Combination of on-heap, off-heap memory utilization as well as local swap space and remote cache storage defined GridGain’s Tiered Storage Model where each layer provides more capacity but progressively hight latencies. User can configure how GridGain stores and move data between these tiers for optimal performance:
For JEE environments like application servers GridGain IMDB provides automatic integration with JTA/XA. Essentially GridGain IMDB becomes an XA resource and will automatically check if there is an active JTA transaction present. If it is, then GridGain transaction will automatically join JTA transaction, if there is no active JTA transaction, then GridGain IMDB transaction will complete on its own. Such transparent integration with JTA/XA allows users to use the same GridGain IMDB APIs regardless of the environment GridGain IMDB is running in.
GridGain IMDB offers an option to perform asynchronous storage update also known as write-behind. The key concept of this approach is to add a persist request to the queue and postpone data persistence to a certain point in future mainly to improve performance and release load on the underlying persistent storage, like database.
GridGain IMDB directly supports caching web sessions of all Java Servlet containers that follow Java Servlet Specification 3.0, including Apache Tomcat, Eclipse Jetty, IBM WebSphere, and others. Web sessions caching becomes useful when running a clustered web applications in a servlet container. Web session caching in IMDB allows to easily solve session fault tolerance in case of cluster node failure.
GridGain IMDB web sessions cache is a distributed cache that maintains a copy of each created session, sharing them between all instances. If any of your application instances fails, GridGain IMDB will automatically restore the sessions, owned by the failed instance, from the distributed cache regardless of which app server the next request will be forwarded to. Moreover, with web session caching sticky connections become less important as the session is available on any app server the web request may be routed to.
GridGain IMDB has full support for distributed transactions which span data cached on local and remote nodes. While automatic enlisting into JEE/JTA transactions is supported, GridGain in-memory database also allows users to create more light-weight cache transactions which are often more convenient to use. GridGain IMDB cache transactions support all ACID properties that you would expect from any transaction, including support for Optimistic and Pessimistic concurrency levels and READ_COMMITTED, REPEATABLE_READ, and SERIALIZABLE isolation levels. if a persistent data store is configured, then in-memory database transaction will also span the data store, i.e. the cache transaction will either succeed as as a whole if data store transaction succeeded, and will fail as a whole if data store transaction failed.
In addition to transactions where GridGain IMDB allows to execute multiple data operations atomically, GridGain IMDB also supports single atomic CAS (compare-and-set) operations, such as
Distributed caches are often used in conjunction with an external data store, such as a database or a file system. Providing proper cache store implementation is important whenever read-through or write-through behavior is desired. Read-through means that data will be read from persistent store whenever it’s not available in cache, and write-through means that data will be automatically persisted whenever it is updated in cache. Whenever asynchronous data store updates are required for better performance, GridGain IMDB also supports write-behind mode where data updates are accumulated and then get flushed to underlying data store as a bulk operation.
Partitioned cache support active backup copies. This feature allows reads from cache to be actively distributed across replicas/backup nodes leading to much better scalability for read operations. Active replicas are extremely important in read-mostly partitioned caches under the load – where this design can achieve significant performance increase without any extra configuration or user coding.
GridGain IMDB supports remote client connectivity via direct TCP connectivity as well as REST protocol over HTTP. It comes in handy whenever GridGain IMDB Java API is not available directly, but it is still needed to execute GridGain tasks or retrieve cached data. GridGain remote client protocol is compatible with Memcached protocol, so you can take any Memcached remote client and use it perform data-related operations over GridGain grid.
GridGain IMDB provides advanced capabilities for affinity co-location: from a simple single-method call to sophisticated APIs supporting complex affinity keys and non-trivial topologies.
Determining proper partitioning strategy is extremely important, especially when it comes to equal data and equal load distribution within grid. By default GridGain IMDB utilizes multi-level consistent hashing to provide efficient fault-tolerant data partitioning. GridGain IMDB also provides various ways to customize partitioning by collocating data with data and computations with data. However, for more advanced cases, you can override the partitioning function altogether and provide your own.
For every synchronous computation (e.g. MapReduce task) on compute grid and for every synchronous cache operation there is an asynchronous counter part. In distributed systems I/O may become an overhead and ability not to wait for results synchronously adds abilities to execute multiple operations in parallel and react to responses as they begin to come in. All GridGain IMDB asynchronous operations allow attaching listeners to them just so result notifications are also asynchronous.
Regardless of which cache mode is used, REPLICATED or PARTITIONED, whenever cached data changes the new state needs to be propagated to some remote cached nodes. By default the new state will be moved to remote node which requires sending the whole new state across. However, whenever new state is too large, or whenever it is OK to load state on demand on remote nodes, you can configure caches to work in Invalidation mode in which case only small invalidation messages will be sent across.
Transparent integration with persistent data stores is extremely important and GridGain IMDB provides a simple API to allow automatic read-through and write-through behavior. Read-through means that data will be read from persistent store whenever it’s not available in cache, and write-through means that data will be automatically persisted whenever it is updated in cache.
Preloading newly started cache nodes is important whenever it is necessary to have common data set in memory on all nodes. When preloading is enabled, distributed caches will attempt to preload all necessary values from other grid nodes. GridGain IMDB has significant optimizations to ensure that cache preloading is absolutely concurrent and imposes no overhead over normal cache performance. GridGain IMDB supports synchronous and asynchronous preloading modes.
Whenever a new node joins the grid or an existing node leaves the grid, cluster repartitioning happens. This basically means that, in case of new node joining, it has to take responsibility for some of the data cached on other nodes, and in case of node leaving the grid, other nodes have to take responsibility for the data cached on that node. Essentially this results in data movement between in-memory database nodes. Whenever starting or stoping multiple nodes together it is often better to delay preloading without violating cache consistency, just so it happens once instead of multiple times.
GridGain IMDB provides LRU, LFU, FIFO, LIRS, time based, and random expiration policies out of the box. What is unique about GridGain IMDB is that it provides you an ability to plug any other custom-made eviction policy. Eviction policies are essential in distributed caches as they provide the means of managing the size of the caches on individual nodes.
Have you ever wish you could take a data structure you are familiar with and use it in clustered grid-enabled fashion? For example, why not take
java.util.concurrent.BlockingDeque and add something to it on one node and poll it from another node? Or why not have a distributed primary key generator which would guarantee uniqueness on all nodes? Or how about a distributed
java.util.concurrent.atomic.AtomicLong which can be updated and read from any node on the grid? GridGain IMDB gives you such capability. What GridGain IMDB did is actually take most of the data structures from
java.util.concurrent framework and made sure they could be used in distributed fashion.
Indexing functionality in GridGain IMDB allows for creation of in-memory indexes of various pieces of cached data so it can be efficiently used in data queries. GridGain IMDB default indexing implementation is based on SQL engine, which gives our users fully ANSI compliant SQL queries for in-memory data. For its indexing GridGain supports unique constraints, ordered and unordered indexes, compound secondary indexes, and also text indexing based on Apache Lucene or H2Text.
GridGain IMDB supports a variety of different ways to query in-memory data, including standard SQL-based queries, Lucene-based text queries, or plain full-scan queries whenever needed. In-Memory Database also ships with JDBC driver.
In addition to supporting standard SQL for querying cached data, GridGain IMDB also allows users to define custom SQL functions to be used inside of SQL queries. Such functions may become handy when you find yourself commonly needing to query a certain average or concatenate various values in a certain way. For such cases, you can define your custom logic in Java or Scala and then tell GridGain IMDB that you plan to use it in SQL queries.
When working with multiple data centers it is often important to make sure that if one data center goes down, another data center is fully capable of picking its load and data. Data center replication is meant to solve exactly this problem. When data center replication is turned on, GridGain IMDB will automatically make sure that each data center is consistently backing up its data to other data centers (there can be one ore more). GridGain IMDB supports both active-active and active-passive modes for replication.
GridGain IMDB provides direct support for Continuous Queries. Continuous query registered once and get called back on database updates. On each update it can perform various operations and decides whether or not to continue listen for database updates. Continuous queries are very useful for cases where we want to know all cache updates that will happen in the future and subsequently fall into our query results.
GridGain IMDB, as any other GridGain product, comes with a comprehensive and unified GUI-based management and monitoring tool called GridGain Visor. It provides deep operations, management and monitoring capabilities.
A starting point of the Visor management console is the Dashboard tab which provides an overview on grid topology, many relevant graphs and metrics, as well as event panel displaying all relevant grid events:
￼To manage and monitor the database you can select the Database Tab which will display detailed information about the GridGain IMDB:
You can also manage and monitor individual caches comprising a IMDB:
Click here for more information about Visor.