VoltDB Community Users Share Knowledge
VoltDB adoption and deployments are accelerating. We’re working hard make our products easy to use in both cloud and privately-racked infrastructures. We see strong adoption in five application categories – capital markets (mostly around trading systems), digital advertising, online games, network monitoring, and intelligence/surveillance (national security, fraud mitigation, etc.).
With product evaluations on the rise, organizations are increasingly asking about user experiences, particularly for deployed VoltDB applications. There are some strong user and partner endorsements on our website. What’s also interesting is that VoltDB community users are now discussing implementation patterns and deployment experiences on blogs and public developer forums. Below are a few examples.
Comments on Scaling, HA, Durability and Devops
This post was contributed to StackOverflow in response to an inquiry about successful VoltDB implementations:
“We went live last year with an application that uses VoltDB. We’re storing around 1.5 billion records and processing 50-90 million transactions a day with a kfactor=1 4 server cluster (256 GB memory/server ). Given the performance of VoltDB, we could easily be handing 1 billion transactions a day.
To date, we have had no problems related to the VoltDB software. Our experience is that it is truly ACID compliant. With the addition of the Command Logging feature, I believe you can configure the logging parameters to preclude the loss of any transactions.
Other strong features include its scalability (and the relative simplicity to add capacity).
An important consideration when choosing VoltDB is understanding VoltDB’s partitioning scheme. Achieving the extremely high transaction rates possible with VoltDB depends on the parallelism achieved through data partitioning. The partitioning is transparent to your application, but your application data must lend itself to being partitioned to get the maximum performance. If your data does not lend itself to partitioning, I believe the primary impact would be reduced throughput ( i.e. transaction rates ) – not a show-stopper.
Finally – a note concerning stored procedures. VoltDB allows you to replace stored procedures without stopping the database. Also, each invocation of a stored procedure constitutes a single transaction. We have leveraged stored procedures in such a way that we are able to modify/update the our application logic without stopping the database.”
Key points from the above post include:
- The application was deployed in production last year.
- Current throughput is 50-90 million transactions per day.
- The customer believes they could easily scale 1 billion transactions per day (ease of scaling is viewed as a strength).
- The customer is using VoltDB’s built-in high availability feature, and goes on to comment about the durability that can be gained from Command Logging.
- The customer is utilizing best practices to modify database stored procedures without incurring service windows.
Comments on Throughput, Admin and Interoperability
And another response to a StackOverflow inquiry about using NewSQL vs. traditional optimization/sharding:
“At Jingit (www.jingit.com) we have battle tested VoltDB. It is fantastic on scaling write heavy apps and in AWS cloud. There is no hosted option so our devs own it and they spend < 1 hr a week administering our VoltDB cluster. We actually use both RDS and VoltDB. RDS for our traditional relational workload, and VoltDB for our HIGH VOLUME transaction processing. If you are developing in Java, VoltDB is a great fit as you write all the procedures in Java.”
Although brief, the above post also provides useful information:
- The application is deployed on Amazon’s public cloud.
- VoltDB has proven to be “fantastic at scaling write heavy apps”.
- Database administration requires less than 1 hour per week.
- The application actually uses RDS (MySQL, Oracle or MS SQL Server) and VoltDB side-by-side to service different workloads. This is a pattern we see with increasing frequency in other deployments as well.
We work with customers all the time, so we have many insights about the interesting and unique applications people are creating with VoltDB. VoltDB is very strong at handling an range of workloads, but it’s not the right tool for every job. It’s very helpful when users in the VoltDB community offer their implementation patterns and deployment experiences to others who are early in their product evaluation cycles. We value the guidance our community members are putting out there, and look forward to more informative commentary in the near future.