Author: dmagda
Date: Tue Mar 10 20:09:42 2020
New Revision: 1875054
URL: http://svn.apache.org/viewvc?rev=1875054&view=rev
Log:
edited pages about colocated processing and key-value store
Modified:
ignite/site/branches/ignite-redisign/features/collocatedprocessing.html
ignite/site/branches/ignite-redisign/use-cases/key-value-store.html
Modified:
ignite/site/branches/ignite-redisign/features/collocatedprocessing.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/features/collocatedprocessing.html?rev=1875054&r1=1875053&r2=1875054&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/features/collocatedprocessing.html
(original)
+++ ignite/site/branches/ignite-redisign/features/collocatedprocessing.html Tue
Mar 10 20:09:42 2020
@@ -43,8 +43,8 @@ under the License.
<title>Co-located Processing - Apache Ignite</title>
<meta name="description"
- content="Apache Ignite supports co-located processing technique for
compute- and data-intensive calculations
- as well as machine learning algorithms. The technique increases
performance by eliminating the impact of
+ content="Apache Ignite supports co-located processing technique for
compute-intensive and data-intensive calculations
+ as well as machine learning algorithms. This technique increases
performance by eliminating the impact of
network latency."/>
@@ -62,19 +62,17 @@ 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>
- By working with disk-based systems such as relational
or NoSQL databases, many of us accustomed
- to using a classic client-server approach for data
processing. Client applications usually bring
- data from servers, use the records for local
calculations, and discard the data as soon as the
- business tasks complete. This approach does not scale
well if a significant volume of data gets
- transferred over the network.
+ In traditional disk-based systems, such as relational
or NoSQL databases, client applications
+ usually bring data from servers, use the records for
local calculations, and discard the data as
+ soon as the business task is complete. This approach
does not scale well if a significant volume
+ of data gets transferred over the network.
</p>
<p>
- In addition to the client-server approach, Apache
Ignite supports a co-located processing
- technique. The primary aim of the technique is to
increase the performance of your complex
- calculations or SQL with JOINs by running them
straight on Ignite cluster nodes. In such a case,
- the calculations work with local data sets of the
cluster nodes, thus, avoiding records shuffling
- over the network and eliminating an impact of the
network latency on the performance of your
- applications.
+ To overcome this issue, Apache Ignite supports a
co-located processing technique. The primary
+ aim of the technique is to increase the performance of
your complex calculations or SQL with
+ JOINs by running them straight on Ignite cluster
nodes. In co-located processing, calculations
+ are done on local data sets of the cluster nodes,
thus, avoiding records shuffling over the
+ network and eliminating the impact of network latency
on the performance of your applications.
</p>
</div>
<div class="col-sm-6 col-md-6 col-xs-12"
style="padding-right:0">
@@ -84,12 +82,12 @@ under the License.
<div class="page-heading">Data Co-location</div>
<p>
- To exploit the co-located processing in practice, first, you
need to co-locate data sets by storing
- related records on the same cluster node. That is also known
as affinity co-location in Ignite.
+ To use co-located processing in practice, first, you need to
co-locate data sets by storing
+ related records on the same cluster node. This process is also
known as affinity co-location in Ignite.
</p>
<p>
For example, let's introduce <code>Country</code> and
<code>City</code> tables and co-locate
- all <code>City</code> records that have a similar
<code>Country</code> identifier on a single node. To
+ all <code>City</code> records that have the same
<code>Country</code> identifier on a single node. To
achieve this, you need to set <code>CountryCode</code> as an
<code>affinityKey</code> in <code>City</code>
table:
</p>
@@ -121,18 +119,19 @@ under the License.
</div>
<p>
This way, you instruct Ignite to store all the
<code>Cities</code> with the same <code>CountryCode
- </code> on a single cluster node. As soon as the data is
co-located, Ignite can execute compute- and
- data-intensive logic, SQL with JOINs straight on the cluster
nodes minimizing or eliminating network utilization.
+ </code> on a single cluster node. As soon as the data is
co-located, Ignite can execute compute and
+ data-intensive logic, and SQL with JOINs straight on the
cluster nodes minimizing or even eliminating network
+ utilization.
</p>
<div class="page-heading">SQL and Distributed JOINs</div>
<p>
- Ignite SQL engine performs much faster if a query gets
executed against co-located records. That's
+ Ignite SQL engine performs much faster if a query gets
executed against co-located records. This is
especially crucial for SQL with JOINs that can span many
cluster nodes.
</p>
<p>
- Taking the previous example with <code>Country</code> and
<code>City</code> tables,
- let's join those tables returning the most populated cities
across several countries:
+ Using the previous example with <code>Country</code> and
<code>City</code> tables,
+ let's join the two tables returning the most populated cities
in the given countries:
</p>
<div class="tab-content">
<div class="tab-pane active" id="sql-joins-query">
@@ -147,14 +146,14 @@ under the License.
</div>
</div>
<p>
- This query is executed only on the nodes that store records of
China, Russia, and the USA. Plus, during
- the JOIN, the records are not shuffled between the nodes as
long as all the <code>Cities
+ This query is executed only on the nodes that store records of
China, Russia, and the USA. Also, during
+ the JOIN, the records are not shuffled between the nodes since
all the <code>Cities
</code> with the same <code>city.countrycode</code> are stored
on a single node.
</p>
<div class="page-heading">Distributed Collocated Computations</div>
<p>
- Apache Ignite compute and machine learning APIs allow to
perform computations and execute
+ Apache Ignite compute and machine learning APIs allow you to
perform computations and execute
machine learning algorithms in parallel to achieve high
performance, low latency, and linear scalability.
Furthermore, both components work best with co-located data
sets.
</p>
@@ -167,7 +166,8 @@ under the License.
<p>
A much more efficient approach would be to run the logic on
and send text messages from the cluster nodes
that store the records of the residents. With this technique,
instead of pulling 20 million records via
- the network, you execute the logic in place and eliminate a
network impact on the performance of the calculation.
+ the network, you execute the logic in place and eliminate the
network impact on the performance of the
+ calculation.
</p>
<p>
@@ -187,7 +187,7 @@ Ignite ignite = ...
// NewYork ID.
long newYorkId = 2;
-// Sending the logic to a cluster node that stores NewYork and all its
inhabitants.
+// Send the logic to the cluster node that stores NewYork and all its
inhabitants.
ignite.compute().affinityRun("City", newYorkId, new IgniteRunnable() {
@IgniteInstanceResource
@@ -195,7 +195,7 @@ ignite.compute().affinityRun("City", new
@Override
public void run() {
- // Getting an access to Persons cache.
+ // Get access to the Person cache.
IgniteCache<BinaryObject, BinaryObject> people =
ignite.cache("Person").withKeepBinary();
@@ -206,11 +206,11 @@ ignite.compute().affinityRun("City", new
for (Cache.Entry<BinaryObject, BinaryObject> entry : cursor) {
BinaryObject personKey = entry.getKey();
- // Picking NewYorker's only.
+ // Pick NewYorkers only.
if (personKey.<Long>field("CITY_ID") == newYorkId) {
person = entry.getValue();
- // Sending the warning message to the person.
+ // Send the warning message to the person.
}
}
}
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=1875054&r1=1875053&r2=1875054&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 Mar
10 20:09:42 2020
@@ -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 a distributed partitioned
+ and on disk. In this deployment mode, Ignite functions
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,
