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 2018/07/24 21:52:32 UTC
svn commit: r1836587 - in /ignite/site/trunk/features: datagrid.html sql.html
Author: dmagda
Date: Tue Jul 24 21:52:32 2018
New Revision: 1836587
URL: http://svn.apache.org/viewvc?rev=1836587&view=rev
Log:
updated sql and datagrid page
Modified:
ignite/site/trunk/features/datagrid.html
ignite/site/trunk/features/sql.html
Modified: ignite/site/trunk/features/datagrid.html
URL: http://svn.apache.org/viewvc/ignite/site/trunk/features/datagrid.html?rev=1836587&r1=1836586&r2=1836587&view=diff
==============================================================================
--- ignite/site/trunk/features/datagrid.html (original)
+++ ignite/site/trunk/features/datagrid.html Tue Jul 24 21:52:32 2018
@@ -56,7 +56,6 @@ under the License.
<section id="datagrid" class="page-section">
<h1 class="first">Key-Value In-Memory Data Grid</h1>
<div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
-
<p>
Ignite provides extensive and rich key-value APIs and can act as an in-memory data grid.
You can think of Ignite as of a distributed partitioned hash map with every
@@ -78,7 +77,7 @@ under the License.
transactions, providing transparent transactional behavior to the users.
</p>
<p>
- However, this approach also has its limitations. For example, SQL or scan queries will only include the
+ However, this approach has its limitations. For example, SQL or scan queries will only include the
results stored in memory, and not in the external database, since Ignite cannot index the external data.
If you require that data on disk should be indexed and accessible via SQL queries, we recommend that you look at
<a href="/arch/persistence.html">Ignite native persistence</a>.
@@ -88,8 +87,8 @@ under the License.
<div class="col-sm-4 col-md-4 col-xs-12" style="padding-right:0">
<img class="img-responsive" src="/images/IMDG.png" width="300px" style="float:right;"/>
</div>
-
-
+ </div>
+ <div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
<div class="col-sm-8 col-md-8 col-xs-12" style="padding-left:0; padding-right:0">
<div class="page-heading">Native Persistence</div>
<p>
@@ -109,7 +108,7 @@ under the License.
<div class="page-heading">Key-Value APIs</div>
<p>
- In addition to the standard <a href="/use-cases/caching/jcache-provider.html">JCache (JSR 107)</a>, API Ignites supports distributed ACID transactions,
+ In addition to the standard <a href="/use-cases/caching/jcache-provider.html">JCache (JSR 107)</a> API, Ignites supports distributed ACID transactions,
scan and continuous queries, collocated processing and more.
</p>
Modified: ignite/site/trunk/features/sql.html
URL: http://svn.apache.org/viewvc/ignite/site/trunk/features/sql.html?rev=1836587&r1=1836586&r2=1836587&view=diff
==============================================================================
--- ignite/site/trunk/features/sql.html (original)
+++ ignite/site/trunk/features/sql.html Tue Jul 24 21:52:32 2018
@@ -74,7 +74,7 @@ under the License.
<p>
Ignite can <nobr><a href="https://apacheignite-sql.readme.io/docs/distributed-joins" target="_blank">join data</a></nobr>
in both collocated and non-collocated fashions. When <a href="/features/collocatedprocessing.html">collocated</a>,
- the JOINs are executed on the nodes where the data is stored, avoiding
+ JOINs are executed on the nodes where the data is stored, avoiding
expensive serialization and network trips. Such approach provides the best scalability and performance
in distributed databases.
</p>
@@ -82,36 +82,33 @@ under the License.
<div class="page-heading">SQL and In-Memory Mode</div>
<p>
Apache Ignite can function in a pure in-memory mode in which all data and indexes are stored entirely
- in RAM. In this scenario, you can achieve the maximum performance possible because the data is never
- written to disk. As with any other in-memory database, configure backup copies of the data to
- prevent possible data loss in case of cluster nodes failures.
+ in RAM. In this mode, you can achieve the maximum performance possible because the data is never
+ written to disk. As with any other in-memory database, you can configure backup copies of the data to
+ prevent possible data loss if cluster nodes fail.
</p>
<div class="page-heading">SQL and Native Persistence</div>
<p>
In this mode, <a href="/arch/persistence.html">Ignite native persistence</a> serves as the primary
- storage that survives any type of cluster failures and restarts. 100% of data and indexes are
+ storage that can survive cluster failures and restarts. 100% of data and indexes are
persisted to disk and the same or smaller amount is cached in memory.
+ When memory resources are scarce, indexes will take priority over data in
+ which case indexes will be cached first. This policy helps to run high-performant
+ SQL queries even if RAM is limited. If a value or index is missing in memory, Ignite will query on-disk data.
</p>
<p>
- Ignite always queries on-disk data if a value or index is missing in memory. If RAM resources are
- scarce, you'll find Ignite caching the most frequently used indexes there over the data. This policy helps
- to run high-performant SQL queries even if memory resources are limited.
- </p>
- <p>
- On a restart, Ignite will be reading data and indexes from disk not requiring you to warm the memory up.
- This significantly decreases a potential downtime.
+ On cluster restart, Ignite reads data and indexes from disk eliminating the need for memory warm-up.
+ This process significantly decreases any potential downtime.
</p>
<div class="page-heading">SQL and 3rd Party Databases</div>
<p>
- Finally, Ignite can be used as a caching layer (aka. data grid) above an existing 3rd party database -
+ Ignite can be used as a caching layer (aka. data grid) above an existing 3rd party database -
RDBMS, NoSQL, or HDFS. This mode is used to accelerate the underlying database. Ignite provides read-through and
write-through capabilities to read and write database records.
</p>
<p>
- In this mode Ignite requires the whole data to be preloaded into caches for SELECT queries,
- it propogates all updates - INSERT, UPDATE, DELETE - to the database.
+ In this mode, Ignite requires preloading data into caches for SELECT queries; however, it propagates all updates - INSERT, UPDATE, DELETE - to the database.
</p>
<p>