merging edits by Prachi
git-svn-id: https://svn.apache.org/repos/asf/ignite/site/branches/ignite-redisign@1874273 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/includes/header.html b/includes/header.html
index e6f1f25..462f2dd 100644
--- a/includes/header.html
+++ b/includes/header.html
@@ -89,7 +89,7 @@
onclick="ga('send', 'event', 'apache_ignite_usecases', 'menu_click', 'in_memory_cache');">
In-Memory Cache</a>
</li>
- <li><a href="/features/datagrid.html" aria-label="In-Memory Data Grid"
+ <li><a href="/use-cases/datagrid.html" aria-label="In-Memory Data Grid"
onclick="ga('send', 'event', 'apache_ignite_usecases', 'menu_click', 'data_grid');">
In-Memory Data Grid</a>
</li>
diff --git a/use-cases/datagrid.html b/use-cases/datagrid.html
index 831dde9..64c4095 100644
--- a/use-cases/datagrid.html
+++ b/use-cases/datagrid.html
@@ -39,7 +39,7 @@
<meta name="description"
content="Apache Ignite as an In-Memory Data Grid accelerates and scales your databases, services, and APIs
- with support of ANSI SQL, ACID transactions, co-located compute, and machine learning."/>
+ through ANSI SQL, ACID transactions, co-located compute, and machine learning."/>
<title>In-Memory Data Grid - Apache Ignite</title>
@@ -56,49 +56,50 @@
<h1 class="first">In-Memory Data Grid With SQL, ACID Transactions and Compute APIs</h1>
<div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
<p>
- Apache Ignite provides an extensive set of APIs to act as an in-memory data grid that integrates into
- your existing architecture and accelerates databases, services, or custom APIs.
+ Apache Ignite provides an extensive set of user-friendly APIs to serve as an in-memory data grid
+ that integrates into your existing architecture seamlessly and accelerates databases, services, and
+ custom APIs.
</p>
<p>
An in-memory data grid type of deployment is also known as a read-through/write-through caching
- strategy. With this strategy, Ignite plugs into your existing architecture seamlessly, and the
- application layer starts treating it as a primary store. Your application layer writes to and reads
- from Ignite, while the latter ensures that any underlying external databases stay updated and
- consistent with in-memory data.
+ strategy, in which case the application layer starts treating the data grid as the primary store.
+ While the application layer writes to and reads from Ignite, the latter ensures that any underlying
+ database stays updated and consistent with in-memory data.
</p>
<p>
- As an in-memory data grid, Ignite provides all the essential developer APIs needed to simplify its
- adoption. The APIs include distributed key-value and ANSI SQL queries, ACID transactions,
- co-located computations, and machine learning models. While key-value and SQL calls let you request,
- join, and group distributed data sets, the compute and machine learning components help to eliminate
- data shuffling over the network, thus, boosting compute and data-intensive calculations.
+ As an in-memory data grid, Ignite provides all essential APIs needed to simplify its adoption.
+ The APIs include distributed key-value and ANSI SQL queries, ACID transactions, co-located
+ computations, and machine learning models. While key-value and SQL calls let you request, join, and
+ group distributed data sets, the compute and machine learning components help to eliminate data
+ shuffling over the network, thus, boosting compute and data-intensive calculations.
</p>
<p>
Ignite is capable of storing data both in memory and on disk with two options for data persistence
-- you can persist changes in an external database or let Ignite keep data in its native persistence.
- Let's review two of them.
+ Let's review both of these options.
</p>
<div class="col-sm-8 col-md-8 col-xs-12" style="padding-left:0; padding-right:0">
<div class="page-heading">Ignite and External Databases</div>
<p>
- Ignite as an in-memory data grid can improve performance and scalability of existing external
- databases such as RDBMS, NoSQL or Hadoop, by sliding in as an in-memory cache between the application
- and database layers. Ignite will automatically write-through or write-behind all the changes to
- an external store. It also includes ACID transactions - Ignite coordinates and commits a
- transaction across its in-memory cluster as well as a relational database.
+ Ignite can improve the performance and scalability of any external database such as RDBMS,
+ NoSQL or Hadoop, by sliding in as an in-memory cache between the application and the database
+ layer. When an application writes data to the cache, Ignite automatically writes-through or
+ writes-behind all data modifications to the underlying external store. Ignite also performs
+ ACID transactions where it coordinates and commits a transaction across the cluster as well as
+ the database.
</p>
<p>
- In addition to that, Ignite can be deployed as a shared and unified in-memory layer that stores
- data sets originating from disjointed databases. Your applications can consume all the data from
+ Additionally, Ignite can be deployed as a shared and unified in-memory layer that stores data
+ sets originating from disjointed databases. Your applications can consume all the data from
Ignite as a single store while Ignite can keep the original databases in sync whenever in-memory
data gets updated.
</p>
<p>
However, there are some limitations if an external database is used as a persistence layer for
- Ignite deployments. For instance, if you run Ignite SQL or scan queries, you need to ensure
- that all the data has already been preloaded to the in-memory cluster. Note that Ignite SQL or
- scan queries can read data from disk only if it's stored in Ignite native persistence.
+ Ignite deployments. For instance, if you run Ignite SQL or scan queries, you need to ensure that
+ all the data has been preloaded to the in-memory cluster. Note that Ignite SQL or scan queries
+ can read data from disk only if it is stored in Ignite native persistence.
</p>
</div>
@@ -112,13 +113,11 @@
<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 data and indexes on disk.
- The native persistence lets eliminate time-consuming data reloading
- phase from external databases as well as a cache warm-up step. Furthermore, 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 Ignite finds that a record is missing in memory, then it will read it from
- disk automatically regardless of the API you use -- let it be SQL, key-value, or scan queries.
+ integrates with Ignite in-memory layer. When 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
+ disk automatically regardless of the API you use -- be it SQL, key-value, or scan queries.
</p>
</div>
@@ -140,11 +139,6 @@
</a>
</p>
<p>
- <a href="/features/machinelearning.html">
- <b>Machine Learning <i class="fa fa-angle-double-right"></i></b>
- </a>
- </p>
- <p>
<a href="/features/transactions.html">
<b>ACID Transactions <i class="fa fa-angle-double-right"></i></b>
</a>
diff --git a/use-cases/in-memory-cache.html b/use-cases/in-memory-cache.html
index 48aef45..bf7da0e 100644
--- a/use-cases/in-memory-cache.html
+++ b/use-cases/in-memory-cache.html
@@ -101,8 +101,8 @@
If Apache Ignite is deployed in a cache-aside configuration, then its native persistence can be used as
a disk store for Ignite data sets. The native persistence allows eliminating the time-consuming cache
warm-up step. Furthermore, 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 Ignite finds that a record is missing in memory,
- then it will read it from disk automatically regardless of the API you use -- be it SQL, key-value,
+ 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 disk automatically regardless of the API you use -- be it SQL, key-value,
or scan queries.
</p>
