Posted on

Coordinating an Apache Ignite Cluster With GridGain Control Center

Bundling various data sources, APIs, services, applications, and several data streams while managing application data integration can become cumbersome. It’s so complex that it typically results in application performance loss. So, database administrators use Apache Ignite, a distributed database that provides high-performance computing capabilities using in-memory speed. Integrating Apache Ignite as an in-memory caching or distributed database solution helps improve the velocity and performance of complex architecture.

But, at the same time, this solution presents new challenges: we’re integrating yet another component into our already complex architecture. GridGain provides a solution to this challenge enabling monitoring, managing, and troubleshooting Apache Ignite clustered environments, whether they’re running as an on-premises solution or as a SaaS offering in the cloud. 

Posted on

Why My In-Memory Cluster Underperforms: Negating Network Impact

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. 

Posted on

A Simple Checklist for Apache Ignite Beginners

If you are running Apache Ignite for the first time, you might face some difficulties. You have just downloaded Apache Ignite, run it a few times, and got some issues. Mostly, these problems are solved in a similar fashion. Therefore, I decided to create a checklist, which provides recommendations to help you avoid issues in the development environments.

1. Configuration Files

When Ignite starts in standalone mode by executing the ignite.sh|bat  file, Ignite uses the $IGNITE_HOME/config/default-config.xml configuration file. In this situation, to connect to the specified node from the Visor command line console, you should choose the default-config.xml file from the configuration file list. Most of the time, the default- config.xml file is the first file in the list.

Posted on

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.