Exploring Four Unique Key Generation Strategies in GridGain and Apache Ignite

Some databases have a feature where a column can be “autoincremented.” In this piece, we’ll explain why GridGain and Apache Ignite do not and what you can do to get equivalent functionality.

The naming varies, but the concept is straightforward: the system automatically generates a key for you if there is no unique business key for a table. Typically, this would be a numeric column, and the data would increase the value by one every time you insert a new record. MySQL and MariaDB have specific SQL syntax for “AUTO_INCREMENT.” SQL Server has a special data type called IDENTITY. Oracle used to make you use a sequence and a trigger, but it has made it a bit easier in recent years.

Developing Spring Boot Applications with In-Memory Database

I am a big fan of in-memory computing and Apache Ignite is one my favorite platform for developing high-performance backend applications. Recently, the Apache Ignite team announced a new extension for developing a Spring Boot application with the Ignite database. The full documentation of the extension is available here

The main purpose of the extension is to integrate Ignite into Spring Boot application with minimal configuration. This autoconfigure module serves in two different flavors:

Introducing Apache Ignite New Subsystems for Metrics and Monitoring

Apache Ignite as a distributed database and caching platform needs end-to-end monitoring to act on time. Historically, Apache Ignite provides a set of API and instrumentation to gather application-specific information and metrics by the external tools. In release 2.8.0, Apache Ignite improved the monitoring capabilities and introduced some nice features like "System views subsystem" and "Metrics subsystem."

In this short article, we are going to explore the Apache Ignite new monitoring opportunities and how to use different tools and technics to gather metrics for diagnosis. Anyway, the full release notes of version 2.8.0 can be found here.

Using Apache Ignite Thin Client

From the version 2.4.0, Apache Ignite introduced a new way to connect to the Ignite cluster, which allows communication with the Ignite cluster without starting an Ignite client node. Historically, Apache Ignite provides two notions of client and server nodes. Ignite client node is intended as lightweight mode, which does not store data (however, it can store near cache) and does not execute any compute tasks. Mainly, the client node is used to communicate with the server remotely and allows manipulating the Ignite Caches using the whole set of Ignite API’s. There are two main downsides with the Ignite Client node:

  • Whenever Ignite client node connects to the Ignite cluster, it becomes the part of the cluster topology. The bigger the topology is, the harder it is for maintaining.
  • In the client mode, Apache Ignite node consumes a lot of resources for performing cache operations

To solve the above problems, Apache Ignite provides a new binary client protocol for implementing thin Ignite client in any programming language or platforms.