Author: dmagda
Date: Tue Feb 25 22:16:33 2020
New Revision: 1874534
URL: http://svn.apache.org/viewvc?rev=1874534&view=rev
Log:
merging edited versions of the hpc and key-value store pages
Modified:
ignite/site/branches/ignite-redisign/use-cases/hpc.html
ignite/site/branches/ignite-redisign/use-cases/key-value-store.html
Modified: ignite/site/branches/ignite-redisign/use-cases/hpc.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/use-cases/hpc.html?rev=1874534&r1=1874533&r2=1874534&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/use-cases/hpc.html (original)
+++ ignite/site/branches/ignite-redisign/use-cases/hpc.html Tue Feb 25 22:16:33
2020
@@ -68,8 +68,8 @@ under the License.
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 @@ under the License.
<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>
Modified: ignite/site/branches/ignite-redisign/use-cases/key-value-store.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/use-cases/key-value-store.html?rev=1874534&r1=1874533&r2=1874534&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/use-cases/key-value-store.html
(original)
+++ ignite/site/branches/ignite-redisign/use-cases/key-value-store.html Tue Feb
25 22:16:33 2020
@@ -39,7 +39,7 @@ under the License.
<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 @@ under the License.
<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 @@ under the License.
<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 @@ under the License.
<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 @@ under the License.
</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 @@ under the License.
<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>
