Comments on: In-memory OLTP database. Interview with Asa Holmstrom. http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/ Trends and Information on Big Data, New Data Management Technologies, and Innovation. Wed, 17 Apr 2013 21:47:18 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: Ruslan Fomkin http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7534 Ruslan Fomkin Mon, 14 Jan 2013 09:51:16 +0000 http://www.odbms.org/blog/?p=1869#comment-7534 Hi John, Thank you for clarification. Does VoltDB performance of millions of TPS correspond to well partitioned database? Starcounter does not require to partition databases. To our experience there are many applications, where databases cannot be partitioned or it is difficult, and such applications still require good performance. Thus Starcounter is designed to get the best performance by running on a single machine with multi-core CPU and large amount of memory. Hi John,

Thank you for clarification. Does VoltDB performance of millions of TPS correspond to well partitioned database?

Starcounter does not require to partition databases. To our experience there are many applications, where databases cannot be partitioned or it is difficult, and such applications still require good performance. Thus Starcounter is designed to get the best performance by running on a single machine with multi-core CPU and large amount of memory.

]]> By: John Hugg http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7533 John Hugg Mon, 14 Jan 2013 03:53:14 +0000 http://www.odbms.org/blog/?p=1869#comment-7533 Ruslan, Apologies for spelling your name wrong above. Ruslan,
Apologies for spelling your name wrong above.

]]> By: John Hugg http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7532 John Hugg Mon, 14 Jan 2013 03:51:58 +0000 http://www.odbms.org/blog/?p=1869#comment-7532 Hi Rusian, Yes, VoltDB maintains consistency across all cluster nodes. Yes, we mix reads and writes at that rate, but with serializable consistency. Our clusters are all shared nothing. Yes VoltDB asks users to tell the system how to split up their data across CPUs and cluster nodes. How well your data partitions will affect performance; some workloads that partition poorly may be better suited for scale-up systems or relaxed consistency. For most workloads, VoltDB achieves dramatic price/operation reductions and offers a clear scalability path for growing workloads. Hi Rusian,

Yes, VoltDB maintains consistency across all cluster nodes. Yes, we mix reads and writes at that rate, but with serializable consistency. Our clusters are all shared nothing.

Yes VoltDB asks users to tell the system how to split up their data across CPUs and cluster nodes. How well your data partitions will affect performance; some workloads that partition poorly may be better suited for scale-up systems or relaxed consistency. For most workloads, VoltDB achieves dramatic price/operation reductions and offers a clear scalability path for growing workloads.

]]> By: Ruslan Fomkin http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7530 Ruslan Fomkin Thu, 10 Jan 2013 10:13:59 +0000 http://www.odbms.org/blog/?p=1869#comment-7530 If I remember correctly, VoltDB requires to partition database per CPU core for performance reason. Starcounter processes concurrent transactions against a single database and transparently utilizing all cores. <blockquote>VoltDB can run millions of TPS across a synchronously replicated, redundant cluster. </blockquote> John, can you clarify your statement? Does VoltDB maintain consistency over all cluster nodes and execute simultaneous read and update transactions at normal operational rate against the same data on all the nodes with the claimed performance? What do you mean by a cluster? Is it shared nothing, shared disk, shared memory, or? I am a Starcounter developer. If I remember correctly, VoltDB requires to partition database per CPU core for performance reason. Starcounter processes concurrent transactions against a single database and transparently utilizing all cores.

VoltDB can run millions of TPS across a synchronously replicated, redundant cluster.

John, can you clarify your statement? Does VoltDB maintain consistency over all cluster nodes and execute simultaneous read and update transactions at normal operational rate against the same data on all the nodes with the claimed performance? What do you mean by a cluster? Is it shared nothing, shared disk, shared memory, or?

I am a Starcounter developer.

]]> By: Roberto V. Zicari http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7525 Roberto V. Zicari Sat, 29 Dec 2012 17:07:14 +0000 http://www.odbms.org/blog/?p=1869#comment-7525 Thank you John. RVZ Thank you John. RVZ

]]> By: John Hugg http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/comment-page-1/#comment-7522 John Hugg Fri, 28 Dec 2012 04:11:27 +0000 http://www.odbms.org/blog/?p=1869#comment-7522 I'm one of the VoltDB devs and would like to correct a few things. First, VoltDB is 100% ACID across a cluster. There is no non-ACID mode in VoltDB and the only consistency level supported is global serializable consistency. As for scaling ACID across machines, whether it's possible depends on the workload. Partitionable workloads scale perfectly. Non-partitionable workloads don't. Workloads that are somewhere in the middle can still benefit from multiple machines. The vast majority of OLTP use cases we see are either partitionable (by customer, ticker symbol, ad-netowork, etc) or mostly partitionable. Finally, building for a cluster allows for a level of availability that can't be achieved with "scale-in". VoltDB can run millions of TPS across a synchronously replicated, redundant cluster. I’m one of the VoltDB devs and would like to correct a few things. First, VoltDB is 100% ACID across a cluster. There is no non-ACID mode in VoltDB and the only consistency level supported is global serializable consistency.

As for scaling ACID across machines, whether it’s possible depends on the workload. Partitionable workloads scale perfectly. Non-partitionable workloads don’t. Workloads that are somewhere in the middle can still benefit from multiple machines. The vast majority of OLTP use cases we see are either partitionable (by customer, ticker symbol, ad-netowork, etc) or mostly partitionable.

Finally, building for a cluster allows for a level of availability that can’t be achieved with “scale-in”. VoltDB can run millions of TPS across a synchronously replicated, redundant cluster.

]]>