Author: dmagda
Date: Thu Feb 8 03:25:38 2018
New Revision: 1823535
URL: http://svn.apache.org/viewvc?rev=1823535&view=rev
Log:
commit collocated processing
Modified:
ignite/site/branches/ignite-7061/collocatedprocessing.html
Modified: ignite/site/branches/ignite-7061/collocatedprocessing.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-7061/collocatedprocessing.html?rev=1823535&r1=1823534&r2=1823535&view=diff
==============================================================================
--- ignite/site/branches/ignite-7061/collocatedprocessing.html (original)
+++ ignite/site/branches/ignite-7061/collocatedprocessing.html Thu Feb 8
03:25:38 2018
@@ -75,10 +75,73 @@ under the License.
<div class="page-heading">Data Collocation</div>
<p>
- In many cases, it is beneficial to collocate different entries
if they will be
- accessed together. Quite often, business logic will require
access to more than one entry. By collocating them together we can ensure that
all the entries with the same affinityKey will be stored on the same processing
node, hence avoiding costly network trips to fetch data from remote nodes
+ To start benefiting from the collocated processing, we need to
ensure that the data is properly collocated
+ at the first place. If business logic requires to access more
than one entry it can be reasonable to
+ collocate dependent entries by storing them on a single
cluster node. This technique is also known as
+ affinity collocation of the data.
</p>
+ <p>
+ In the example below, we have <code>Country</code> and
<code>City</code> tables and want to collocate
+ <code>City</code> entries with <code>Country</code> entries
for where a city is located. To achieve this,
+ we use the <code>WITH</code> clause and specify
<code>affinityKey=CountryCode</code> as shown below:
+ </p>
+ <div class="tab-content">
+
+ <div class="tab-pane active" id="sql-tables">
+ <pre class="brush:sql">
+ CREATE TABLE Country (
+ Code CHAR(3),
+ Name CHAR(52),
+ Continent CHAR(50),
+ Region CHAR(26),
+ SurfaceArea DECIMAL(10,2),
+ Population INT(11),
+ Capital INT(11),
+ PRIMARY KEY (Code)
+ ) WITH "template=partitioned, backups=1";
+
+ CREATE TABLE City (
+ ID INT(11),
+ Name CHAR(35),
+ CountryCode CHAR(3),
+ District CHAR(20),
+ Population INT(11),
+ PRIMARY KEY (ID, CountryCode)
+ ) WITH "template=partitioned, backups=1,
affinityKey=CountryCode";
+ </pre>
+ </div>
+ </div>
+ <p>
+ By collocating the tables together we can ensure that all the
entries with the same <code>affinityKey</code>
+ will be stored on the same cluster node, hence avoiding costly
network trips to fetch data from other
+ remote nodes.
+ </p>
+ <div class="page-heading">SQL and Distributed JOINs</div>
+ <p>
+ Apache Ignite SQL engine will always perform much more
efficiently if a query is run against the
+ collocated data. Especially it is crucial for distributed
JOINs supported by Ignite.
+ </p>
+ <p>
+ Taking the two tables created above as an example, let's get
the most inhabited cities across China,
+ Russia and the USA joining the data stored in the
<code>Country</code> and <code>City</code> tables, as follows:
+ </p>
+ <div class="tab-content">
+ <div class="tab-pane active" id="sql-joins-query">
+ <pre class="brush:sql">
+ SELECT country.name, city.name,
MAX(city.population) as max_pop
+ FROM country
+ JOIN city ON city.countrycode = country.code
+ WHERE country.code IN ('USA','RUS','CHN')
+ GROUP BY country.name, city.name
+ ORDER BY max_pop DESC;
+ </pre>
+ </div>
+ </div>
+ <p>
+ Since all the data was collocated beforehand, Ignite will
execute the query with the JOIN in the collocated
+ mode
+ </p>
<div class="page-heading">Usage Example</div>
<p>
Let's assume that a blizzard is approaching New York. As a
telecommunication company, you have to
