5 ms·

It is a triumph of vendor marketing (Hi, John Hugg!) that reasonably informed engineers think ACID == SQL/relational and that NoSQL == EC. Both are false. As a

It is a triumph of vendor marketing (Hi, John Hugg!) that reasonably informed engineers think ACID == SQL/relational and that NoSQL == EC. Both are false. As a couple of examples, have a look at Google Percolator http://research.google.com/pubs/pub36726.html http://research.google.com/pubs/pub36726.html and Scalaris http://code.google.com/p/scalaris/ http://code.google.com/p/scalaris/ .

jhugg 16y ago
I am John Hugg. I do work for VoltDB. I am proud of our transaction isolaton. Not sure why this comment was a reply to me though. I've never claimed all NoSQL is EC, not all SQL/Relational is ACID. I totally agree there is a lot of unfortunate confusion, though I wouldn't limit the blame.
- 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 ago
    You 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.
- benblack 16y ago
  From the VoltDB FAQ (http://community.voltdb.com/faq#id545596 http://community.voltdb.com/faq#id545596): Key-Value stores are a mechanism for storing arbitrary data (i.e. values) based on individual keys. Distributing Key-Value stores is simple, since there is only one key. However, there is no structure within the data store and no transactional reliability provided by the system.
  - jhugg 16y ago
    Sorry. I didn't write it and I'll see what I can do about toning down the language. In the defense of the text, while some Key-Value stores provide atomic operations on individual values, I'm not aware of many that offer actual transactions in the traditional sense of the term. If you want to complain about our marketing, feel free to email Fred Holahan (fholahan at voltdb.com). He didn't write everything on our website, but he's in charge.
  - jhugg 16y ago
    I hadn't really looked into Scalaris much. I see they're trying to provide transactions on a DHT. Cool. Something to keep an eye on.

jhugg 16y ago

I am John Hugg. I do work for VoltDB. I am proud of our transaction isolaton. Not sure why this comment was a reply to me though. I've never claimed all NoSQL is EC, not all SQL/Relational is ACID. I totally agree there is a lot of unfortunate confusion, though I wouldn't limit the blame.

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 ago
  You 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.
benblack 16y ago
From the VoltDB FAQ (http://community.voltdb.com/faq#id545596 http://community.voltdb.com/faq#id545596): Key-Value stores are a mechanism for storing arbitrary data (i.e. values) based on individual keys. Distributing Key-Value stores is simple, since there is only one key. However, there is no structure within the data store and no transactional reliability provided by the system.
- jhugg 16y ago
  Sorry. I didn't write it and I'll see what I can do about toning down the language. In the defense of the text, while some Key-Value stores provide atomic operations on individual values, I'm not aware of many that offer actual transactions in the traditional sense of the term. If you want to complain about our marketing, feel free to email Fred Holahan (fholahan at voltdb.com). He didn't write everything on our website, but he's in charge.
- jhugg 16y ago
  I hadn't really looked into Scalaris much. I see they're trying to provide transactions on a DHT. Cool. Something to keep an eye on.