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/03/06 16:33:32 UTC

svn commit: r1874912 - in /ignite/site/branches/ignite-redisign: arch/multi-tier-storage.html arch/persistence.html features/sql.html

Author: dmagda
Date: Fri Mar  6 16:33:32 2020
New Revision: 1874912

URL: http://svn.apache.org/viewvc?rev=1874912&view=rev
Log:
updated multi-tier, persistence and sql pages

Modified:
    ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html
    ignite/site/branches/ignite-redisign/arch/persistence.html
    ignite/site/branches/ignite-redisign/features/sql.html

Modified: ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html?rev=1874912&r1=1874911&r2=1874912&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html (original)
+++ ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html Fri Mar  6 16:33:32 2020
@@ -43,8 +43,9 @@ under the License.
     <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 @@ under the License.
             <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 @@ under the License.
             <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 @@ under the License.
                     <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 @@ under the License.
                     <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 @@ under the License.
                     <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 @@ under the License.
                 <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 @@ under the License.
                 <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 @@ under the License.
             </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>

Modified: ignite/site/branches/ignite-redisign/arch/persistence.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/arch/persistence.html?rev=1874912&r1=1874911&r2=1874912&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/arch/persistence.html (original)
+++ ignite/site/branches/ignite-redisign/arch/persistence.html Fri Mar  6 16:33:32 2020
@@ -61,20 +61,17 @@ under the License.
                 <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 @@ under the License.
 
             <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 @@ under the License.
 
                 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;">

Modified: ignite/site/branches/ignite-redisign/features/sql.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/features/sql.html?rev=1874912&r1=1874911&r2=1874912&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/features/sql.html (original)
+++ ignite/site/branches/ignite-redisign/features/sql.html Fri Mar  6 16:33:32 2020
@@ -58,13 +58,14 @@ under the License.
             <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 @@ under the License.
                 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>