Skip directly to content

voltdb

Announcing VoltDB 4.0: Enhanced In-Memory Analytics and Online Elasticity

Wednesday, January 29, 2014 - 12:00am

written by John Piekos on January 29, 2014

The VoltDB engineering team is pleased to announce that VoltDB 4.0 is now available!

Bruce Reading, the VoltDB CEO is fond of saying that VoltDB contains lots of “yummy goodness”, and, while that is not a term we engineers use often, VoltDB v4.0 does indeed include a lot of new features.  The highlights of VoltDB v4.0 include:

  • Enhanced in-memory analytics capabilities with a host of new SQL support.
  • Greatly improved analytic read throughput performance.
  • Clusters can grow elastically, increasing both throughput and capacity, by adding nodes

Debunking Myths about the VoltDB in-memory database

Monday, May 12, 2014 - 12:00am

written by John Hugg on May 12, 2014

I’d like to take a quick moment to address some myths and misconceptions about VoltDB. Many people selling products who view VoltDB as competition seem to be repeating them. As you’ll read, much of what’s said is just plain FUD.

VoltDB is an in-memory database that has benchmarked at over 3 million transactions asecond on bare metal, and recently crushed previous performance records in the cloud, posting eye-popping YCSB (Yahoo! Cloud Service Benchmark) numbers on AWS, Amazon’s cloud platform.

Don’t Accept Data Loss when Upgrading to In-memory Database Performance

Tuesday, May 20, 2014 - 12:00am

written by Ryan Betts on May 20, 2014

Data loss is the enemy of businesses everywhere. Snapshots, replication, active-active architectures, even physical measures such as backup generators are used to ensure data is preserved as it enters and is used or warehoused by the enterprise. Most companies use a database to manage this data and extract intelligence from it; therefore, the database has an important role in preservation of data – durability in database-speak.

As data wends its way through ingestion, transactions and analysis, many databases rely on frequent writes to disk to ensure data

Impact of Java Garbage Collection on in-memory databases

Friday, May 2, 2014 - 12:00am

written by Ariel Weisberg on May 2, 2014

Some users of Java, and specifically Java as it is used in in-memory database technology, worry Java’s ‘Garbage Collection’ can impact performance. Garbage Collection is intended to simplify memory management (allocation and de-allocation) and therefore reduce the amount of code written, speed development, and avoid memory management bugs. Garbage collection typically works by copying actively used (live) objects or tracking free memory occupied by unused (garbage) objects.

The primary concern is that most implementations of garbage collection stop

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

Integration of a streaming system with batch oriented, slower downstream systems

Tuesday, May 6, 2014 - 12:00am

written by Mik Quinlan on May 6, 2014

We’re happy to share a great blog from Mik Quinlan, a Java Technical Architect and Agile Mentor with more than 16 years experience in software development, who has extensive experience deploying VoltDB in fast data ingestion applications for the retail market.  He is currently Director of Mobile Advertising at Thinknear.  The blog originally appeared here.

Background

Over the last two years, I have been involved in transforming a complex legacy processing system that gave rise to a unique solution that may be used in other contexts.

M2M World Congress Wrap-Up

Monday, May 5, 2014 - 12:00am

written by Ryan Betts on May 5, 2014

I attended M2M World Congress in London two weeks ago and have been pondering my “take-aways” since. While many VoltDB customers use our NewSQL, in-memory database to provide scalable transactions, decisions and analytics in M2M deployments (smart grids, mobile telco platforms, cloud PaaS products), putting the M2M/IoT space into a broader context is hard. It was great to take a couple of days to listen and learn.

I left for London with the question, “What might the winner look like – from which industry might the winners emerge?”.

I came back with a pile

Narrowing the data-to-decision gap with in-memory operational databases

Thursday, May 22, 2014 - 12:00am

written by Peter Vescuso on May 22, 2014 

We can all agree that data is an organization’s greatest asset, yet in many industries data is treated as a ‘fixed’ asset, collected and stored in data warehouses for later analysis. This ignores data’s most valuable moment: when it’s analyzed in real-time to inform business decisions.

Not all companies hoard data for later analysis and action, of course.

Presto! Facebook Embraces SQL, Everyone at VoltDB Nods Their Head.

Thursday, November 7, 2013 - 12:00am

written by Ryan Betts on November 7, 2013 

Yesterday, Facebook announced open-source access to Presto, “a distributed SQL query engine optimized for ad-hoc analysis at interactive speed.” You can read more in this blog post by Martin Traverso, a member of Facebook’s Presto team.

At VoltDB, we’ve always believed that data is only valuable when you can interact with it. Data you can’t interact with — well, that’s just overhead. We put access and interactivity first. And that means we put SQL first. Five years ago this wasn’t a popular choice but we stuck to our guns.

Scaling: 700,000 Simultaneous Connections to VoltDB

Monday, October 21, 2013 - 12:00am

written by Ariel Weisberg on October 21, 2013

One of the original design goals for VoltDB was to support large numbers of connections per server. This kind of came for free with Volt’s event based design. The event based design was driven by a desire to keep the number of active software threads 1:1 with available hardware threads and this basically proscribed any kind of thread per client network IO implementation.

In theory the only limit on the number of connections in Volt is kernel memory and heap space.

VoltDB is a Churning Urn of Groovy Funk

Tuesday, February 11, 2014 - 12:00am

written by Stefano Santoro on February 11, 2014

VoltDB is welcoming Groovy into its ecosystem as its first inline procedure language. Code your procedure logic straight into the DDL, bypassing the java procedure requirements to edit/compile java source files separately.

With VoltDB Groovy stored procedures you can code your procedure implementation as part of CREATE PROCEDURE statements in your DDL file.

CREATE PROCEDURE groovy.procedures.Item AS ###

selectItem = new SQLStmt('SELECT ITEM_ID, DESCRIPTION FROM ITEMS WHERE ITEM_ID = ?')

transactOn = { id ->

    voltQueueSQL(selectItem,

VoltDB Real-Time Analytics with JSON

Thursday, October 3, 2013 - 12:00am

written by John Piekos on October 3, 2013

Consider the scenario where you are building an online multi-player game platform, where users can use the platform to create their own games.  Such a platform would have the following high-level requirements:

  1. It needs to be able to process tens of thousands of write transactions, game state changes, per second.  As each player makes a “move” or “action”, that needs to be recorded.
  2. It needs to be able to query player status and ranking.

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.