Skip directly to content

building voltdb

In-memory database sizing – throw out conventional wisdom

Monday, June 2, 2014 - 12:00am

written by John Piekos on June 2, 2014 

Sizing an in-memory database does not follow conventional database sizing rules.

For traditional databases, you buy a decent server machine, likely one with many CPU cores and reasonable memory, and then focus on application IOPS (I/O Operations per Second). If you are really going to stress the database, you must choose disks that can support the I/O needs of your application, today and in the future. Because these systems often use many disks to achieve high I/O performance, capacity is usually an afterthought.

With in-memory databases, throw out

Introducing VoltDB DevCenter

Thursday, February 27, 2014 - 12:00am

written by Ryan Betts on February 27, 2014

As part of VoltDB 4.0, we built a developer focused landing site, VoltDB Dev-Center. You can find it on the voltdb.com main navigation under the Developers menu: “Developers > Build Your Apps”.

Dev-Center is the down-to-earth, get-out-of-my-way, show-me-how-to-build-it collection of how-to recipes, documentation and tutorials. In that spirit – I’m keeping this blog post short and to the point. We’ve brought together a new, refined tutorial, a link to the extensive online documentation, and a developer cookbook.

The cookbook currently includes

VoltDB, native memory, and you

Monday, March 3, 2014 - 12:00am

written by Ariel Weisberg on March 3, 2014 

(Originally published here.)

Target audience

This post targets other VoltDB developers who are going to be dealing with the various unconventional ways Volt now uses native memory in the Java portions of the database. It will also be of interest to other Java developers looking to step outside what is typically considered Java’s comfort zone for interacting with native memory.

What was

Out of the box Java doesn’t give you much in the way of tools for accessing native memory allocation and deallocation mechanisms like mmap or malloc.