4 ms·
From your earlier comment: "Due to it’s unique single-threaded architecture..." That would be a single thread per partition, right? Are those partitions auto
by benblack 16y ago
From your earlier comment:
"Due to it’s unique single-threaded architecture..."
That would be a single thread per partition, right? Are those partitions automatic or might a developer have to consider their creation carefully based on how data will be accessed? And replication? Seems concurrency _is_ something about which developers have to think. Here's the entry in the VoltDB FAQ: http://community.voltdb.com/faq#id545447 http://community.voltdb.com/faq#id545447
"...how refereshing it is to actually not have to think about concurrency."
Except you do. By figuring out the partitioning and replication up front. TANSTAAFL, regardless of our level of enthusiasm for our employers.
- jhugg 16y agoYou have to think about partitioning up front. In a sense, this is a prerequisite for our concurrency. So you're right. What I meant was, inside of a stored procedure itself, you never have to think about concurrent access to the data you are modifing during the lifetime of the procedure. You own it. Period. I wouldn't ever try to make the argument that this functionality is "free" and that VoltDB is a system without tradeoffs. It just seemed particularly relavent when the original article was making claims that serializable transaction semantics in SQL-RDBMSs were rare due to performance issues. I didn't mention NoSQL or Key-Value stores anywhere in my original comment.