Deployment Modes

As a rule of thumb, follow this logic if you are in doubt over which client to use:

Partition awareness allows the thin client to send query requests directly to the node that owns the queried data.

Without partition awareness, an application that is connected to the cluster via a thin client executes all queries and operations via a single server node that acts as a proxy for the incoming requests. These operations are then re-routed to the node that stores the data that is being requested. This results in a bottleneck that could prevent the application from scaling linearly.

Notice how queries must pass through the proxy server node, where they are routed to the correct node.

With partition awareness in place, the thin client can directly route queries and operations to the primary nodes that own the data required for the queries. This eliminates the bottleneck, allowing the application to scale more easily.

When GridGain is used as a caching layer on top of an external storage, such as a relational database, you are dealing with the in-memory data grid (IMDG) use case. In this case, the whole data set is stored in the external database and what fits in memory is loaded there to boost application performance.

As you can see in the figure above, your applications can start treating a GridGain cluster as a primary storage, using the cluster to keep an underlying database in sync. That’s the easiest and least disruptive way to enable in-memory computing for existing solutions - position GridGain between your application and database layers, load data into RAM, and boost performance.

GridGain as an IMDG is different from a simple in-memory cache use case because it allows you to:

When you use GridGain native persistence instead of an external storage, then you are enabling the in-memory database (IMDB) or system of record use case.

In this use case, all of the data is stored on disk and as much as will fit is loaded into RAM. This allows for a much larger data set as data that does not fit in memory is still available. For example, if your data set is large enough that only 10% of it can fit in memory, 100% of the data will be stored on disk and 10% is cached in memory for performance. This configuration, where the data set is stored in bulk on disk, is called GridGain persistence (or native persistence).

This use case provides the following benefits:

In some cases you might have a mixed deployment configuration when GridGain, for instance, caches RDBMs tables with read-only access while the tables are updated via the RDBMs directly and all of the changes should be propagated to the cluster. Or, you might have a GridGain cluster that has a subset of the tables that are persisted in an external database (IMDG mode) while the others are persisted to the native persistence.

Usually heterogeneous deployment modes are used for projects when it’s hard to migrate to a clean IMDG or system of record mode and a transitioning or custom architecture is developed.

Client-Server deployment is the classical and most widely used deployment mode, regardless of your deployment environment (bare-metal, VMs, Kubernetes, etc.). This mode separates the lifecycles of your applications and the GridGain cluster. The applications are deployed, developed, updated, and redeployed independently of the cluster of server nodes. The cluster is deployed once and used as a database/storage and computational platform that is restarted only in the case of rare maintenance events.

Overall, the primary benefits of this standard deployment mode are:

GridGain clients are always embedded into your application code and run as part of the application process. At the same time it’s possible to embed server nodes into the application process. There are two reasons why you would consider this deployment option.

First, this mode can be used for testing. For instance, you can start a Unit test that will launch several server nodes and carry on with testing scenarios by using this local in-process cluster. The Apache Ignite community and GridGain benefit from this deployment mode for functional testing.

Second, the embedded mode is ideal for ultra low-latency use cases like high-performance mission critical applications or electronic trading. The latency has to stay within the 20-100 microseconds range and any operation that involves network communication can easily go beyond the range. Server nodes embedded into your application instances should store a full copy of the data to ensure all of the application calls are local and not directed to other servers over the network.

So, the pros of the embedded mode are that you can easily achieve microseconds SLAs by avoiding network communication between the applications and the cluster as much as possible. There are, however, some cons to this mode for ultra-low latency scenarios: