Apache Ignite is widely used around the world and is growing all the time. Companies like Barclays, Misys, Sberbank (3r largest bank in Europe), ING, JacTravel all use Ignite to power pieces of their architecture that are critical to the day-to-day operations of those organizations. Moreover, the vendor like TIBCO uses core caching data-grid module of Apache Ignite with advanced indexing and SQL capability for their Master Data Management platform.
However there are a few others alternatives to Apache Ignite from other vendors such as HazelCast, Oracle, Ehcache, GemFire, etc. The main difference of Apache Ignite from the others is the number of functionalities and simplicity of use. Apache Ignite provides a variety of functionalities, which you can use for different use cases. The key differences between the Apache Ignite, Hazelcast, and Apache Cassandra are as follows:
From the above table, you can see that unlike other competitors, Apache Ignite provides durable memory architecture (free of charges), server-side scripting (compute grid), a set of components called In-memory Hadoop accelerator and Spark shared RDD that can deliver real-time performance to Hadoop and Spark users. The Apache Ignite is the right choice when you need scalability and high availability with the capability of processing high volume transactions. It is the perfect platform for the mission-critical data on commodity hardware or cloud infrastructure.
Now, let’s compare the Apache Ignite functionalities with another in-memory database named Tarantool. Tarantool is an in-memory database, design by a team led by a former MySQL engineer.
If you carefully study the above table, you can notice that Tarantool doesn’t support SQL and distributed transactions. Even Tarantool doesn’t provide any ORM support for using Hibernate or MyBatis. From the architecture point of view, Tarantool uses Master-Slave replication, which can proceed data loss whenever a master fails.
However there are a few others alternatives to Apache Ignite from other vendors such as HazelCast, Oracle, Ehcache, GemFire, etc. The main difference of Apache Ignite from the others is the number of functionalities and simplicity of use. Apache Ignite provides a variety of functionalities, which you can use for different use cases. The key differences between the Apache Ignite, Hazelcast, and Apache Cassandra are as follows:
| Feature | Apache Ignite | Hazelcast | Apache Cassandra |
|---|---|---|---|
| Data model | Key-value | Key-value | Column family |
| Durability | Yes (WAL and,memory pages) | Yes (not free) | Yes (commit log and,SStable) |
| SQL support | Yes | SQL like query language | No, support SQL like query language |
| Secondary index | Yes | Yes | Yes |
| Big data accelerator | Yes | Yes (not free) | No |
| Transaction | Yes | Yes | CAS – not ACID compliant |
| Use case | Most suitable for read/write-heavy workloads | Most suitable for read/write-heavy workloads | Most suitable for write-heavy workloads |
| Server-side scripting | Yes (compute & service grid) | Yes | No |
| Availability | High | High | High |
| Streaming | Yes | Yes (not free) | No |
| In-memory Map/Reduce | Yes | Yes | No |
From the above table, you can see that unlike other competitors, Apache Ignite provides durable memory architecture (free of charges), server-side scripting (compute grid), a set of components called In-memory Hadoop accelerator and Spark shared RDD that can deliver real-time performance to Hadoop and Spark users. The Apache Ignite is the right choice when you need scalability and high availability with the capability of processing high volume transactions. It is the perfect platform for the mission-critical data on commodity hardware or cloud infrastructure.
Now, let’s compare the Apache Ignite functionalities with another in-memory database named Tarantool. Tarantool is an in-memory database, design by a team led by a former MySQL engineer.
| Feature | Apache Ignite | Tarantool |
|---|---|---|
| Data model | Key-value | Container like |
| Durability | Yes (WAL and memory pages) | Yes (WAL, LSM tree) |
| SQL support | Yes | No |
| Secondary index | Yes | Yes |
| Big data accelerator | Yes | No |
| ORM support | Yes | No |
| Distributed transaction | Yes | No |
| Use case | Most suitable for read/write-heavy workloads | Most suitable for read/write-heavy workloads |
| Server-side scripting | Yes (compute & service grid) | Yes (using programming language Lua) |
| Availability | High | High! Master-slave replication |
| Streaming | Yes | Yes (built-in queues) |
| In-memory Map/Reduce | Yes | Yes |
If you carefully study the above table, you can notice that Tarantool doesn’t support SQL and distributed transactions. Even Tarantool doesn’t provide any ORM support for using Hibernate or MyBatis. From the architecture point of view, Tarantool uses Master-Slave replication, which can proceed data loss whenever a master fails.
Comments