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/02/11 00:50:46 UTC
svn commit: r1873877 -
/ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html
Author: dmagda
Date: Tue Feb 11 00:50:45 2020
New Revision: 1873877
URL: http://svn.apache.org/viewvc?rev=1873877&view=rev
Log:
applying an edited version for the in-memory cache use case
Modified:
ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html
Modified: ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html
URL: http://svn.apache.org/viewvc/ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html?rev=1873877&r1=1873876&r2=1873877&view=diff
==============================================================================
--- ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html (original)
+++ ignite/site/branches/ignite-redisign/use-cases/in-memory-cache.html Tue Feb 11 00:50:45 2020
@@ -57,10 +57,10 @@ under the License.
<div class="col-sm-12 col-md-12 col-xs-12" style="padding:0 0 20px 0;">
<div class="col-sm-6 col-md-6 col-xs-12" style="padding-left:0;">
<p>
- Distributed in-memory cache that supports ANSI SQL, ACID transactions, and co-located
- computations is one of the usage scenarios Apache Ignite is selected for. From sessions and
- APIs caching to databases and microservices acceleration, Ignite provides all essential
- components needed to speed things up.
+ One of the usages of Apache Ignite is as a distributed in-memory cache that supports ANSI SQL,
+ ACID transactions, and co-located computations. From APIs and sessions caching to databases and
+ microservices acceleration, Ignite provides all essential components required to speed up
+ applications.
</p>
</div>
<div class="col-sm-6 col-md-5 col-xs-12" style="padding-right:0">
@@ -69,63 +69,63 @@ under the License.
</div>
<p>
- As with classic distributed caches, you would span an Ignite cluster across several interconnected
- physical or virtual machines letting it utilize all the available memory and CPU resources. However,
- the difference comes in a way you can use the cluster once it's up and running. In addition to
- standard key-value APIs, you can run distributed SQL queries joining and grouping various data sets.
- If strong consistency is required, you can execute multi-records and cross-cache ACID transactions in
- both pessimistic and optimistic modes. Next, if an application runs compute or data-intensive logic,
- you can minimize data shuffling with network utilization by running co-located computations and
- distributed machine learning APIs right on the cluster nodes that store your data.
+ As with classic distributed caches, you can span an Ignite cluster across several interconnected
+ physical or virtual machines letting it utilize all the available memory and CPU resources. But the
+ difference lies in the way you can use the cluster. In addition to standard key-value APIs, you can
+ run distributed SQL queries joining and grouping various data sets. If strong consistency is required,
+ you can execute multi-records and cross-cache ACID transactions in both pessimistic and optimistic
+ modes. Additionally, if an application runs compute or data-intensive logic, you can minimize data
+ shuffling and network utilization by running co-located computations and distributed machine learning
+ APIs right on the cluster nodes that store your data.
+
</p>
<p>
- There are two primary deployment strategies for Ignite as an in-memory cache -- the cache-aside one and
- read-through/write-through caching. Let's review two of them.
+ There are two primary deployment strategies for Ignite as an in-memory cache -- the cache-aside
+ deployment and read-through/write-through caching. Let's review both of them.
</p>
<div class="page-heading">Cache-Aside Deployment</div>
<p>
- With the cache-aside deployment strategy, a cache is deployed separately from a primary data store and
- might not even know that the latter exists. An application or change-data-capture process (CDC) becomes
- responsible for data synchronization between these two storage locations. For instance, if any record
- gets updated in the primary store, then its new value needs to be replicated to the cache.
+ With the cache-aside deployment strategy, a cache is deployed separately from the primary data store
+ and might not even know that the latter exists. An application or change-data-capture process (CDC)
+ becomes responsible for data synchronization between these two storage locations. For instance, if any
+ record gets updated in the primary data store, then its new value needs to be replicated to the cache.
</p>
<p>
- This strategy works well when the cached data is rather static and not updated frequently, or
- temporary data lag/inconsistency is allowed between the two storage locations. It's usually assumed
- that the cache and the primary store will become consistent eventually as soon as changes are replicated
- in full.
+ This strategy works well when the cached data is rather static and not updated frequently, or temporary
+ data lag/inconsistency is allowed between the two storage locations. It's usually assumed that the
+ cache and the primary store will become consistent eventually when changes are replicated in full.
</p>
<p>
If Apache Ignite is deployed in a cache-aside configuration, then its native persistence can be used as
- a disk store for Ignite data sets. The native persistence lets eliminate time-consuming data reloading
- phase from the primary store as well as a cache warm-up step. Furthermore, since the native persistence
- always keeps a full copy of data on disk, you are free to cache a subset of records in memory. If Ignite
- finds that a record is missing in memory, then it will read it from disk automatically regardless of the
- API you use -- let it be SQL, key-value, or scan queries.
+ a disk store for Ignite data sets. The native persistence allows eliminating the time-consuming cache
+ warm-up step. Furthermore, since the native persistence always keeps a full copy of data on disk,
+ you are free to cache a subset of records in memory. If Ignite finds that a record is missing in memory,
+ then it will read it from disk automatically regardless of the API you use -- be it SQL, key-value,
+ or scan queries.
</p>
<div class="page-heading">Read-Through/Write-Through Caching</div>
<p>
- The read-through/write-through caching strategy can also be classified as an in-memory data grid type of
- deployment. When Apache Ignite is deployed as a data grid, the application layer starts treating Ignite
- as the primary store. The applications write to and read from Ignite while the latter ensures that any
- underlying external databases stay updated and consistent with the in-memory data.
+ The read-through/write-through caching strategy can also be classified as an in-memory data grid type
+ of deployment. When Apache Ignite is deployed as a data grid, the application layer starts treating
+ Ignite as the primary store. While the applications write to and read from Ignite, the latter ensures
+ that any underlying external databases stay updated and consistent with the in-memory data.
</p>
<p>
This strategy is favorable for architectures that need to accelerate existing disk-based databases or
create a shared caching layer across many disconnected data sources. Ignite integrates with many
- databases out-of-the box and can write-through or write-behind all the changes to them. This also
- includes ACID transactions - Ignite will coordinate and commit a transaction across its own in-memory
+ databases out-of-the-box and can write-through or write-behind all the changes to them. This also
+ includes ACID transactions - Ignite will coordinate and commit a transaction across its in-memory
cluster as well as to a relational database.
</p>
<p>
The read-through capability implies that a cache can read data from an external database if a record is
- missing in memory. Ignite fully supports this capability for key-value APIs. However, if Ignite SQL is
- at use then you have to preload an entire data set in memory first. (Note, that Ignite SQL can query
- data on disk only if it's located in its native persistence).
+ missing in memory. Ignite fully supports this capability for key-value APIs. However, when using Ignite
+ SQL, you have to preload the entire data set in memory first (Ignite SQL can query data on
+ disk only if it is located in its native persistence).
</p>
<div class="page-heading">Learn More</div>
<p>