You can deploy
GemFire XD as a distributed cache for data that is managed in a traditional
relational database system. GemFire XD offers several strategies for using the
product as a database cache.
Considerations for Auto-Generated Keys
If cached tables require automatic generation of identity column
values, then you should use GemFire XD to automatically generate the key values
disable generated keys in the backend database. If the backend
database also generates key values, then inserts can fail if GemFire XD has
already generated the key.
Note: GemFire XD supports automatic generation of identity column values, but it does
not support generating a sequence of key values. If a sequence is required, then
consider using a stored procedure to obtain the next sequence value from the backend
database before inserting the row in GemFire XD.
When you use the GemFire XD DBSynchronizer implementation to synchronize tables
that have an identity column, identity column values are not automatically applied
to the synchronized database. Instead, the full DML statement is delivered to the
underlying database. See Restrictions and Limitations
for more information about DBSynchronizer limitations.
Lazy-Loading the Cache
Application query requests are first
attempted in GemFire XD. On a miss, a loader that implements lazy loading is
invoked that can fetch the data from a backend database. GemFire XD only supports
primary key-based queries when the table is lazily loaded. It is impractical
(too expensive) to determine the subset of the rows missing in GemFire XD and
construct a query to the backend database that only fetches the missing rows.
It is also typical for applications to configure least-recently-used (LRU)
caching where the cache optimizes the available memory by evicting the least
frequently used rows. Applications can only issue primary key-based queries on
tables that are configured for eviction. For more information, see
Using a RowLoader to Load Existing Data
All updates can be synchronously or asynchronously written back to the
database using a 'writer' or the built in
DBSynchronizer. For tables that are
identical in structure to the backend database, applications can asynchronously
"write behind" if you configure the database URL for the backend database.
GemFire XD offers several caching strategies that involve preloading
- Preload database.
Load the entire database at bootstrap time into GemFire XD. If all updates are
going through GemFire XD, it is unnecessary to resynchronize the state from the
backend database. The data bootstrapping process is outlined below.
With this choice, the tables are loaded with the
entire data set from the backend database and all queries can directly be
executed on GemFire XD data stores.
- Preload "hot" data and
lazy-load the rest. If the data set in the backend database is very large,
a better option would be to maintain all the "hot" tables in GemFire XD and lazy
load the historical data into "historical" tables. With this design, the entire
supported SQL syntax can be used on fully populated "hot" tables, but, only
primary key based queries can be issued on historical tables. Typically, these
historical tables will be configured for LRU eviction.
Integration with Hibernate
GemFire XD can also be integrated in object relational mapping products such as Hibernate and
provide an L2 cache - entire query result sets can be cached in GemFire XD. Updates
done using the Hibernate API will be synchronously propagated to the database and
query result sets will be invalidated in GemFire XD.
See GemFire XD Hibernate Dialect
for information about using the GemFire XD dialect file with your Hibernate
Exporting and Transforming an Existing Schema
Application developers can use
a tool such as
export an existing relational database schema, transform it to GemFire XD, and
import the new schema along with data into a GemFire XD cluster.