Ignite is a memory-centric platform
- combining a distributed SQL database
- with a key-value data grid
- that is ACID-compliant
- and horizontally scalable
Yes. Data in Ignite is either partitioned or replicated across a cluster of multiple nodes. This provides scalability and adds resilience to the system. Ignite automatically controls how data is partitioned, however, users can plug in their own distribution (affinity) functions and collocate various pieces of data together for efficiency.
Not fully. Although Ignite aims to behave like any other relational SQL database, there are differences in how Ignite handles constraints and indexes. Ignite supports primary and secondary indexes, however, the uniqueness can only be enforced for the primary indexes. Ignite also does not support foreign key constraints.
Essentially, Ignite purposely does not support any constraints that would entail a cluster broadcast message for each update and significantly hurt performance and scalability of the system.
Yes. Even though Ignite durable memory works well in-memory and on-disk, the disk persistence can be disabled and Ignite can act as a pure in-memory database.
Not fully. ACID Transactions are supported, but only at key-value API level. Ignite also supports cross-partition transactions, which means that transactions can span keys residing in different partitions on different servers.
At SQL level Ignite supports atomic, but not yet transactional consistency. Ignite community plans to implement SQL transactions in version 2.2.
Yes. Ignite provides a feature rich key-value API, that is JCache (JSR-107) compliant and supports Java, C++, and .NET.
Yes. Ignite is a full-featured data grid, which can be used either in pure in-memory mode or with Ignite native persistence. It can also integrate with any 3rd party database, including any RDBMS or NoSQL store.
Ignite durable memory architecture allows Ignite to extend in-memory computing to disk. It is based on a paged-based off-heap memory allocator which becomes durable by persisting to the write-ahead-log (WAL) and, then, to main Ignite persistent storage. When persistence is disabled, durable memory acts like a pure in-memory storage.
Ignite is a distributed system and, therefore, it is important to be able to collocate data with data and compute with data to avoid distributed data noise. Data collocation becomes especially important when performing distributed SQL joins. Ignite also supports sending user logic (functions, lambdas, etc.) directly to the nodes where the data resides and computing on the data locally.
- Ignite C++ is built on top of Ignite
- Ignite С++ starts the JVM in the same process and communicates with it via JNI
- .NET, C++ and Java nodes can join the same cluster, use the same caches, and interoperate using common binary protocol
- Java compute jobs can execute on any node (Java, .NET, C++)
Learn even more from High-Performance in-memory computing with Apache Ignite book.