Anything & Everything

Amplify’d from www.databasejournal.com

The advent of 64-bit support on most processors and operating systems has opened up more possibilities for storing greater amounts of data in buffer pools during the past couple of years. However, you still need to have enough physical memory in your server to support those pools, and even at today’s relatively low prices it rapidly becomes uneconomical to configure systems beyond a few hundreds of Gigabytes.

Enter the SSD So, what else has changed to open a new chapter in this story? One answer to that question is the SSD, or Solid State Disk (aka Solid State Drive). This is essentially a device that uses flash-based, non-volatile memory to store data, while presenting itself to the outside world (and the operating system) as just another hard disk drive. Compared to conventional magnetic media, SSDs are typically somewhat more expensive, but much faster (up to 70 times the number of I/O operations per second), quieter and use significantly less power. As such, SSDs represent a compromise between the outright speed of conventional memory access and the low cost of a traditional magnetic disk drive (see diagram below).

SSDs have been around for while but as the chart above indicates, they are falling rapidly in price: they are currently around 10 times the price of a Hard Disk Drive (HDD) on a cost-per-megabyte basis but that is expected to fall to just 2-3 times over the next 12-24 months. Today, the SSD is mainly being used as a straightforward replacement for conventional HDDs. For a DB2 system that is predominantly I/O-constrained, moving the high-access tablespaces onto SSDs can give some dramatic and immediate performance benefits with relatively minor implementation cost and effort. At the same time, many database vendors are beginning to extend and enhance their traditional RDBMs systems to make them “SSD aware” and specifically exploit their unique characteristics. For example, some vendors are looking at the possibility of multi-tier cache systems based on the “temperature” of the data, as shown in the diagram below.

In this kind of environment, conventional buffer pools would continue to host the “hot” data exactly as they currently do. However, the system administrator can also create a new type of larger second-level buffer pool on an SSD, aimed at hosting “warm” data, which may be needed again shortly. Instead of “casting out” updated pages all the way back to the disk when the conventional buffer pool needs to free up space, the page will instead be moved to the second-level pool where it can be quickly and efficiently retrieved again if needed. Conventional “cast out” processing can occur to write updated pages from either the conventional or level-2/SSD buffer pool to disk when they become “cold”.

Dedicated Data in Memory Database Systems

Finally, no discussion on in-memory databases would be complete without at least a brief mention of the high performance in-memory database systems that have been built from the ground up to support today’s search and social networking sites. Google, Twitter, Facebook and many others all rely on various forms of in-memory database to provide rapid response times in the face of ever-increasing data volumes. Read more at www.databasejournal.com