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/10 20:09:42 UTC
svn commit: r1875054 - in /ignite/site/branches/ignite-redisign:
features/collocatedprocessing.html use-cases/key-value-store.html
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,