You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ignite.apache.org by dm...@apache.org on 2020/02/24 21:28:47 UTC
svn commit: r1874471 - in /ignite/site/branches/ignite-redisign/use-cases:
datagrid.html in-memory-database.html
Author: dmagda
Date: Mon Feb 24 21:28:47 2020
New Revision: 1874471
URL: http://svn.apache.org/viewvc?rev=1874471&view=rev
Log:
edited version of the IMDB page
Modified:
ignite/site/branches/ignite-redisign/use-cases/datagrid.html
ignite/site/branches/ignite-redisign/use-cases/in-memory-database.html
Modified: ignite/site/branches/ignite-redisign/use-cases/datagrid.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/use-cases/datagrid.html?rev=1874471&r1=1874470&r2=1874471&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/use-cases/datagrid.html (original)
+++ ignite/site/branches/ignite-redisign/use-cases/datagrid.html Mon Feb 24 21:28:47 2020
@@ -113,7 +113,7 @@ under the License.
<div class="page-heading">Ignite Native Persistence</div>
<p>
Ignite native persistence is a distributed ACID and SQL-compliant disk store that transparently
- integrates with Ignite in-memory layer. When native persistence is enabled, Ignite stores both
+ integrates with Ignite in-memory layer. When the native persistence is enabled, Ignite stores both
data and indexes on disk and eliminates the time-consuming cache warm-up step. Since the
native persistence always keeps a full copy of data on disk, you are free to cache a subset of
records in memory. If a required data record is missing in memory, then Ignite reads it from the
Modified: ignite/site/branches/ignite-redisign/use-cases/in-memory-database.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/use-cases/in-memory-database.html?rev=1874471&r1=1874470&r2=1874471&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/use-cases/in-memory-database.html (original)
+++ ignite/site/branches/ignite-redisign/use-cases/in-memory-database.html Mon Feb 24 21:28:47 2020
@@ -38,8 +38,9 @@ under the License.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description"
- content="Apache Ignite, as an In-Memory Database, is a high-performant system-of-records that is capable of
- storing and querying much larger data sets from disk with no need for memory warm-ups on restarts."/>
+ content="Apache Ignite, as an in-memory database, is a high-performant system-of-records that is capable of
+ storing and querying large data sets from memory as well as disk without requiring to warm up the in-memory
+ caches on cluster restarts."/>
<title>In-Memory Database - Apache Ignite</title>
@@ -58,13 +59,13 @@ under the License.
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-left:0; padding-right:0">
<p>
Apache Ignite, as an in-memory database, is a high-performant system-of-records that is capable
- of storing and querying much larger data sets from disk with no need for memory warm-ups on
- restarts.
+ of storing and querying large data sets from memory as well as disk without requiring to warm up
+ the in-memory caches on cluster restarts.
</p>
<p>
- That's a distributed database that scales horizontally across memory and disk tiers and supports
- ACID transactions, ANSI SQL, key-value, compute, machine learning, and other data processing
- APIs.
+ Ignite serves as a distributed database that scales horizontally across memory and disk tiers
+ and supports ACID transactions, ANSI SQL, key-value, compute, machine learning, and other data
+ processing APIs.
</p>
</div>
<div class="col-sm-6 col-md-5 col-xs-12" style="padding-right:0">
@@ -75,59 +76,59 @@ under the License.
<div class="page-heading">Memory-Centric Architecture</div>
<p>
Apache Ignite memory management system is memory-centric in the sense that most of the processing takes
- place in-memory on cached data with a superset of data persisted to disk. Such an architecture lets
- combine advantages of in-memory computing with the disk durability and strong consistency in one system.
+ place in memory on cached data with a superset of data persisted to disk. Such architecture lets you
+ combine the advantages of in-memory computing with disk durability and strong consistency in one system.
</p>
<p>
- When the native persistence is enabled, Ignite allows you to control how much memory space is to be
- consumed by Ignite. Depending on the memory space available, Ignite either caches a full data set in
- memory, thus, performing as fast as it can or keeps only the most frequently data there, pulling
- missing records from disk. For instance, if there are 100 records and your memory capacity allows to
- cache only 20 of them, then all 100 will be stored on disk, and only 20 will be cached in memory for
- better performance.
+ When the native persistence is enabled, Ignite allows you to control the amount of memory it should
+ consume. Depending on the memory space available, Ignite either caches the full data set in memory or
+ keeps only the most frequently used data there and retrieves missing records from disk when needed.
+ For instance, if there are 100 records and the memory of your system can accommodate only 20 of them,
+ then all 100 records will be stored on disk and only 20 records will be cached in memory for better
+ performance.
</p>
<p>
- Overall, these are the primary advantages of Ignite memory-centric architecture:
+ The following are the primary advantages of Ignite memory-centric architecture:
</p>
<ul class="page-list" style="margin-bottom: 20px;">
<li>
- Flexible configuration of available memory and disk resources as long as Ignite allows storing a
- superset of data on disk and only the most frequently used subsets in memory.
+ Flexible configuration of available memory and disk resources such that Ignite stores a superset
+ of data on disk and only the most frequently used subsets in memory.
</li>
<li>
- Ignite SQL queries and all other APIs can query both cached data sets as well as other data that
- is kept on disk only.
+ Ignite SQL queries and all other APIs can query both cached data sets as well as data that is kept
+ on disk only.
</li>
<li>
Instantaneous cluster restarts. Ignite becomes fully operational from disk immediately upon cluster
- startup or restarts. There is no need to preload or warm up the in-memory caches.
+ startup or restarts without requiring to preload or warm up the in-memory caches.
</li>
</ul>
<div class="page-heading">Better High-Availability With Instantaneous Cluster Restarts</div>
<p>
- If you enable Ignite native persistence for your deployments, then there is no need to worry about
- time-consuming memory warm-ups on cluster restarts. As long as Ignite persistence always keeps a
- superset of data on disk and treats it as one of the storage layers, Ignite starts reading data from
- the persistence as soon as the cluster becomes active. The memory tier is warmed up in the background
- with the data Ignite accesses on disk for you.
+ Ignite native persistence takes away the trouble of time-consuming memory warm-ups on cluster restarts.
+ Ignite persistence always keeps a superset of data on disk and treats it as one of the storage layers.
+ Hence, Ignite starts reading data from the persistence layer as soon as the cluster becomes active. As
+ you begin to run the queries, the memory tier is warmed up in the background with the data Ignite
+ accesses from the disk.
</p>
<div class="page-heading">Avoiding Network Impact on Performance With Co-located Processing</div>
<p>
- The disk-centric systems, like RDBMS or NoSQL, generally utilize the classic client-server approach,
- when the data is transferred from the server to the client-side where it gets processed and then usually
- discarded. This approach does not scale well as moving the data over the network is the most expensive
- operation in a distributed system.
+ Disk-centric systems, like RDBMS or NoSQL, generally use the classic client-server approach when
+ transferring data from the server to the client-side where it gets processed and then discarded. This
+ approach does not scale very well because moving data over the network is the most expensive operation
+ in a distributed system.
</p>
<p>
- Many distributed databases, including Apache Ignite, support another more scalable approach called
- co-located processing that eliminates or reduces network traffic significantly by running application
- logic right on the cluster nodes. This approach executes data or compute-intensive logic, including
- distributed SQL with JOINs, exactly where the data resides, thus, reducing data shuffling over the network.
+ Many distributed databases, including Apache Ignite, support a more scalable approach called co-located
+ processing, which eliminates or significantly reduces network traffic by running application logic right
+ on the cluster nodes. This approach executes data or compute-intensive queries, including distributed
+ SQL with JOINs, exactly where the data resides.
</p>
<div class="page-heading">Learn More</div>