m
Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
Top
Performance and Efficiency - VoltDB
10680
page-template-default,page,page-id-10680,page-child,parent-pageid-10675,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.4.4,vc_responsive
VoltDB / Product  / Features and Benefits / Performance and Efficiency

Performance and Efficiency

Per Machine Efficiency

In our race to scale systems out to commodity clusters, sometimes efficiency per unit of hardware takes a backseat. Some systems are so focused on parallelism, that individual node performance is not exactly state of the art. “Just add nodes…” they say, until you’ve found yourself managing a 500 node cluster that requires constant attention.

VoltDB is an all-new architecture, a database born from research into what a 21st century system should look like.

Hundreds of thousands of durable ACID transactions, containing millions of queries and writes, run each and every second. And that’s just on our laptops.

Now take that per-machine performance and scale it to 3 nodes, or 9, or 27. Millions of transactions and tens of millions of queries per second on small clusters are achievable without extensive tuning, special hardware, or other tricks.

The techniques we use to accomplish this are described in the architecture section, but the main idea is to partition data to individual CPU cores, treat CPU cores as pipelines of single-threaded work, then work to keep the pipelines full. It’s not complex, but we’ve spent almost 10 years polishing and perfecting it.

Smarter — Not Just Faster

When many systems talk about throughput, they talk about gets and puts (and not always puts).

VoltDB assumes that most transactions are going to have multiple SQL statements. Most applications build with aggregations and atomic counters. Many need joins. Lots of apps use custom processing or complex math. A few use JSON/Geospatial/UDFs/etc.. These powerful features enable application developers to focus on their business, not in building new primitives on top of a simpler database.

Check out the Views, Indexes & Data Structures and Server-Side Code pages for more on the power of VoltDB.

Cheaper Transactions Open New Use-Cases

Imagine you have a problem that requires 10,000 transactions per second, and generates $5,000,000 a month. To break even on the database alone, it must cost less than 0.002 US cents per transaction.

  • One VoltDB customer uses RFID to track the movement of every chip in a casino, looking for patterns in real time.
  • A second tracks mouse-movement over digital offers.
  • A third computes detailed request statistics for CDN traffic to enable fine-grained billing.

These use cases weren’t economical using traditional relational databases. NoSQL systems were considered, but none had the combination of strong consistency, operational simplicity, and raw hardware efficiency. VoltDB stood alone.

Related Content