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:
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.
Memory access is so much faster than disk I/O that many of us expect to gain striking performance advantages by merely deploying a distributed in-memory cluster and start reading data from it. However, sometimes we overlook the fact that a network interconnects cluster nodes with our applications, and it can quickly diminish the positive effects of having an in-memory cluster if a lot of data gets transferred continuously over the wire.
With that being said, using proper data access patterns provided by distributed in-memory technologies can negate the effect of the network latency. In this article, we’re using the APIs of Apache Ignite’s in-memory computing platform to see how the performance of our application changes if we put less pressure on the communication channels. The ultimate goal is to be able to deploy horizontally scalable in-memory clusters that can tap into the pool of RAM and CPUs spread across all machines with minimal impact of the network.
