optimized for in-memory data. The faster are the interactions between the application and the server the bigger is the gain brought by MME. Running the applications locally is key to uncover that gain.

MME TCP relaxed durability

Here the term strict is replaced with relaxed. With relaxed durability, the commit acknowledgment is returned before the commit record is persistently written to the disk storage. The commit record is written to disk asynchronously, with a delay of few seconds. With relaxed durability, MME does not have to wait for I/O operations to complete, and that can be seen in the response time of write transactions. Overall, more CPU time can be utilized to process the in-memory data.

MME SMA relaxed durability

By replacing the TCP/IP based driver with an SMA driver, you ultimately bring the data as close to the application as possible, which is into the application’s process space. Shared memory access (SMA) allows the user to link the application with a library containing the whole query processing code. At this point, all obstacles in the way of bringing the data to the application with a full CPU speed are removed.

In the experiment, the disk-based database was reasonably buffered: the size of the page buffer pool (called DBE cache, in solidDB) was 20% of the total

database size. You can see that, by taking all the steps, the throughout can be increased almost 15 times, and the response time shortened to almost one tenth, compared to the worst case. Of all the steps shown, you might use only a few, but then, of course, there would also be fewer benefits. The subject of performance is further discussed in Chapter 6, “Performance and troubleshooting” on

page 147, and Chapter 7, “Putting solidDB and the Universal Cache to good use” on page 219, including the description of the TATP benchmark.

1.2 Database caching with in-memory databases

In this section, we propose that using solidDB as a cache database to a larger enterprise database can alleviate the problems caused by the database growth.

1.2.1 Databases are growing

Enterprise databases can grow to very large sizes. The application load on the database system can grow to high levels too. That can lead to a situation where the database system becomes a bottleneck. In such an overloaded system, the response times may become painfully long.

One solution might be to scale the system up (to a more powerful computer) or out (to a cluster of computers). Both alternatives are costly and may expose scalability problems.

1.2.2 Database caching off-loads the enterprise server

You can off-load the enterprise database server by moving the data out of the

server and close to where the applications are running. The solution is called database caching if the database interface in the applications can be preserved.

With database caching, all the data is still stored within the enterprise server. However, it is also replicated to smaller cache databases, typically residing in

computer nodes where the applications are running. An in-memory database is an ideal candidate for a cache database because of the performance and response time advantages

1.2.3 IBM solidDB Universal Cache

IBM solidDB Universal Cache is a product enabling cache databases for popular enterprise database products such as Oracle, DB2, IDS, Sybase ASE, and

Microsoft SQL Server. The solidDB in-memory database server maintains a cache database that contains a subset of data stored in the back-end database

(being run by any of the systems previously mentioned). The applications connect to the cache database. Additionally, the product includes an elaborate replication mechanism known as InfoSphere Change Data Capture (InfoSphere CDC) available also as a separate product from IBM. The InfoSphere CDC components are responsible for carrying the data between the back-end database and the cache database--both ways.

The replication can take the form of one-time refreshes of cached data or continuous update propagation between the systems. The continuous replication is done in an asynchronous fashion: the data is first committed on the local system (the source) and then propagated to the other system (the target). The delay is usually within a second.

Because of the asynchronous nature of the continuous replication, the replication does not delay or block the transactions at the source side. However, there is one exception: if the cache database produces more updates that can be applied to

the back-end database, the replication buffers fill-up, and a mechanism called transaction throttling is enacted. With transaction throttling, the cache database

transactions are slowed down to keep up with the pace of data replication.

The advantage of an in-memory cache database is magnified with new access methods available with solidDB. By using linked library access or shared memory

10 IBM solidDB: Delivering Data with Extreme Speed