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>
