In Memory Database Report | Electronics Seminar Topic
In Memory Database Report
The profound improvements in computer architectures over the
last decade gave rise to In-Memory Database technology. CPU performance (as
measured by circuit density) has been doubling, on average, every year and a
half Memory chips have doubled in capacity at half the cost in the same
intervals. Today, a gigabyte of physical memory for a server costs around $100.
Once prohibitive, the cost of RAM is no longer a factor in
the consideration of production-scale In-Memory Databases for front-office
applications. Back-office systems and data warehouses are still largely the
domain of disk-based databases, which may store hundreds of gigabytes of
historical data that’s rarely accessed.
Magnetic disk performance has increased much more slowly.
Thus, the performance gap between CPUs and disks has widened substantially.
Data integrity and functional richness are the other major advantages of an
IMDB product. Real-time applications impose fixed deadline on completion of
transactions.
Applications such as router have to handle a huge amount of traffic
data, in short period of time. Other application areas where there is immense
need of high performance are mobile communication and telecommunications
systems. Such applications expect very short and predictable access and
response times from the underlying storage system.
Conventional DBMS incurs a lot of disk interaction, and
cannot ensure predictable response times, hence proving itself unsuitable for
these kind of applications. For predictable and short response time, data has
to be kept in main memory.
As a result, the storage system for most of these
applications is custom-designed, and lack to ensure durability and consistency
of the data.Further, due to impedance mismatch (difference in schema
definitions), data can hardly be shared across application boundaries.
This motivates the need of some system that allows access to
shared in-memory data, ensuring ACID properties on it. One approach towards
this problem is to modify the DBMS to incorporate huge in-memory buffer.But,
storage and indexing architecture of such a system is designed for disk.
Disk
block is the unit of data access. For every access/up date of and at a item,
the system calculates its physical address. The target block is searched in
buffer pool.Now,if the buffer pool size is big enough to accommodate the whole
database, linear search will be inefficient.
If buffer pool is not big enough, page fault will occur,
resulting into disk access for the block, increasing the response time. Either
way, this approach is not suitable. This motivates the need to develop a DBMS,
whose storage and indexing components are designed for in-memory data. Such a
DBMS is Main Memory DBMS (MMDB).
In a Main Memory Database (MMDB) system, the primary copy of
the database resides in volatile main memory as opposed to Disk Resident
Database (DRDB) systems where the database is on disk. The perception of where
the data resides is important here.
With an MMDB the DBMS software is designed
assuming that the data is memory resident. With a DRDB the DMBS software is
designed assuming the data is stored on disk and I/O is required to access the
data. MMDB systems need not perform I/O operations for database applications.
Thus, they are ideal for applications that require high
Throughput and a fast response time. With the increasing demand for
high-performance systems and the steady decrease in memory cost, MMDBs have
become an attractive alternative to DRDB’s.
This is especially the case for
telephone switching applications, mobile computing applications and real-time
systems, i.e. applications that require high throughput and fast response time.
The increasing popularity of MMDBs can be illustrated by the sizable effort of
research done in this area .
The end result of In-Memory Database technology is a
significant reduction in the amount of CPU needed to complete standard database
operations – as Database technology is a significant compared to a fully-cached
RDBMS. The actual difference depends on exactly what work is being done.
Read
operations (e.g. reference data lookups) exhibit the greatest speedup Write
operations, which probably entail some logging of changes to disk to guarantee
recoverability, could be slowed down somewhat by database operations. The disk
operation. In practice, applications are almost never only reads or only.
