Disk IO operations for in-memory databases

When working with in-memory databases a lot of people discard the fact that your disk IO can still be a bottleneck. It is true that most of your operations are done in memory when working with a in-memory database. However, having slow disk I/O can dramaticly impact the performance of you operations even when using a in-memory database. You have to make some decissions in your hardware and in your application design when working with a in-memory database.

The Oracle TimesTen in memory database is a good example when talking about this subject.
Oracle TimesTen In-Memory Database (TimesTen) is a full-featured, memory-optimized, relational database with persistence and recoverability. It provides applications with the instant responsiveness and very high throughput required by database-intensive applications. Deployed in the application tier, TimesTen operates on databases that fit entirely in physical memory (RAM). Applications access the TimesTen database using standard SQL interfaces. For customers with existing application data residing on the Oracle Database, TimesTen is deployed as an in-memory cache database with automatic data synchronization between TimesTen and the Oracle Database.

As a quick introduction to the TimesTen database Oracle has provided a short, 3 minute youtube video showing what Oracle TimesTen can do;


One of the interesting topics already touched in the above video is, what will happen to my in-memory data when the server fails. The answer to this is that TimeTen will make it persistent. Making it persistent means in this case writing it to a disk. Writing data to disk means disk I/O. This means that a in-memory database is not 100% pure in-memory, it will still use your disks.

Oracle TimesTen uses durable commits to make a commit persistent. When using a durable commit the commit is not only written to the database structure which is hold in memory it is also written to disk. It is good to know that by default every commit results in a durable commit and by doing so results in disk I/O. Developers can make the decision if they will do a normal commit (durable) or a non-durable commit.

As an example, if you are building a webshop application based upon a TimesTen database you can make the decission that every item that is placed in the basket by a user is written to memory by using a non-durable commit. When the order is placed the order itself is written with a durable commit. This holds that if the database is to crash all items that a user has placed in a basket will be lost and will have to placed again, however a order that is placed is stored safely to disk and when the database is loaded into memory again during start-up this is still present.

More detailed information about durable and non-durable commits in a Oracle TimesTen database can be found in the documentation. Specially the chapter "use durable commits appropriately" is advisable to developers who are new to in-memory database architectures. 

Making non-durable commits are in general faster than durable commits. This can improve the performance of your application dramatically. However at some point you will most likely want to use a durable commit to safeguard the final transaction. In case you have a large load on your system and you have slow disk I/O this can hinder the performance of your application. In the below video from Intel you can see a example of this and how solid state disks help to improve this in the showcase shown in the video.



See Diane M. Bryant, Vice President & General Manager of the Datacenter and Connected Systems Group (DCSG) at Intel, walk through a compelling Big Data server demonstration featuring Intel® Xeon® processor-based servers and Intel® Solid-State drives running Oracle TimesTen® In-Memory Database. Chuck DuVall, Sr. Technical Engineer explains the demo details which highlight the need for solid state drive speed for persistent data while running In-memory databases.