An in-memory database (IMDB; also main memory database system or MMDB or memory
resident database) is a database management system that primarily relies on main memory for computer
data storage. It is contrasted with database
management systems that employ a disk
storage mechanism. Main memory databases are faster than
disk-optimized databases since the internal optimization algorithms are simpler
and execute fewer CPU instructions. Accessing data in memory eliminates seek time when querying the data, which provides faster and more
predictable performance than disk.
An in-memory database
(IMDB, also known as a main memory database or MMDB) is a database whose data
is stored in main memory to facilitate faster response times. Source data is loaded
into system memory in a compressed, non-relational format. In-memory databases
streamline the work involved in processing queries.
An IMDB is one type
of analytic database,
which is a read-only system that stores historical data on metrics for business
intelligence/business analytics (BI/BA) applications, typically as part of a data warehouse or data
mart. These systems allow users to run queries and
reports on the information contained, which is regularly updated to incorporate
recent transaction data from an organization’s operational systems.
In addition to
providing extremely fast query response times, in-memory analytics can reduce or
eliminate the need for data indexing and storing pre-aggregated data in OLAPcubes or aggregate tables.
This capacity reduces IT costs and allows faster implementation of BI/BA
applications.
Three developments in
recent years have made in-memory analytics increasingly feasible: 64-bit computing, multi-core servers and
lower RAM prices.
Applications where response time is critical, such as those
running telecommunications network equipment and mobile advertising networks, often use main-memory databases. IMDBs have gained a lot
of traction, especially in the data
analytics space, starting in the mid-2000s - mainly due to less expensive RAM.
With the introduction of non-volatile
random access memory technology, in-memory
databases will be able to run at full speed and maintain data in the event of
power failure.
There is an obvious
performance benefit in the reduced latency in-memory
database solutions bring, even over heavily cached systems, which can only
optimise database read requests.
But in-memory
databases are subtler than that. This is because they provide an opportunity to
optimise the way data is managed compared to traditional databases on
disk-based media.
When all data is kept in memory, the need to deal with issues arising from the use of
traditional spinning disks disappears. This means, for example, there is no
need to maintain additional cache copies of data and manage synchronisation between
them.
Row Format vs.
Column Format
Oracle Database has traditionally stored data in a row format. In a
row format database, each new transaction or record stored in the database is
represented as a new row in a table. That row is made up of multiple columns, with
each column representing a different attribute about that record. A row format
is ideal for online transaction systems, as it allows quick access to all of
the columns in a record since all of the data for a given record are kept
together in-memory and on-storage.
A column format database stores each of the attributes about a
transaction or record in a separate column structure. A column format is ideal
for analytics, as it allows for faster data retrieval when only a few columns
are selected but the query accesses a large portion of the data set.
But what happens when a DML operation (insert, update or delete)
occurs on each format? A row format is incredibly efficient for processing DML
as it manipulates an entire record in one operation i.e. insert a row, update a
row or delete a row. A column format is not so efficient at processing row-wise
DML: In order to insert or delete a single record in a column format all of the
columnar structures in the table must be changed.
Up until now you have been forced to pick just one format and suffer
the tradeoff of either sub-optimal OLTP or sub-optimal analytics performance.
Oracle Database In-Memory (Database In-Memory) provides the best of
both worlds by allowing data to be simultaneously populated in both an
in-memory row format (the buffer cache) and a new in-memory column format.
Note that the dual-format architecture does not double memory requirements. The in-memory
column format should be sized to accommodate the objects that must be stored in
memory, but the buffer cache has been optimized for decades to run effectively
with a much smaller size than the size of the database.
In
practice it is expected that the dual-format architecture will impose less than
a 20% overhead in terms of total memory requirements. This is a small price to
pay for optimal performance at all times for all workloads.
Figure 1. Oracle’s unique dual-format architecture
With Oracle’s unique approach, there remains a single copy of the
table on storage, so there are no additional storage costs or synchronization
issues. The database maintains full transactional consistency between the row and
the columnar formats, just as it maintains consistency between tables and
indexes. The Oracle Optimizer is fully aware of the column format: It
automatically routes analytic queries to the column format and OLTP operations
to the row format, ensuring outstanding performance and complete data
consistency for all workloads without
any application changes.
List of in-memory databases
|
Name
|
Developer
|
Availability
|
License
|
Description/Notes
|
|
Oracle Coherence
|
Oracle Corporation
|
Proprietary with developer download
|
For Java, relational, distributed
|
|
|
Oracle Exalytics
|
Oracle Corporation
|
Proprietary
|
Appliance
|
|
|
2014
|
Proprietary
|
RDBMS Oracle 12c contains an option for in-memory
technology (additional licenses required).
|
I hope you all have enjoyed reading this article. Comments are welcome....
No comments:
Post a Comment