Ignite: Version Comparison

Ignite is an in-memory, distributed key-value store which uses a shared-nothing, node-based cluster architecture. It can be used with existing third party databases to improve the overall performance and scalability, and it can also be used in its native persistence.

Ignite is an in-memory, distributed key-value store which uses a shared-nothing, node-based cluster architecture. It can be used with existing third party databases to improve the overall performance and scalability, and it can also be used in its native persistence.

Ignite was originally the proprietary GridGain DBMS for in-memory computing. Then Ignite was donated to Apache Software Foundation as "The Apache Ignite middleware project" and open-sourced by GridGain in late 2014. It was accepted in the Apache Incubator program in the same year. It graduated on September 18, 2015.

Ignite was originally the proprietary GridGain DBMS for in-memory computing. Then Ignite was donated to Apache Software Foundation as "The Apache Ignite middleware project" and open-sourced by GridGain in late 2014. It was accepted in the Apache Incubator program in the same year. It graduated on September 18, 2015.

According to Ignite's confluence page, consistent checkpointing is available in the system.

According to Ignite's confluence page, consistent checkpointing is available in the system.

There is no data compression implemented in ignite now. However, ignite suggests the Index Prefix Compression in its future enhancement plan.

There is no data compression implemented in ignite now. However, ignite suggests the Index Prefix Compression in its future enhancement plan.

According to Ignite's documentation v2.7.6, Multi-version concurrency control is available from Ignite version 2.7. In MVCC, a logical snapshot of data is created for each transaction. The snapshot is consistent throughout the transaction and the transaction can only view and modify data in this snapshot. For example, if an entry is read by transaction A and updated by transaction B when transaction A tries to update the entry again, an exception will be thrown and transaction A will need to be retried.

According to Ignite's documentation v2.7.6, Multi-version concurrency control is available from Ignite version 2.7. In MVCC, a logical snapshot of data is created for each transaction. The snapshot is consistent throughout the transaction and the transaction can only view and modify data in this snapshot. For example, if an entry is read by transaction A and updated by transaction B when transaction A tries to update the entry again, an exception will be thrown and transaction A will need to be retried.

Ignite uses a key-value store. And Ignite determines the location of the data using a pluggable hashing algorithm. It means every client can determine where the value is stored by plugging the key into a hashing function.

Ignite uses a key-value store. And Ignite determines the location of the data using a pluggable hashing algorithm. It means every client can determine where the value is stored by plugging the key into a hashing function.

Ignite does not support foreign key constraints.

Ignite does not support foreign key constraints.

Ignite uses B+tree data structures to store regular indexes. Ignite supports primary and secondary indexes, but it will only enforce the uniqueness of primary indexes.

Ignite uses B+tree data structures to store regular indexes. Ignite supports primary and secondary indexes, but it will only enforce the uniqueness of primary indexes.

According to Ignite's official documentation, the following three isolation levels are supported: read committed, repeatable read, and serializable.

According to Ignite's official documentation, the following three isolation levels are supported: read committed, repeatable read, and serializable.

Ignite uses a write-ahead log which logs logical database modifications and page changes.

Ignite uses a write-ahead log which logs logical database modifications and page changes.

It supports distributed collocated processing, where the operation can be distributed to each node.

It supports distributed collocated processing, where the operation can be distributed to each node.

According to Ignite's official documentation, the support of following syntaxes of SQL are available in Ignite: Data Definition Language (e.g. CREATE INDEX, CREATE TABLE), Data Manipulation Language (e.g. SELECT, INSERT, UPDATE), Aggregate Functions (e.g. AVG, MAX, MIN, SUM), Numeric Functions (e.g. ABS, SIN, COS), String Functions (e.g. CONCAT, LOWER, UPPER), Date and Time Functions (e.g. DATEDIFF), System Functions (e.g. COALESCE, DECODE, GREATEST, IFNULL) and Data Types (e.g. BOOLEAN, INT, TINYINT, SMALLINT).

According to Ignite's official documentation, the support of following syntaxes of SQL are available in Ignite: Data Definition Language (e.g. CREATE INDEX, CREATE TABLE), Data Manipulation Language (e.g. SELECT, INSERT, UPDATE), Aggregate Functions (e.g. AVG, MAX, MIN, SUM), Numeric Functions (e.g. ABS, SIN, COS), String Functions (e.g. CONCAT, LOWER, UPPER), Date and Time Functions (e.g. DATEDIFF), System Functions (e.g. COALESCE, DECODE, GREATEST, IFNULL) and Data Types (e.g. BOOLEAN, INT, TINYINT, SMALLINT).

Apache Ignite is an in-memory (or memory-centric) distributed database. But there is a native persistence option in Ignite. If you turned it off, it is a pure in-memory store. When the option is turned on, it stores both data and indexes on disk. In this mode, a subset of data is stored in memory. Additionally, one benefit of this mode is that the indexes don't need to be rebuild when the system restarts since they are persisted on the disk.

Apache Ignite is an in-memory (or memory-centric) distributed database. But there is a native persistence option in Ignite. If you turned it off, it is a pure in-memory store. When the option is turned on, it stores both data and indexes on disk. In this mode, a subset of data is stored in memory. Additionally, one benefit of this mode is that the indexes don't need to be rebuild when the system restarts since they are persisted on the disk.

Ignite used a page-based memory architecture, where memory is split into pages of fixed size. The pages are stored in RAM and are organized in a special hierarchy on disk.

Ignite used a page-based memory architecture, where memory is split into pages of fixed size. The pages are stored in RAM and are organized in a special hierarchy on disk.

Ignite support access to the contents of the result generated by batches and stored procedures.

Ignite support access to the contents of the result generated by batches and stored procedures.

Ignite uses a shared-nothing, node-based cluster architecture. The nodes can automatically discover each other. It supports third-party persistence and native persistence. For third-party persistence, it acts as a in-memory cache on top of a third-party database. For its native persistence, it acts as a in-memory (memory-centric) distributed database. It also supports collocated processing, where the computation on data is done on the node where the data is stored.

Ignite uses a shared-nothing, node-based cluster architecture. The nodes can automatically discover each other. It supports third-party persistence and native persistence. For third-party persistence, it acts as a in-memory cache on top of a third-party database. For its native persistence, it acts as a in-memory (memory-centric) distributed database. It also supports collocated processing, where the computation on data is done on the node where the data is stored.

Ignite has some built-in views that contain information about cluster nodes.

Ignite has some built-in views that contain information about cluster nodes.