You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ignite.apache.org by ds...@apache.org on 2017/09/26 02:34:06 UTC
svn commit: r1809677 - in /ignite/site/trunk: collocatedprocessing.html
use-cases/database/key-value-store.html whatisignite.html
Author: dsetrakyan
Date: Tue Sep 26 02:34:05 2017
New Revision: 1809677
URL: http://svn.apache.org/viewvc?rev=1809677&view=rev
Log:
Some content improvements.
Modified:
ignite/site/trunk/collocatedprocessing.html
ignite/site/trunk/use-cases/database/key-value-store.html
ignite/site/trunk/whatisignite.html
Modified: ignite/site/trunk/collocatedprocessing.html
URL: http://svn.apache.org/viewvc/ignite/site/trunk/collocatedprocessing.html?rev=1809677&r1=1809676&r2=1809677&view=diff
==============================================================================
--- ignite/site/trunk/collocatedprocessing.html (original)
+++ ignite/site/trunk/collocatedprocessing.html Tue Sep 26 02:34:05 2017
@@ -62,7 +62,7 @@ under the License.
network is the most expensive operation in a distributed system.
</p>
<p>
- A much more scalable approach is <b>collocated processing</b> that reverses the flow by bringing
+ A much more scalable approach is <code>collocated</code> processing that reverses the flow by bringing
the computations to the servers where the data actually resides. This approach allows you to
execute advanced logic or distributed SQL with JOINs exactly where the data is stored avoiding
expensive serialization and network trips.
@@ -75,25 +75,19 @@ under the License.
<div class="page-heading">Usage Example</div>
<p>
- Let's assume that a blizzard is approaching New York City. You, as a telecommunication company has to warn
- all the people sending a message to everyone with precise instructions on how to behave during such
- weather conditions. There are around 8 million New Yorkers in your database that have to receive
- the text message.
+ Let's assume that a blizzard is approaching New York. As a telecommunication company, you have to
+ send a warning text message to 8 million New Yorkers.
+ With the client-server approach the company has to move all <nobr>8 million (!)</nobr> records
+ from the database to the client text messaging application, which does not scale.
</p>
<p>
- With the client-server approach the company has to connect to the database, move all 8 million (!) records
- from there to a client application that will text to everyone. This is highly inefficient that wastes
- network and computational resources of company's IT infrastructure.
- </p>
- <p>
- However, if the company initially collocates all the cities it covers with the people who live there then
- it can send a single computation (!) to the cluster node that stores information about all New Yorkers
- and send the text message from there. This approach avoids 8 million records movement over the network
- and helps utilizing cluster resources for computation needs. That's the collocated processing in action!
+ A much more efficient approach would be to send the text-messaging logic to the cluster node responsible
+ for storing the New York residents. This approach moves only 1 computation instead of 8 million records
+ across the network, and performs a lot better.
</p>
<p>
- Code snippet below shows a way how this computation might look like:
+ Here is an example of how this logic might look like:
</p>
<!--<ul id="compute-example" class="nav nav-tabs">-->
<!--<li class="active"><a href="#compute-task" aria-controls="profile" data-toggle="tab">Message Broadcasting Logic</a></li>-->
Modified: ignite/site/trunk/use-cases/database/key-value-store.html
URL: http://svn.apache.org/viewvc/ignite/site/trunk/use-cases/database/key-value-store.html?rev=1809677&r1=1809676&r2=1809677&view=diff
==============================================================================
Binary files - no diff available.
Modified: ignite/site/trunk/whatisignite.html
URL: http://svn.apache.org/viewvc/ignite/site/trunk/whatisignite.html?rev=1809677&r1=1809676&r2=1809677&view=diff
==============================================================================
--- ignite/site/trunk/whatisignite.html (original)
+++ ignite/site/trunk/whatisignite.html Tue Sep 26 02:34:05 2017
@@ -71,17 +71,17 @@ under the License.
<p>
Ignite's durable memory component treats RAM not just as a caching layer but as a complete fully functional storage layer.
This means that users can turn the persistence on and off as needed. If the persistence is off, then Ignite
- can act as a distributed <nobr><i><strong>in-memory database</strong></i></nobr> or <nobr><i><strong>in-memory data grid</strong></i></nobr>,
+ can act as a distributed <nobr><i><a href="/use-cases/database/in-memory-database.html">in-memory database</a></i></nobr> or <nobr><i><a href="/features/datagrid.html">in-memory data grid</a></i></nobr>,
depending on whether you prefer to use SQL or key-value APIs. If the persistence is turned on, then Ignite becomes a distributed,
- <nobr><i><strong>horizontally scalable database</strong></i></nobr> that guarantees full data consistency and is
+ <nobr><i><a href="/features/sql.html">horizontally scalable database</a></i></nobr> that guarantees full data consistency and is
resilient to full cluster failures.
</p>
<h3>Ignite Persistence</h3>
<p>
- Ignite Native Persistence is a distributed, ACID, and SQL-compliant <i><strong>disk store</strong></i> that transparently integrates with Ignite's Durable Memory as an
+ Ignite <a href="/features/persistence.html">native persistence</a> is a distributed, ACID, and SQL-compliant <i><strong>disk store</strong></i> that transparently integrates with Ignite's Durable Memory as an
optional disk layer storing data and indexes on SSD, Flash, 3D XPoint, and other types of non-volatile storages.
- With the Ignite Persistence enabled, you no longer need to keep all the data and indexes in memory or warm it up after a node or
+ With the Ignite persistence enabled, you no longer need to keep all the data and indexes in memory or warm it up after a node or
cluster restart because the Durable Memory is tightly coupled with persistence and treats it as a secondary memory tier.
This implies that if a subset of data or an index is missing in RAM, the Durable Memory will take it from the disk.
</p>
@@ -95,12 +95,12 @@ under the License.
<p>
Ignite provides full support for SQL, DDL and DML, allowing users to interact with Ignite using pure SQL without writing any code.
This means that users can create tables and indexes as well as insert, update, and query data using only SQL. Having such complete SQL support makes Ignite a one-of-a-kind
- <i><strong>distributed SQL database</strong></i>.
+ <i><a href="/features/sql.html">distributed SQL database</a></i>.
</p>
<h3>Key-Value</h3>
<p>
- The in-memory data grid component in Ignite is a fully transactional <i><strong>distributed key-value store</strong></i> that can scale horizontally
+ The in-memory data grid component in Ignite is a fully transactional <i><a href="/use-cases/database/key-value-store.html">distributed key-value store</a></i> that can scale horizontally
across 100s of servers in the cluster. When persistence is enabled, Ignite can also store more data than fits in memory and survive full cluster restarts.
</p>
@@ -108,7 +108,7 @@ under the License.
<p>
Most traditional databases work in a client-server fashion, meaning that data must be brought to the client side for processing. This approach requires
lots of data movement from servers to clients and generally does not scale. Ignite, on the other hand, allows for sending light-weight computations to the data,
- i.e. <i><strong>collocating</strong></i> computations with data. As a result, Ignite scales better and minimizes data movement.
+ i.e. <nobr><i><a href="/collocatedprocessing.html">collocating computations with data</a></i></nobr>. As a result, Ignite scales better and minimizes data movement.
</p>
<h3>Scalability and Durability</h3>