What is Memory-Centric?

- -

- Apache Ignite is a memory-centric data platform that combines the performance and scale of - in-memory computing together with the disk durability and strong consistency in one system. -

-
-
-
-
- - - - - - - - - - - - - - - -
Memory-CentricDisk-Centric
Memory as a Main StorageMemory as Caching Layer
Collocated and Client-Server ProcessingClient-Server Processing
- - - - - - - - - - - - - - - - - - -
Memory-CentricDisk-Centric
Memory as a Main Storage
Collocated and Client-Server Processing
Disk-Centric
Memory as Caching Layer
Client-Server Processing
+
+
+

+ Apache Ignite is a memory-centric data platform that combines the performance and scale of + in-memory computing together with the disk durability and strong consistency in one system. +

+

+ The main difference between the memory-centric approach and the traditional disk-centric approach is that + the memory is treated as a fully functional storage, not just as a caching layer, like most databases do. + For example, Apache Ignite can function in a pure in-memory mode, in which case it can be treated as an + In-Memory Database (IMDB) and In-Memory Data Grid (IMDG) in one. +

-
  +
+
-

- The main difference between the memory-centric approach and the traditional disk-centric approach is that - the memory is treated as a fully functional storage, not just as a caching layer, like most databases do. - For example, Apache Ignite can function in a pure in-memory mode, in which case it can be treated as an - In-Memory Database (IMDB) and In-Memory Data Grid (IMDG) in one. -

+

On the other hand, when persistence is turned on, Ignite begins to function as a memory-centric system where most of the processing happens in memory, but the data and indexes get persisted to disk. The main difference here from the traditional disk-centric RDBMS or NoSQL system is that Ignite is strongly consistent, horizontally scalable, and supports both SQL and key-value processing APIs. -

- -

Collocated vs Client-Server Processing

+
+
+

Collocated vs Client-Server Processing

The disk-centric systems, like RDBMS or NoSQL, generally utilize the classic client-server approach, where the data is brought from the server to the client side where it gets processed and then is usually discarded. Modified: ignite/site/ignite-6036/scss/ignite.scss URL: http://svn.apache.org/viewvc/ignite/site/ignite-6036/scss/ignite.scss?rev=1805682&r1=1805681&r2=1805682&view=diff ============================================================================== --- ignite/site/ignite-6036/scss/ignite.scss (original) +++ ignite/site/ignite-6036/scss/ignite.scss Mon Aug 21 20:56:47 2017 @@ -1808,133 +1808,3 @@ div.square { .wrapper-main-banner { background-color: rgb(0, 0, 0); } - -table.common-table { - border: none !important; - margin-bottom: 20px; - position: relative; - - & > thead > tr { - background: #e50000; - border: 1px solid #e50000; - - & > th { - color: white; - font-size: 20px !important; - font-weight: 400; - border: none !important; - } - & .left { - padding-left: 20px !important; - } - } - - & > tbody { - - & > tr { - border-bottom: 1px solid #d7d7d7; - & > td { - border: none !important; - font-weight: 300; - letter-spacing: 0.2px; - padding-right: 0px !important; - line-height: 1.5em; - - & > p { - margin-top : 8px; - margin-bottom : 8px; - - - @media (max-width: $mobile) { - margin-top : 0px; - margin-right : 5px; - padding-right: 5px; - } - } - - @media (max-width: $mobile) { - white-space: normal !important; - } - } - - & .left { - font-weight: bold; - padding-left: 20px !important; - } - } - - @media (max-width: $mobile) { - border: none !important; - } - } - - @media (max-width: $mobile) { - display: none !important; - } -} - -table.common-table-mobile { - display: none; - @media (max-width: $mobile) { - border: none !important; - padding-bottom: 20px; - position: relative; - - & > thead { - display: block !important; - & > tr { - background: #e50000; - border: 1px solid #e50000; - height: 40px; - & > th { - color: white; - font-size: 20px !important; - font-weight: 400; - border: none !important; - display: block !important; - text-align: center; - padding : 10px !important; - } - - } - } - - & > tbody { - - & > tr { - border-bottom: 1px solid #d7d7d7; - - & > td { - border: none !important; - font-weight: 300; - letter-spacing: 0.2px; - vertical-align: middle; - line-height: 1.5em; - text-align: center; - - & > span { - padding: 0px !important; - } - - & .right { - float: right; - width: 50%; - margin-left: 10px; - } - - & .left { - - } - } - - &.ignite { - background: #eee; - } - } - - @media (max-width: $mobile) { - border: none !important; - } - } - } -} \ No newline at end of file Modified: ignite/site/ignite-6036/whatisignite.html URL: http://svn.apache.org/viewvc/ignite/site/ignite-6036/whatisignite.html?rev=1805682&r1=1805681&r2=1805682&view=diff ============================================================================== --- ignite/site/ignite-6036/whatisignite.html (original) +++ ignite/site/ignite-6036/whatisignite.html Mon Aug 21 20:56:47 2017 @@ -69,71 +69,63 @@ under the License.

-

Is Ignite a distributed database?

+

Is Ignite an in-memory database (IMDB)?

- 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 plugin their own distribution (affinity) functions and collocate various pieces of data together for efficiency. + 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 distributed in-memory database, with strong + support for SQL and distributed joins.



-

Is Ignite a relational SQL database?

-

- 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. -

+

Is Ignite an in-memory data grid (IMDG)?

- 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. 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 databases, + including any RDBMS or NoSQL stores.

-



+



-

Is Ignite an in-memory database?

+

Is Ignite a distributed database?

- 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. + Yes. Data in Ignite is either partitioned or replicated across a cluster of + multiple nodes. This provides scalability and adds resiliency to the system. Ignite automatically + controls how data is partitioned, however, users can plugin their own distribution (affinity) functions + and collocate various pieces of data together for efficiency.



-

Is Ignite a transactional 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. -

- +

Is Ignite an SQL database?

- At SQL level Ignite supports atomic, but not yet transactional consistency. Ignite community plans to implement SQL transactions in version 2.2. + 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.

-



- -

Is Ignite a key-value store?

- Yes. Ignite provides a feature rich key-value API, that is JCache (JSR-107) compliant and supports Java, C++, and .NET. + 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.

-



+



-

Is Ignite an in-memory data grid (IMDG)?

+

Is Ignite a transactional database?

- 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. + 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.

-



-

What is durable memory?

- 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. + At SQL level Ignite supports atomic, but not yet transactional consistency. Ignite community plans + to implement SQL transactions in version 2.3.

-



+



-

What is collocated processing?

+

Is Ignite a key-value store?

- Ignite is a distributed system and, therefore, it is important to be able 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 data locally. + Yes. Ignite provides a feature rich key-value API, that is JCache (JSR-107) compliant + and supports Java, C++, and .NET.

-



+



Book

Learn even more from High-Performance in-memory computing with Apache Ignite book.