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>
