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/13 15:56:03 UTC
svn commit: r1875164 - in /ignite/site/branches/ignite-redisign:
arch/multi-tier-storage.html arch/persistence.html features/sql.html
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>