Databases Reference
In-Depth Information
risk profiles. In order to develop a recommendation, the stock trading application needs
to store a large set of stock histories. Every few seconds the application needs to perform
map-reduce analytics across either all or a selected set of stock symbols (such as a market
sector), comparing potential returns, evaluating risk profiles, and optimizing the overall
trading strategy. This ability to scan a large, fast-changing data set in real time gives the
trading analyst an important new tool for detecting changing market conditions and
optimizing the selection of trades to place.
Now let's discuss how an in-memory data grid actually works. First of all, it is important
to understand that an in-memory data grid is not the same as an in-memory database.
Typical examples of in-memory databases are Oracle TimesTen,
SAS
® In-
Database
and SAP®
HANA. In-memory databases are full database products that simply reside in memory.
As a result of being a full-blown database, they also carry the weight and overhead of
database management features. In-memory data grid is different: no tables, indexes,
triggers, stored procedures, process managers etc., just plain storage.
The data model used in the in-memory data grid is key-value pairs. Unlike traditional
systems where keys and values are often limited to byte arrays or strings, with in-memory
data grids you can use any domain object as either value or key. Most in-memory data
grids are written in Java, thus they have the ability to support a wide variety of data types
ranging from simple data types such as a string or number, to complex objects. In-memory
data grid has the ability to interface with the distributed data store as with a simple hash
map. Being able to work with domain objects directly is one of the main differences
between in-memory data grids and in-memory databases. With the in-memory databases,
users still need to perform object-to-relational mapping, which typically adds significant
performance overhead.
Data consistency is one of the main differences between in-memory data grids and
NoSQL databases. NoSQL databases are usually designed on top of the eventual consistency
approach where data is allowed to be inconsistent for a period of time as long as it will
become consistent eventually. In-memory data grids are positioned as complementary with
distributed caching and can be effectively leveraged to support following core patterns:
•
Transactional “write through.”
Changes are synchronously
updated in databases. The update to the in-memory data grid is
successful if and only if the update is also in the database.
•
Asynchronous “write behind.”
Queue the updates across the
in-memory data grid cluster and transfer the changes in batches
to the backend repository. The queuing can be configured to be
in-memory replicated for high availability.
Figure
8-3
shows an in-memory data grid with a key set of
{k1, k2, k3}
where each key
belongs to a different node.
