merging edited versions of the hpc and key-value store pages
git-svn-id: https://svn.apache.org/repos/asf/ignite/site/branches/ignite-redisign@1874534 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/use-cases/hpc.html b/use-cases/hpc.html
index f08c66a..42ea2f6 100644
--- a/use-cases/hpc.html
+++ b/use-cases/hpc.html
@@ -68,8 +68,8 @@
nodes.
</p>
<p>
- Ignite enables speed and scale for HPC scenarios by processing records in memory with the
- elimination of data shuffling and network utilization.
+ Ignite enables speed and scale for HPC scenarios by processing records in memory and reducing
+ data shuffling and network utilization.
</p>
</div>
@@ -83,39 +83,33 @@
<div class="page-heading">Co-located Processing</div>
<p>
Ignite uses the notion of co-located processing to guide HPC workloads implementations in distributed
- in-memory environments. The primary aim of this type of processing is to increase the performance of
- your complex calculations by running them straight on the Ignite cluster nodes. In such a case, the
- calculations process only local data sets of the cluster nodes, thus, avoiding records shuffling over
- the network. It results in minimal network utilization, and an order of magnitude performance increase
- depending on the data volume.
+ in-memory environments. Co-located processing increases the performance of your complex calculations by
+ running them straight on the Ignite cluster nodes. These calculations are done only on local data sets
+ available on the nodes, thus avoiding data shuffling over the network and resulting in orders of magnitude
+ increase in performance.
</p>
<p>
To exploit the co-located processing in practice, first, you need to co-locate data by storing related
- records on the same cluster node. Consider your bank account and transactions posted to it as an example
- of related or co-located data. Once you set <code>accountID</code> as an affinity
- key for <code>Transactions</code> table, then you'll instruct Ignite to store all the transactions with
- the same <code>accountId</code> on a single cluster node that keeps the record of your account in
- <code>Accounts</code> table.
- </p>
-
- <p>
- As soon as data is co-located, Ignite can execute compute- and data-intensive logic on the cluster nodes
- that store the records required for the calculation. For instance, a payment processing system can send
- a compute task for previous transactions verification to a specific Ignite node that stores your account
- record with all completed transactions and finish fraud-detection verifications locally on that machine.
- Thus, instead of pulling all the transactions back to the application over the network, the processing
- system eliminates network utilization by running verifications on the nodes that store actual data.
- The effect is even more significant when the system needs to process millions of transactions per second,
- verifying billions of previously completed payments.
+ records on the same cluster node. As an example of related or co-located data, consider your bank account
+ and transactions posted to it. Once you set <code>accountID</code> as an affinity key for the
+ <code>Transactions</code> table, you'll instruct Ignite to store all transactions for your
+ <code>accountId</code> on the same node that keeps the record of your account in the
+ <code>Accounts</code> table. Now let's say a payment processing system sends a compute task that
+ verifies previous transactions of your account. Since the data is co-located, Ignite will execute this
+ task directly on the node that stores your account record with all completed transactions and finish the
+ verification locally on that machine instead of pulling all the transactions back to the application
+ over the network. This method of executing a task on the node where the data resides provides
+ exceptionally high performance.The effect is even more significant when the system needs to process
+ millions of transactions per second, verifying billions of previously completed payments.
</p>
<div class="page-heading">Compute APIs</div>
<p>
- Ignite provides compute APIs (also known as compute grid) for creation and scheduling custom
- tasks of arbitrary complexity. The APIs implement MapReduce paradigm and presently available for Java,
- C# and C++ programming languages.
+ Ignite provides compute APIs (also known as compute grid) for creating and scheduling custom
+ tasks of arbitrary complexity. The APIs implement MapReduce paradigm and are presently available for Java,
+ C#, and C++.
</p>
<div class="page-heading">Learn More</div>
diff --git a/use-cases/key-value-store.html b/use-cases/key-value-store.html
index a12973d..ce9c71d 100644
--- a/use-cases/key-value-store.html
+++ b/use-cases/key-value-store.html
@@ -39,7 +39,7 @@
<meta name="description"
content="Apache Ignite operates as a distributed key-value store that stores data both in memory and on disk
- with support of key-value, SQL, ACID transactions, compute and machine learning APIs."/>
+ with support for key-value, SQL, ACID transactions, compute, and machine learning APIs."/>
<title>Distributed Key-Value Store - Apache Ignite</title>
@@ -58,7 +58,7 @@
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-left:0; padding-right:0">
<p>
Apache Ignite can operate as a distributed key-value store that stores data both in memory
- and on disk. In this deployment mode, you can think of Ignite as of a distributed partitioned
+ and on disk. In this deployment mode, you can think of Ignite as a distributed partitioned
hash map with every cluster node owning a portion of the overall data set. As with
standard key-value stores, you can access the cluster with key-value requests or take
advantage of APIs available exclusively in Ignite - distributed ACID transactions, SQL,
@@ -85,7 +85,7 @@
<p>
In addition to that, Ignite extends JCache specification supporting distributed key-value ACID
transactions, scan and continuous queries, co-located computations, and much more. For instance,
- continuous queries are handy for cases when you want an application to be notified whenever any record
+ continuous queries are handy for cases where you want an application to be notified whenever a record
gets updated on the server nodes. While ACID transactions let you update a set of records stored in
different caches/tables consistently.
</p>
@@ -95,10 +95,10 @@
<p>
Near cache is a local client-side cache that stores the most frequently used data on the application end.
This caching technique is supported for key-value APIs only and can be considered for applications that
- require a consistent response time withing a low microseconds range. The near cache is invalidated and
- updated by Ignite automatically. Whenever a primary copy of a record gets updated on a server node,
- the change will be propogated to all the nodes that store its backup copy as well as to your applications
- that keep a record's copy in their near caches.
+ require a consistent response time ranging in microseconds. Ignite automatically invalidates and
+ updates the near cache. Whenever the primary copy of a record gets updated on a server node, Ignite
+ propagates the change to all the nodes that store the record's backup copy as well as to your
+ applications that keep the record's copy in their near caches.
</p>
<div class="page-heading">Read-through and Write-Through/Behind</div>
@@ -111,7 +111,7 @@
</p>
<p>
- The read-through capability implies that Ignite can read data from an external database if a record is
+ The read-through capability means that Ignite can read data from an external database if a record is
missing in memory. This feature is fully supported for both JCache and extended key-value APIs.
</p>
@@ -119,12 +119,11 @@
<p>
If you want Ignite to function as a key-value store that caches data in memory and persists it to
- disk, then, alternatively to an external database, you can enable Ignite native persistence. Ignite
- 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.
+ disk instead of an external database, then you can enable Ignite native persistence. Ignite
+ persistence lets you eliminate the time-consuming cache warm-up step as well as the data reloading phase
+ from external databases. 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 a required data record is missing in memory,
+ then Ignite reads it from the disk automatically regardless of the API you use.
</p>
<div class="page-heading">Learn More</div>
