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, Data Science and Innovation. Mon, 03 Nov 2014 17:39:20 +0000 hourly 1 http://wordpress.org/?v=4.2.4 By: Ruslan Fomkin http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/#comment-172 Mon, 14 Jan 2013 09:51:16 +0000 http://www.odbms.org/blog/?p=1869#comment-172 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-171 Mon, 14 Jan 2013 03:53:14 +0000 http://www.odbms.org/blog/?p=1869#comment-171 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-170 Mon, 14 Jan 2013 03:51:58 +0000 http://www.odbms.org/blog/?p=1869#comment-170 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-169 Thu, 10 Jan 2013 10:13:59 +0000 http://www.odbms.org/blog/?p=1869#comment-169 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-168 Sat, 29 Dec 2012 17:07:14 +0000 http://www.odbms.org/blog/?p=1869#comment-168 Thank you John. RVZ

]]>
By: John Hugg http://www.odbms.org/blog/2012/12/in-memory-oltp-database-interview-with-asa-holmstrom/#comment-167 Fri, 28 Dec 2012 04:11:27 +0000 http://www.odbms.org/blog/?p=1869#comment-167 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.

]]>