Author: dmagda
Date: Fri Mar 13 15:56:03 2020
New Revision: 1875164
URL: http://svn.apache.org/viewvc?rev=1875164&view=rev
Log:
recovered edits by Prachi for multi-tier storage, persistence and sql
Modified:
ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html
ignite/site/branches/ignite-redisign/arch/persistence.html
ignite/site/branches/ignite-redisign/features/sql.html
Modified: ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html?rev=1875164&r1=1875163&r2=1875164&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html (original)
+++ ignite/site/branches/ignite-redisign/arch/multi-tier-storage.html Fri Mar
13 15:56:03 2020
@@ -33,141 +33,199 @@ under the License.
<!DOCTYPE html>
<html lang="en">
<head>
-<link rel="canonical"
href="https://ignite.apache.org/arch/multi-tier-storage.html"/>
-<meta charset="utf-8">
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<meta http-equiv="Cache-Control" content="no-cache, no-store,
must-revalidate"/>
-<meta http-equiv="Pragma" content="no-cache"/>
-<meta http-equiv="Expires" content="0"/>
-<title>Multi-Tier Storage - Apache Ignite</title>
-<meta name="description"
- content="Apache Ignite multi-tier storage uses memory, disk and
Intel® Optane⢠as active storage tiers. Speed of
- memory with the consistency of disk-based databases and no need for
memory warm-ups on restarts."/>
+ <link rel="canonical"
href="https://ignite.apache.org/arch/multi-tier-storage.html"/>
+ <meta charset="utf-8">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+ <meta http-equiv="Cache-Control" content="no-cache, no-store,
must-revalidate"/>
+ <meta http-equiv="Pragma" content="no-cache"/>
+ <meta http-equiv="Expires" content="0"/>
-<!--#include virtual="/includes/styles.html" -->
+ <title>Multi-Tier Storage - Apache Ignite</title>
-<!--#include virtual="/includes/sh.html" -->
+ <meta name="description"
+ content="Apache Ignite multi-tier storage uses memory, disk, and
Intel® Optane⢠as active storage tiers to
+ provide the speed of memory with the consistency of disk-based
databases without the need for memory
+ warm-ups on restarts."/>
+
+ <!--#include virtual="/includes/styles.html" -->
+
+ <!--#include virtual="/includes/sh.html" -->
</head>
<body>
-<!--#include virtual="/includes/header.html" -->
+
+ <!--#include virtual="/includes/header.html" -->
<article>
- <div class="container">
-
- <h1>Multi-Tier <strong>Storage</strong></h1>
-
- <p> Apache Ignite is designed to work with memory, disk and Intel®
Optane⢠as active storage tiers.
- The memory tier allows to use DRAM and Intel® Optane⢠operating
in the Memory Mode for data storage and processing needs.
- The disk tier is optional with the support of two options -- you can
persist data in an external database or keep it in the Ignite native
persistence. SSD, Flash, HDD or Intel® Optane⢠operating in the AppDirect
Mode can be used as a storage device. </p>
- <img class="img-fluid diagram-right" src="/images/durable_memory.png" />
-
- <p> Ignite takes full control of its memory tier by allocating and
managing off-heap regions. Each Ignite
- server node allocates memory regions during bootstrap, splits the
regions into pages, and keeps data
- records with indexes there. Java heap is used to keep temporary
objects such as queries results sets,
- metrics samples, objects generated by your application code. All these
objects are garbage collected
- eventually. </p>
- <p> If you select the native persistence as the disk tier, then most of
the processing will still
- take place in memory on cached data, but, with a full copy stored on
disk. If any record is
- missing in memory, Ignite will read it from disk, allowing you to
persist much larger data sets
- than you can cache in memory. That also eliminates the need for
time-consuming memory warm-ups
- on restarts. As soon as your cluster reconnects after a restart,
Ignite will serve most of the
- data from disk warming the memory tier up in the background. </p>
-
- <h2>Multi-Tier Storage Usage Modes <a
href="/arch/multi-tier-storage.html#storage-usage-modes"><i class="fa
fa-anchor"></i></a> </h2>
-
- <p>Below you can see primary modes for multi-tier storage usage and
configuration:</p>
-
- <table class="table table-bordered table-striped" name="Deployment
Options Features">
- <thead>
- <tr>
- <th width="35%" class="left">Mode</th>
- <th>Description</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td class="left">In-Memory</td>
- <td><p> The whole data set is available in memory only. In order
to survive node failures, it is
- recommended to keep at least one backup copy of the data
across the cluster. DRAM or Intel®
- Optane⢠operating in the Memory Mode can be used as a
storage device. </p>
- <p> <strong>Use cases</strong>: general in-memory caching,
high-performance
- computing, web-session caching, real-time processing of
continuous data streams. </p></td>
- </tr>
- <tr>
- <td class="left">In-Memory + External Database</td>
- <td><p> Ignite is deployed as a distributed caching layer on top
of an existing external database.
- This mode is for the acceleration of disk-based databases and
your services with APIs that
- interact with them. </p>
- <p> <strong>Use cases</strong>: acceleration of services and
APIs with write-through/behind
- capability, to an external database (aka. in-memory data
grid). </p></td>
- </tr>
- <tr>
- <td class="left">In-Memory Cache + Native Persistence</td>
- <td><p> 100% of data is persisted to disk, and the same or smaller
amount is cached in memory.
- The more data is cached, the faster is the performance. The
disk serves as the primary
- storage that survives any cluster failures and restarts. No
need for memory warm-ups on
- restarts as long as Ignite can serve data from disk. SSD,
Flash, HDD or Intel®
- Optane⢠operating in the AppDirect Mode can be used as a
storage device. </p>
- <p> <strong>Use cases</strong>: Ignite as an in-memory database
or digital integration hub
- with the active persistence layer. </p></td>
- </tr>
- </tbody>
- </table>
-
-
- <h2>Partitioning & Replication <a
href="/arch/multi-tier-storage.html#partitioning"><i class="fa
fa-anchor"></i></a> </h2>
- <p>Depending on the configuration, Ignite can both partition or
replicate data across the cluster. With the replicated mode, each cluster node
keeps a full copy of the data that is advantageous for frequently accessed
dictionaries. As for the partitioned mode, Ignite spreads the data across all
the cluster nodes evenly, allowing to store much more than a single machine can
fit in.</p>
-
- <h2>Durability and Consistency <a
href="/arch/multi-tier-storage.html#durability"><i class="fa
fa-anchor"></i></a> </h2>
- <p>Ignite provides strong ACID durability guarantees to the data:</p>
- <ul class="page-list" style="margin-bottom: 20px;">
- <li>Committed transactions always survive failures.</li>
- <li>The cluster can always be recovered to the latest successfully
committed transaction.</li>
- </ul>
-
+ <div class="container">
+ <h1>Multi-Tier <strong>Storage</strong></h1>
- <h2>Write-Ahead Logging and Checkpointing <a
href="/arch/multi-tier-storage.html#write-ahead-log"><i class="fa
fa-anchor"></i></a></h2>
- <p> If Ignite native persistence is selected as a disk tier, then
every time a record is updated in memory, the change is added to the
write-ahead log (WAL). The purpose of the WAL is to propagate updates to disk
in the fastest way possible and provide a consistent recovery mechanism that
supports full cluster failures. </p>
- <p> As WAL grows, it periodically gets checkpointed to the main
storage. Checkpointing is the process of copying dirty pages from the memory
tier to the partition files on disk. A dirty page is a page that was updated in
memory, was appended to WAL, but was not written to a respective partition file
on disk yet. </p>
-
- <div class="jumbotron jumbotron-fluid">
- <div class="container">
- <div class="display-6 title">Learn More</div>
- <hr class="my-4">
- <div class="row">
- <div class="col-6 col-xs-12">
- <ul>
- <li>
- <p><a
href="https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood";
target="docs">Multi-Tier Storage Implementation Details <i class="fa
fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a href="/arch/persistence.html"> Native Persistence <i
class="fa fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a href="/features/datagrid.html"> Ignite as an
In-Memory Data Grid <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- </ul>
- </div>
- <div class="col-6 col-xs-12">
- <ul>
- <li>
- <p><a href="/use-cases/in-memory-database.html"> Ignite as
an In-Memory Database <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a href="/use-cases/dih.html"> Ignite as a Digital
Integration Hub <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a href="/use-cases/hpc.html"> Ignite for High
Performance Computing <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- </ul>
+
+ <p>
+ Apache Ignite is designed to work with memory, disk, and Intel®
Optane⢠as active storage tiers.
+ The memory tier allows using DRAM and Intel® Optane⢠operating
in the Memory Mode for data storage
+ and processing needs. The disk tier is optional with the support
of two options -- you can
+ persist data in an external database or keep it in the Ignite
native persistence. SSD, Flash,
+ HDD, or Intel® Optane⢠operating in the AppDirect Mode can be
used as a storage device.
+ </p>
+
+ <img class="img-responsive diagram-right"
src="/images/durable_memory.png" />
+ <p>
+ Ignite takes full control of its memory tier by allocating and
managing off-heap regions. Each Ignite
+ server node allocates memory regions during bootstrap, splits the
regions into pages, and keeps data
+ records with indexes in those pages. Java heap is used to keep
temporary objects such as query result
+ sets, metrics samples, and objects generated by your application
code. All these objects are garbage
+ collected eventually.
+ </p>
+ <p>
+ If you select the native persistence as the disk tier, then most
of the processing will still take place
+ in memory on cached data, but, with a full copy stored on disk. If
any record is missing in memory,
+ Ignite will read it from disk, allowing you to persist much larger
data sets than you can cache in memory.
+ This also eliminates the need for time-consuming memory warm-ups
on restarts. As soon as your cluster
+ reconnects after a restart, Ignite will serve most of the data
from disk warming up the memory tier in
+ the background.
+ </p>
+
+ <h2>Multi-Tier Storage Usage Modes</h2>
+
+ <table class="table table-bordered table-striped" name="Deployment
Options Features">
+ <thead>
+ <tr>
+ <th width="35%" class="left">Mode</th>
+ <th>Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td class="left">In-Memory</td>
+ <td>
+ <p>
+ The whole data set is available in memory only. In
order to survive node failures, we
+ recommend keeping at least one backup copy of the
data across the cluster. DRAM or
+ Intel® Optane⢠operating in the Memory Mode can
be used as a storage device.
+ </p>
+
+ <p>
+ <strong>Use cases</strong>: general in-memory
caching, high-performance
+ computing, web-session caching, real-time
processing of continuous data streams.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="left">In-Memory + External Database</td>
+ <td>
+ <p>
+ Ignite is deployed as a distributed caching layer
on top of an existing external database.
+ This mode is for accelerating disk-based databases
and your services with APIs that
+ interact with them.
+ </p>
+
+ <p>
+ <strong>Use cases</strong>: acceleration of
services and APIs with write-through and
+ write-behind capability, to an external database.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td class="left">In-Memory Cache + Native Persistence</td>
+ <td>
+ <p>
+ 100% of data is persisted to disk, and the same or
smaller amount is cached in memory. The
+ more data is cached, the faster is the
performance. The disk serves as the primary storage
+ that survives any cluster failures and restarts.
There is no need for memory warm-ups on
+ restarts since Ignite can serve data from disk.
SSD, Flash, HDD or Intel® Optane⢠operating
+ in the AppDirect Mode can be used as a storage
device.
+ </p>
+
+ <p>
+ <strong>Use cases</strong>: Ignite as an in-memory
database or digital integration hub
+ with the active persistence layer.
+ </p>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+
+ <h2 id="partitioning">
+ Partitioning & Replication
+ </h2>
+ <p>
+ Depending on the configuration, Ignite can both partition or
replicate data across the cluster. In the
+ replicated mode, each cluster node keeps a full copy of the
data, but the size of a replicated cache is
+ limited by the amount of memory available on the node. In the
partitioned mode, Ignite spreads the data
+ across all the cluster nodes evenly, allowing you to store
much more than what can fit in a single machine.
+ </p>
+
+ <h2 id="durability">
+ Durability and Consistency
+
+ </h2>
+ <p>
+ Ignite provides the following ACID guarantees across the
cluster:
+ </p>
+
+ <ul >
+ <li>Committed transactions always survive failures.</li>
+ <li>
+ The cluster can always be recovered to the latest
successfully committed transaction.
+ </li>
+ </ul>
+
+
+ <h2 id="write-ahead-log">
+ Write-Ahead Logging and Checkpointing
+
+ </h2>
+ <p>
+ If Ignite native persistence is selected as a disk tier, then
every time a record is updated in memory,
+ the change is added to the write-ahead log (WAL). The purpose
of the WAL is to propagate updates to disk
+ in the fastest way possible and provide a consistent recovery
mechanism that supports full cluster failures.
+ </p>
+
+ <p>
+ As WAL grows, it periodically gets checkpointed to the main
storage. Checkpointing is the process of
+ copying dirty pages from the memory tier to the partition
files on disk. A dirty page is a page that was
+ updated in memory, was appended to WAL, but was not written to
the respective partition file on disk yet.
+ </p>
+
+ <div class="jumbotron jumbotron-fluid">
+ <div class="container">
+ <div class="display-6 title">Learn More</div>
+ <hr class="my-4">
+ <div class="row">
+ <div class="col-6 col-xs-12">
+ <ul>
+ <li>
+ <p><a
href="https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood";
target="docs">Multi-Tier Storage Implementation Details <i class="fa
fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a href="/arch/persistence.html"> Native
Persistence <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a href="/features/datagrid.html"> Ignite as an
In-Memory Data Grid <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ </ul>
+ </div>
+ <div class="col-6 col-xs-12">
+ <ul>
+ <li>
+ <p><a href="/use-cases/in-memory-database.html">
Ignite as an In-Memory Database <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a href="/use-cases/dih.html"> Ignite as a
Digital Integration Hub <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a href="/use-cases/hpc.html"> Ignite for High
Performance Computing <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
</div>
</div>
- </div>
- </div>
-
- </div>
- </article>
-<!--#include virtual="/includes/footer.html" -->
+ </article>
+
+ <!--#include virtual="/includes/footer.html" -->
+
<!--#include virtual="/includes/scripts.html" -->
</body>
</html>
Modified: ignite/site/branches/ignite-redisign/arch/persistence.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/arch/persistence.html?rev=1875164&r1=1875163&r2=1875164&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/arch/persistence.html (original)
+++ ignite/site/branches/ignite-redisign/arch/persistence.html Fri Mar 13
15:56:03 2020
@@ -55,67 +55,66 @@ under the License.
<article>
<div class="container">
<h1>Apache Ignite <strong>Native Persistence</strong></h1>
- <p>
+ <img class="img-responsive" src="/images/native_persistence.png"
alt="Apache Ignite Native Persistence"/></a>
+ <p>
Even though Apache Ignite is broadly used as a caching layer on
top of external databases, it
- comes with its native persistence that is a distributed, ACID, and
SQL-compliant disk-based
- store.
- The native persistence integrates into the Ignite multi-tier
storage as a disk tier that can
- be turned on to let Ignite store more data on disk than it can
cache in memory and to enable
+ comes with its native persistence - a distributed, ACID, and
SQL-compliant disk-based
+ store. The native persistence integrates into the Ignite
multi-tier storage as a disk tier that
+ can be turned on to let Ignite store more data on disk than it can
cache in memory and to enable
fast cluster restarts.
</p>
<p>
With native persistence enabled, Ignite always stores a superset
of data on disk, and caches as
- much as
- it can in memory. For example, if your application stores 200
records in an Ignite cluster and
- your
- memory capacity allows caching only 150 of them, then those 150
records will be served from
- memory while
- the rest 50 from disk whenever the application requests them.
+ much as it can in memory. For example, if your application needs
to store 200 records in an
+ Ignite cluster and the memory capacity allows caching only 150
records, then all 200 will be
+ stored on disk, out of which 150 will be served from memory while
the rest 50 from disk whenever
+ the application requests them.
</p>
- <a href="/images/native_persistence.png"><img class="img-responsive
diagram-right" src="/images/native_persistence.png" alt="Apache Ignite Native
Persistence"/></a>
-
-
- <h2>Ignite Persistence vs. External Databases</h2>
- <p>
- The native persistence has the following advantages over external
databases that can also be used as
- the disk tier in Ignite:
- </p>
- <ul class="page-list" >
- <li>
- An ability to cache a subset of the data - the native
persistence always stores 100% of data on
- disk and lets you cache as much as required in memory.
- </li>
- <li>
- An ability to query data from disk - if any record is missing in
memory, then Ignite takes it from
- disk. This is supported for all the APIs including SQL.
- </li>
- <li>
- Instantaneous cluster restarts - Ignite becomes fully
operational from disk upon a cluster
- startup or restarts without requiring to preload or warm up the
memory tier.
- </li>
- </ul>
-
- <h2>Write-Ahead Logging and Checkpointing</h2>
- <p>
- If Ignite native persistence is
selected as a disk tier, then every time a record is updated in memory, the
change is added to the write-ahead log (WAL). The purpose of the WAL is to
propagate updates to disk in the fastest way possible and provide a consistent
recovery mechanism that supports full cluster failures.</p>
-
- <p>As WAL grows, it periodically gets
checkpointed to the main storage. Checkpointing is the process of copying dirty
pages from the memory tier to the partition files on disk. A dirty page is a
page that was updated in memory, was appended to WAL, but was not written to a
respective partition file on disk yet.
- </p>
-
+
+ <h2>Ignite Persistence vs. External Databases</h2>
+ <p>
+ The native persistence has the following advantages over external
databases:
+ </p>
+ <ul>
+ <li>
+ The ability to cache a subset of the data - the native
persistence always stores 100% of data on
+ disk and lets you cache as much as required in memory.
+ </li>
+ <li>
+ The ability to query data from disk - if any record is missing
in memory, then Ignite reads it from
+ disk. This is supported for all the APIs including SQL.
+ </li>
+ <li>
+ Instantaneous cluster restarts - Ignite becomes fully
operational from disk upon a cluster
+ startup or restarts without requiring to preload or warm up
the memory tier.
+ </li>
+ </ul>
- <h2>Durability</h2>
- <p>
- Ignite provides strong ACID durability guarantees to the data:
- </p>
+ <h2>Write-Ahead Logging and Checkpointing</h2>
+ <p>
+ If Ignite native persistence is selected as a disk tier, then
every time a record is updated in memory,
+ the change is added to the write-ahead log (WAL). The purpose of
the WAL is to propagate updates to disk
+ in the fastest way possible and provide a consistent recovery
mechanism that supports full cluster
+ failures.
- <ul class="page-list" >
- <li>
- Committed transactions always survive failures.
- </li>
- <li>
- The cluster can always be recovered to the latest
successfully committed transaction.
- </li>
- </ul>
+ As WAL grows, it periodically gets checkpointed to the main
storage. Checkpointing is the process of
+ copying dirty pages from the memory tier to the partition files on
disk. A dirty page is a page that was
+ updated in memory, was appended to WAL, but was not written to the
respective partition file on disk yet.
+ </p>
+
+ <h2>Durability</h2>
+ <p>
+ Ignite native persistence provides the following ACID guarantees
across the cluster:
+ </p>
+
+ <ul>
+ <li>
+ Committed transactions always survive failures.
+ </li>
+ <li>
+ The cluster can always be recovered to the latest successfully
committed transaction.
+ </li>
+ </ul>
<div class="jumbotron jumbotron-fluid">
<div class="container">
@@ -150,9 +149,7 @@ under the License.
</div>
</div>
</div>
- </div>
-
-
+ </div>
</div><!-- end .container -->
</article>
<!--#include virtual="/includes/footer.html" -->
Modified: ignite/site/branches/ignite-redisign/features/sql.html
URL:
http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/features/sql.html?rev=1875164&r1=1875163&r2=1875164&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/features/sql.html (original)
+++ ignite/site/branches/ignite-redisign/features/sql.html Fri Mar 13 15:56:03
2020
@@ -48,100 +48,105 @@ under the License.
<!--#include virtual="/includes/sh.html" -->
</head>
<body>
-<!--#include virtual="/includes/header.html" -->
+
+ <!--#include virtual="/includes/header.html" -->
<article>
- <div class="container">
- <h1>Distributed ANSI SQL <strong>With JOINs</strong></h1>
-
- <p>
- Apache Ignite comes with ANSI-99 compliant, horizontally scalable,
and fault-tolerant SQL engine.
- That allows you to interact with Ignite as with a regular SQL
database using JDBC, ODBC drivers,
- or native SQL APIs available for Java, C#, C++, Python, and other
programming languages.
- </p>
- <p>
- Ignite supports all DML commands, including SELECT, UPDATE, INSERT,
and DELETE
- queries as well as a subset of DDL commands relevant for distributed
systems.
- </p>
-
- <img class="img-responsive diagram-right" alt="SQL Database diagram"
src="/images/sql_database.png" />
-
- <h2>SQL Joins</h2>
- <p>
- Ignite fully supports distributed joins for advanced querying
needs. A distributed join is a SQL statement
- with a join clause that combines two or more tables. If the
tables are joined on the partitioning column
- (affinity or primary key), the join is called a co-located
join. Otherwise, if the tables were not
- co-located initially, then Ignite does the join in a
non-colocated fashion. The co-located joins avoid
- data shuffling between nodes, minimizes network usage, thus,
performing much faster than a non
- co-located counterpart.
- </p>
-
- <h2>SQL and In-Memory Mode</h2>
- <p>
- Apache Ignite can function in a pure in-memory mode when all
data and indexes are located solely in memory.
- In this mode, Ignite SQL shows the highest performance as long
as all the data is served from memory,
- and there is no need to update the disk tier.
- </p>
-
- <h2>SQL and Native Persistence</h2>
- <p>
- In this mode, Ignite persists 100% of data and indexes in the
native persistence while caching as much
- as possible in memory. Ignite SQL engine does not require to
cache an entire data set in memory to
- operate correctly. If the engine finds that any record is not
cached, then it will be taken from disk.
- Your application merely executes SQL queries, and Ignite gets
the records from both memory and disk
- automatically.
- </p>
- <p>
- On cluster restarts, Ignite reads data and indexes from disk,
eliminating the need for memory warm-up.
- That significantly decreases the time of any potential
downtimes.
- </p>
-
- <h2>SQL and 3rd Party Databases</h2>
- <p>
- Ignite can be used as a caching layer for external databases
such as RDBMS, NoSQL, or Hadoop.
- In this mode, the Ignite SQL engine requires to cache all the
data needed for SQL queries in memory as
- long as the engine does not support federated queries at the
moment.
- </p>
-
- <p>
- If federate queries between Ignite and an external database
are required, then you can consider Ignite
- integration for Spark -- DataFrames API can join data stored
in Ignite and other systems.
- </p>
-
- <div class="jumbotron jumbotron-fluid">
- <div class="container">
- <div class="display-6 title">Learn More</div>
- <hr class="my-4">
- <div class="row">
- <div class="col-6 col-xs-12">
- <ul>
- <li>
- <p><a
href="https://apacheignite-sql.readme.io/docs/how-ignite-sql-works";
target="docs">Ignite SQL implementation details <i class="fa
fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a
href="https://apacheignite-sql.readme.io/docs/distributed-joins";
target="docs">Distributed JOINs <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a
href="https://apacheignite-sql.readme.io/docs/sql-reference-overview";
target="docs">SQL Reference <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- </ul>
- </div>
- <div class="col-6 col-xs-12">
- <ul>
- <li>
- <p><a href="/use-cases/spark-acceleration.html">Apache
Ignite and Spark <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- <li>
- <p><a href="/arch/multi-tier-storage.html">Multi-Tier
Storage <i class="fa fa-angle-double-right"></i></a></p>
- </li>
- </ul>
- </div>
- </div>
- </div>
- </div>
-
+ <div class="container">
+ <h1>Distributed ANSI SQL <strong>With JOINs</strong></h1>
+
+ <img class="img-responsive diagram-right" alt="SQL Database diagram"
src="/images/sql_database.png" />
+ <p>
+ Apache Ignite comes with ANSI-99 compliant, horizontally scalable,
and fault-tolerant SQL engine
+ allowing you to interact with Ignite as with a regular SQL
database using JDBC, ODBC drivers, or
+ native SQL APIs available for Java, C#, C++, Python, and other
programming languages.
+
+ </p>
+ <p>
+ Ignite supports all DML commands, including SELECT, UPDATE,
INSERT, and DELETE queries as well
+ as a subset of DDL commands relevant for distributed systems.
+ </p>
+
+ <h2>SQL Joins</h2>
+ <p>
+ Ignite fully supports distributed joins for advanced querying
needs. A distributed join is a SQL statement
+ with a join clause that combines two or more tables. If the tables
are joined on the partitioning column
+ (affinity or primary key), the join is called a co-located join.
Otherwise, if the tables were not
+ co-located initially, then Ignite does the join in a non-colocated
fashion. Co-located joins avoid data
+ shuffling between nodes and minimize network usage, thus,
performing much faster than a non-colocated
+ counterpart.
+ </p>
+
+ <h2>SQL and In-Memory Mode</h2>
+ <p>
+ Apache Ignite can function in a pure in-memory mode when all the
data and indexes are located solely in
+ memory. In this mode, Ignite SQL shows the highest performance
since all the data is served from memory
+ with no usage of the disk tier at all.
+ </p>
+
+ <h2>SQL and Native Persistence</h2>
+ <p>
+ In this mode, Ignite persists 100% of data and indexes in the
native persistence while caching as much
+ as possible in memory. Ignite SQL engine does not require to cache
an entire data set in memory to
+ operate correctly. If the engine finds that a record is not
cached, then it will read the record from
+ disk. Your application only executes SQL queries, and Ignite gets
the records from both memory and disk
+ automatically.
+ </p>
+ <p>
+ On cluster restarts, Ignite reads data and indexes from disk,
eliminating the need for memory warm-up,
+ which significantly decreases the time of any potential downtimes.
+
+ </p>
+
+ <h2>SQL and 3rd Party Databases</h2>
+ <p>
+ Ignite can be used as a caching layer for external databases such
as RDBMS, NoSQL, or Hadoop. In this mode,
+ the Ignite SQL engine requires caching all the data needed for SQL
queries in memory since the engine
+ currently does not support federated queries.
+ </p>
+
+ <p>
+ If federated queries between Ignite and an external database are
required, then you can consider Ignite
+ integration for Spark, where the DataFrames API can join the data
stored in Ignite and other systems.
+ </p>
+
+ <div class="jumbotron jumbotron-fluid">
+ <div class="container">
+ <div class="display-6 title">Learn More</div>
+ <hr class="my-4">
+ <div class="row">
+ <div class="col-6 col-xs-12">
+ <ul>
+ <li>
+ <p><a
href="https://apacheignite-sql.readme.io/docs/how-ignite-sql-works";
target="docs">Ignite SQL implementation details <i class="fa
fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a
href="https://apacheignite-sql.readme.io/docs/distributed-joins";
target="docs">Distributed JOINs <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a
href="https://apacheignite-sql.readme.io/docs/sql-reference-overview";
target="docs">SQL Reference <i class="fa fa-angle-double-right"></i></a></p>
+ </li>
+ </ul>
+ </div>
+ <div class="col-6 col-xs-12">
+ <ul>
+ <li>
+ <p><a
href="/use-cases/spark-acceleration.html">Apache Ignite and Spark <i class="fa
fa-angle-double-right"></i></a></p>
+ </li>
+ <li>
+ <p><a
href="/arch/multi-tier-storage.html">Multi-Tier Storage <i class="fa
fa-angle-double-right"></i></a></p>
+ </li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ </div>
+
</div>
</article>
+
+
<!--#include virtual="/includes/footer.html" -->
+
<!--#include virtual="/includes/scripts.html" -->
</body>
</html>
