updated multi-tier, persistence and sql pages
git-svn-id: https://svn.apache.org/repos/asf/ignite/site/branches/ignite-redisign@1874912 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/arch/multi-tier-storage.html b/arch/multi-tier-storage.html
index 277de99..241a858 100644
--- a/arch/multi-tier-storage.html
+++ b/arch/multi-tier-storage.html
@@ -43,8 +43,9 @@
<title>Multi-Tier Storage - Apache Ignite</title>
<meta name="description"
- content="Apache Ignite multi-tier storage uses memory, disk and Intel® Optane™ as active storage tiers. Speed of
- memory with the consistency of disk-based databases and no need for memory warm-ups on restarts."/>
+ content="Apache Ignite multi-tier storage uses memory, disk, and Intel® Optane™ as active storage tiers to
+ provide the speed of memory with the consistency of disk-based databases without the need for memory
+ warm-ups on restarts."/>
<!--#include virtual="/includes/styles.html" -->
@@ -60,12 +61,11 @@
<div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-left:0; padding-right:0">
<p>
- Apache Ignite is designed to work with memory, disk and Intel® Optane™ as active storage tiers.
- The memory tier allows to use DRAM and Intel® Optane™ operating in the Memory Mode for data
- storage and processing needs.
- The disk tier is optional with the support of two options -- you can persist data in an
- external database or keep it in the Ignite native persistence. SSD, Flash, HDD or Intel®
- Optane™ operating in the AppDirect Mode can be used as a storage device.
+ Apache Ignite is designed to work with memory, disk, and Intel® Optane™ as active storage tiers.
+ The memory tier allows using DRAM and Intel® Optane™ operating in the Memory Mode for data storage
+ and processing needs. The disk tier is optional with the support of two options -- you can
+ persist data in an external database or keep it in the Ignite native persistence. SSD, Flash,
+ HDD, or Intel® Optane™ operating in the AppDirect Mode can be used as a storage device.
</p>
</div>
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-right:0">
@@ -75,26 +75,23 @@
<p>
Ignite takes full control of its memory tier by allocating and managing off-heap regions. Each Ignite
server node allocates memory regions during bootstrap, splits the regions into pages, and keeps data
- records with indexes there. Java heap is used to keep temporary objects such as queries results sets,
- metrics samples, objects generated by your application code. All these objects are garbage collected
- eventually.
+ records with indexes in those pages. Java heap is used to keep temporary objects such as query result
+ sets, metrics samples, and objects generated by your application code. All these objects are garbage
+ collected eventually.
</p>
<p>
- If you select the native persistence as the disk tier, then most of the processing will still
- take place in memory on cached data, but, with a full copy stored on disk. If any record is
- missing in memory, Ignite will read it from disk, allowing you to persist much larger data sets
- than you can cache in memory. That also eliminates the need for time-consuming memory warm-ups
- on restarts. As soon as your cluster reconnects after a restart, Ignite will serve most of the
- data from disk warming the memory tier up in the background.
+ If you select the native persistence as the disk tier, then most of the processing will still take place
+ in memory on cached data, but, with a full copy stored on disk. If any record is missing in memory,
+ Ignite will read it from disk, allowing you to persist much larger data sets than you can cache in memory.
+ This also eliminates the need for time-consuming memory warm-ups on restarts. As soon as your cluster
+ reconnects after a restart, Ignite will serve most of the data from disk warming up the memory tier in
+ the background.
</p>
<div class="page-heading" id="storage-usage-modes">
Multi-Tier Storage Usage Modes
<a href="/arch/multi-tier-storage.html#storage-usage-modes"><i class="fa fa-anchor"></i></a>
</div>
- <p>
- Below you can see primary modes for multi-tier storage usage and configuration:
- </p>
<table class="formatted" name="Deployment Options Features">
<thead>
<tr>
@@ -107,9 +104,9 @@
<td class="left">In-Memory</td>
<td>
<p>
- The whole data set is available in memory only. In order to survive node failures, it is
- recommended to keep at least one backup copy of the data across the cluster. DRAM or Intel®
- Optane™ operating in the Memory Mode can be used as a storage device.
+ The whole data set is available in memory only. In order to survive node failures, we
+ recommend keeping at least one backup copy of the data across the cluster. DRAM or
+ Intel® Optane™ operating in the Memory Mode can be used as a storage device.
</p>
<p>
@@ -123,13 +120,13 @@
<td>
<p>
Ignite is deployed as a distributed caching layer on top of an existing external database.
- This mode is for the acceleration of disk-based databases and your services with APIs that
+ This mode is for accelerating disk-based databases and your services with APIs that
interact with them.
</p>
<p>
- <strong>Use cases</strong>: acceleration of services and APIs with write-through/behind
- capability, to an external database (aka. in-memory data grid).
+ <strong>Use cases</strong>: acceleration of services and APIs with write-through and
+ write-behind capability, to an external database.
</p>
</td>
</tr>
@@ -137,11 +134,11 @@
<td class="left">In-Memory Cache + Native Persistence</td>
<td>
<p>
- 100% of data is persisted to disk, and the same or smaller amount is cached in memory.
- The more data is cached, the faster is the performance. The disk serves as the primary
- storage that survives any cluster failures and restarts. No need for memory warm-ups on
- restarts as long as Ignite can serve data from disk. SSD, Flash, HDD or Intel®
- Optane™ operating in the AppDirect Mode can be used as a storage device.
+ 100% of data is persisted to disk, and the same or smaller amount is cached in memory. The
+ more data is cached, the faster is the performance. The disk serves as the primary storage
+ that survives any cluster failures and restarts. There is no need for memory warm-ups on
+ restarts since Ignite can serve data from disk. SSD, Flash, HDD or Intel® Optane™ operating
+ in the AppDirect Mode can be used as a storage device.
</p>
<p>
@@ -158,10 +155,10 @@
<a href="/arch/multi-tier-storage.html#partitioning"><i class="fa fa-anchor"></i></a>
</h2>
<p>
- Depending on the configuration, Ignite can both partition or replicate data across the cluster. With
- the replicated mode, each cluster node keeps a full copy of the data that is advantageous
- for frequently accessed dictionaries. As for the partitioned mode, Ignite spreads the data across all
- the cluster nodes evenly, allowing to store much more than a single machine can fit in.
+ Depending on the configuration, Ignite can both partition or replicate data across the cluster. In the
+ replicated mode, each cluster node keeps a full copy of the data, but the size of a replicated cache is
+ limited by the amount of memory available on the node. In the partitioned mode, Ignite spreads the data
+ across all the cluster nodes evenly, allowing you to store much more than what can fit in a single machine.
</p>
<h2 style="padding-top: 10px;" id="durability">
@@ -169,7 +166,7 @@
<a href="/arch/multi-tier-storage.html#durability"><i class="fa fa-anchor"></i></a>
</h2>
<p>
- Ignite provides strong ACID durability guarantees to the data:
+ Ignite provides the following ACID guarantees across the cluster:
</p>
<ul class="page-list" style="margin-bottom: 20px;">
@@ -186,15 +183,14 @@
</h2>
<p>
If Ignite native persistence is selected as a disk tier, then every time a record is updated in memory,
- the change is added to the write-ahead log (WAL). The purpose of the WAL is to propagate updates to
- disk in the fastest way possible and provide a consistent recovery mechanism that supports full cluster
- failures.
+ the change is added to the write-ahead log (WAL). The purpose of the WAL is to propagate updates to disk
+ in the fastest way possible and provide a consistent recovery mechanism that supports full cluster failures.
</p>
<p>
As WAL grows, it periodically gets checkpointed to the main storage. Checkpointing is the process of
copying dirty pages from the memory tier to the partition files on disk. A dirty page is a page that was
- updated in memory, was appended to WAL, but was not written to a respective partition file on disk yet.
+ updated in memory, was appended to WAL, but was not written to the respective partition file on disk yet.
</p>
<div class="page-heading">Learn More</div>
diff --git a/arch/persistence.html b/arch/persistence.html
index 922c97d..e5e8ab6 100644
--- a/arch/persistence.html
+++ b/arch/persistence.html
@@ -61,20 +61,17 @@
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-left:0; padding-right:0;">
<p>
Even though Apache Ignite is broadly used as a caching layer on top of external databases, it
- comes with its native persistence that is a distributed, ACID, and SQL-compliant disk-based
- store.
- The native persistence integrates into the Ignite multi-tier storage as a disk tier that can
- be turned on to let Ignite store more data on disk than it can cache in memory and to enable
+ comes with its native persistence - a distributed, ACID, and SQL-compliant disk-based
+ store. The native persistence integrates into the Ignite multi-tier storage as a disk tier that
+ can be turned on to let Ignite store more data on disk than it can cache in memory and to enable
fast cluster restarts.
</p>
<p>
With native persistence enabled, Ignite always stores a superset of data on disk, and caches as
- much as
- it can in memory. For example, if your application stores 200 records in an Ignite cluster and
- your
- memory capacity allows caching only 150 of them, then those 150 records will be served from
- memory while
- the rest 50 from disk whenever the application requests them.
+ much as it can in memory. For example, if your application needs to store 200 records in an
+ Ignite cluster and the memory capacity allows caching only 150 records, then all 200 will be
+ stored on disk, out of which 150 will be served from memory while the rest 50 from disk whenever
+ the application requests them.
</p>
</div>
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-right:0; top: -10px;">
@@ -86,16 +83,15 @@
<div class="page-heading">Ignite Persistence vs. External Databases</div>
<p>
- The native persistence has the following advantages over external databases that can also be used as
- the disk tier in Ignite:
+ The native persistence has the following advantages over external databases:
</p>
<ul class="page-list" style="margin-bottom: 20px;">
<li>
- An ability to cache a subset of the data - the native persistence always stores 100% of data on
+ The ability to cache a subset of the data - the native persistence always stores 100% of data on
disk and lets you cache as much as required in memory.
</li>
<li>
- An ability to query data from disk - if any record is missing in memory, then Ignite takes it from
+ The ability to query data from disk - if any record is missing in memory, then Ignite reads it from
disk. This is supported for all the APIs including SQL.
</li>
<li>
@@ -114,12 +110,12 @@
As WAL grows, it periodically gets checkpointed to the main storage. Checkpointing is the process of
copying dirty pages from the memory tier to the partition files on disk. A dirty page is a page that was
- updated in memory, was appended to WAL, but was not written to a respective partition file on disk yet.
+ updated in memory, was appended to WAL, but was not written to the respective partition file on disk yet.
</p>
<div class="page-heading">Durability</div>
<p>
- Ignite provides strong ACID durability guarantees to the data:
+ Ignite native persistence provides the following ACID guarantees across the cluster:
</p>
<ul class="page-list" style="margin-bottom: 20px;">
diff --git a/features/sql.html b/features/sql.html
index 1aba5c0..eb73451 100644
--- a/features/sql.html
+++ b/features/sql.html
@@ -58,13 +58,14 @@
<div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
<div class="col-sm-6 col-md-7 col-xs-12" style="padding-left:0;">
<p>
- Apache Ignite comes with ANSI-99 compliant, horizontally scalable, and fault-tolerant SQL engine.
- That allows you to interact with Ignite as with a regular SQL database using JDBC, ODBC drivers,
- or native SQL APIs available for Java, C#, C++, Python, and other programming languages.
+ Apache Ignite comes with ANSI-99 compliant, horizontally scalable, and fault-tolerant SQL engine
+ allowing you to interact with Ignite as with a regular SQL database using JDBC, ODBC drivers, or
+ native SQL APIs available for Java, C#, C++, Python, and other programming languages.
+
</p>
<p>
- Ignite supports all DML commands, including SELECT, UPDATE, INSERT, and DELETE
- queries as well as a subset of DDL commands relevant for distributed systems.
+ Ignite supports all DML commands, including SELECT, UPDATE, INSERT, and DELETE queries as well
+ as a subset of DDL commands relevant for distributed systems.
</p>
</div>
@@ -77,42 +78,42 @@
Ignite fully supports distributed joins for advanced querying needs. A distributed join is a SQL statement
with a join clause that combines two or more tables. If the tables are joined on the partitioning column
(affinity or primary key), the join is called a co-located join. Otherwise, if the tables were not
- co-located initially, then Ignite does the join in a non-colocated fashion. The co-located joins avoid
- data shuffling between nodes, minimizes network usage, thus, performing much faster than a non
- co-located counterpart.
+ co-located initially, then Ignite does the join in a non-colocated fashion. Co-located joins avoid data
+ shuffling between nodes and minimize network usage, thus, performing much faster than a non-colocated
+ counterpart.
</p>
<div class="page-heading">SQL and In-Memory Mode</div>
<p>
- Apache Ignite can function in a pure in-memory mode when all data and indexes are located solely in memory.
- In this mode, Ignite SQL shows the highest performance as long as all the data is served from memory,
- and there is no need to update the disk tier.
+ Apache Ignite can function in a pure in-memory mode when all the data and indexes are located solely in
+ memory. In this mode, Ignite SQL shows the highest performance since all the data is served from memory
+ wih no usage of the disk tier at all.
</p>
<div class="page-heading">SQL and Native Persistence</div>
<p>
In this mode, Ignite persists 100% of data and indexes in the native persistence while caching as much
as possible in memory. Ignite SQL engine does not require to cache an entire data set in memory to
- operate correctly. If the engine finds that any record is not cached, then it will be taken from disk.
- Your application merely executes SQL queries, and Ignite gets the records from both memory and disk
+ operate correctly. If the engine finds that a record is not cached, then it will read the record from
+ disk. Your application only executes SQL queries, and Ignite gets the records from both memory and disk
automatically.
</p>
<p>
- On cluster restarts, Ignite reads data and indexes from disk, eliminating the need for memory warm-up.
- That significantly decreases the time of any potential downtimes.
+ On cluster restarts, Ignite reads data and indexes from disk, eliminating the need for memory warm-up,
+ which significantly decreases the time of any potential downtimes.
</p>
<div class="page-heading">SQL and 3rd Party Databases</div>
<p>
- Ignite can be used as a caching layer for external databases such as RDBMS, NoSQL, or Hadoop.
- In this mode, the Ignite SQL engine requires to cache all the data needed for SQL queries in memory as
- long as the engine does not support federated queries at the moment.
+ Ignite can be used as a caching layer for external databases such as RDBMS, NoSQL, or Hadoop. In this mode,
+ the Ignite SQL engine requires caching all the data needed for SQL queries in memory since the engine
+ currently does not support federated queries.
</p>
<p>
- If federate queries between Ignite and an external database are required, then you can consider Ignite
- integration for Spark -- DataFrames API can join data stored in Ignite and other systems.
+ If federated queries between Ignite and an external database are required, then you can consider Ignite
+ integration for Spark, where the DataFrames API can join the data stored in Ignite and other systems.
</p>
<div class="page-heading">Learn More</div>
