3 ms·

VoltDB currently requires stored procedures for multi-statement transactions, but you can send single-statement ad-hoc queries to it just fine (JDBC/Native Clie

by jhugg 13y ago

VoltDB currently requires stored procedures for multi-statement transactions, but you can send single-statement ad-hoc queries to it just fine (JDBC/Native Clients/HTTP-JSON). Our SQL has gotten significantly more sophisticated lately and many kinds of interesting queries and updates can be performed with one statement. Stored procs are used to allow rich transactions without using client-side transaction control. For all of the concerns about stored procs (of which some are valid), the fundamental issue is that external transaction control is performance's nemesis. It's not a coincidence that few No/NewSQL systems support external transaction control, and those that do don't publish many benchmarks using that feature.

batbomb 13y ago
I suppose it depends heavily on application, but I don't think external transaction control is necessarily tied to performance. However, that being said, it's usually up to the user to come up with some sort of managed transaction on the application/middleware side which usually needs to be coupled with some sort of database locking mechanism. In reality, that's really hard to get right, even if you "get" multithreading. Again, I think VoltDB is going places. I haven't been able to actually dig into it personally due to time constraints, and when I realized Command Logging was only available in the Enterprise Edition that effectively killed a few use cases for me. One of the uses I hope to investigate is to use it as a nice materialized-view playground for bridging data on-demand from various databases, in coordination with Presto: https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920 https://www.facebook.com/notes/facebook-engineering/presto-i... In any case, it's a shame it's rarely discussed on HN.

by jhugg 13y ago

batbomb 13y ago

I suppose it depends heavily on application, but I don't think external transaction control is necessarily tied to performance. However, that being said, it's usually up to the user to come up with some sort of managed transaction on the application/middleware side which usually needs to be coupled with some sort of database locking mechanism. In reality, that's really hard to get right, even if you "get" multithreading. Again, I think VoltDB is going places. I haven't been able to actually dig into it personally due to time constraints, and when I realized Command Logging was only available in the Enterprise Edition that effectively killed a few use cases for me. One of the uses I hope to investigate is to use it as a nice materialized-view playground for bridging data on-demand from various databases, in coordination with Presto: https://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/10151786197628920 https://www.facebook.com/notes/facebook-engineering/presto-i... In any case, it's a shame it's rarely discussed on HN.