11–20 of 34 posts
I think it's great that someone is taking a detailed look at distinct isolation levels for different systems. It's also worth looking at distinct levels for atomicity, consistency, and durability. One could then define an overall "pH" level for systems. I would take exception to Bailis' statement that "it is impossible to simultaneously achieve high availability and serializability." At FoundationDB, we do exactly th…
Earlier quoted context omitted.
Did you read the post? First, it covers both default isolation and maximum available. Second, note that many databases (like Oracle 11g) don't actually give you serializable semantics at ANY setting. Third, most of these products are not distributed systems. Fourth, ACID is not a spectrum for distributed systems; it is basically impossible to apply without sacrificing availability. But that's perhaps not a big deal i…
People scream ACiD on NoSQL's because they fail the easier A, C, or D in various forms, not the harder I part. Having AC&D go a long way in ensuring data correctness.
Serializability ("I") ensures that database consistency, or maintenance of integrity constraints ("C"), is not violated. While it's possible to get consistency ("C") without serializability (which would give up traditional "I" in favor of a weaker form of isolation), it's often difficult [see http://www.bailis.org/blog/when-is-acid-acid-rarely/#arbitra...].
Earlier quoted context omitted.
Did you read the post? First, it covers both default isolation and maximum available. Second, note that many databases (like Oracle 11g) don't actually give you serializable semantics at ANY setting. Third, most of these products are not distributed systems. Fourth, ACID is not a spectrum for distributed systems; it is basically impossible to apply without sacrificing availability. But that's perhaps not a big deal i…
I did read the post. It does cover both default and maximum. I didn't dispute that. I called out the notion that anyone ought to be depending on the defaults in the first place, or that SERIALIZABLE as a default was a good choice. Yes, many don't support SERIALIZABLE. Didn't contradict that either. As to whether many of these are or aren't distributed systems: Ingres - has replication. Aerospike - distributed/fault t…
Regardless of whether you should depend on them, many many people do. Heck, many people don't even understand that there's a choice to be made: after all, everyone knows that Oracle is ACID compliant, right?
Yes, many don't support SERIALIZABLE. Didn't contradict that either.
Sorry, I was confused by the bit about "If your workload needs serializability, set it" since that's physically impossible on Oracle 11g.
Just because a DB has a replication package available (like MySQL) does not mean that it is a distributed system. And the file backed DBs (like Berkeley) are definitely not distributed. Sure, there are some extremely expensive massively parallel DBs in use (like Volt), but the number of deployments for those systems is a drop in the bucket compared with single-node MySQL/Postgres/Oracle/SQLServer/DB2 instances.
Earlier quoted context omitted.
I did read the post. It does cover both default and maximum. I didn't dispute that. I called out the notion that anyone ought to be depending on the defaults in the first place, or that SERIALIZABLE as a default was a good choice. Yes, many don't support SERIALIZABLE. Didn't contradict that either. As to whether many of these are or aren't distributed systems: Ingres - has replication. Aerospike - distributed/fault t…
I called out the notion that anyone ought to be depending on the defaults in the first place Regardless of whether you should depend on them, many many people do. Heck, many people don't even understand that there's a choice to be made: after all, everyone knows that Oracle is ACID compliant, right? Yes, many don't support SERIALIZABLE. Didn't contradict that either. Sorry, I was confused by the bit about "If your wo…
Things get harder when you're distributed. For example, if you cluster with a sharded master-slave configuration, then, to serialize transactions that span shards/partitions, you'll need to do 2 phase commit or similar between masters for writes and, for most read/write transactions, make sure you don't read from slaves. If you cluster via master-master/active-active, then, for serializability, you'll need locking or some other concurrency control across masters for each shard/partition. Both setups are definitely do-able (if not highly available) but require non-trivial engineering.
Earlier quoted context omitted.
I did read the post. It does cover both default and maximum. I didn't dispute that. I called out the notion that anyone ought to be depending on the defaults in the first place, or that SERIALIZABLE as a default was a good choice. Yes, many don't support SERIALIZABLE. Didn't contradict that either. As to whether many of these are or aren't distributed systems: Ingres - has replication. Aerospike - distributed/fault t…
I called out the notion that anyone ought to be depending on the defaults in the first place Regardless of whether you should depend on them, many many people do. Heck, many people don't even understand that there's a choice to be made: after all, everyone knows that Oracle is ACID compliant, right? Yes, many don't support SERIALIZABLE. Didn't contradict that either. Sorry, I was confused by the bit about "If your wo…
Ignorance is not an excuse. It just isn't.
"Just because a DB has a replication package available (like MySQL) does not mean that it is a distributed system. And the file backed DBs (like Berkeley) are definitely not distributed. Sure, there are some extremely expensive massively parallel DBs in use (like Volt), but the number of deployments for those systems is a drop in the bucket compared with single-node MySQL/Postgres/Oracle/SQLServer/DB2 instances."
I do not understand what point you are trying to make here. Are these systems de-facto non-distributed systems merely because of deployment counts? Is there an objective criteria here I should be aware of?
Earlier quoted context omitted.
People scream ACiD on NoSQL's because they fail the easier A, C, or D in various forms, not the harder I part. Having AC&D go a long way in ensuring data correctness.
Unlike "C" and "A" in "CAP," "AC&D" (specifically, "C") can't be easily separated from "I". Serializability ("I") ensures that database consistency, or maintenance of integrity constraints ("C"), is not violated. While it's possible to get consistency ("C") without serializability (which would give up traditional "I" in favor of a weaker form of isolation), it's often difficult [see http://www.bailis.org/blog/when-is…
The author of the post basically seems to treat any isolation level below serializability as some sort of sham perpetrated on the development community, and that's not the case: they're still useful, and they're still something that you can use to build the sorts of application guarantees you want. The mere fact that pretty much every database vendor gives you a choice as to what isolation level to use should be a pretty obvious clue that there's no one-size-fits-all answer there, so harping on the non-existence of a serializable isolation level is somewhat missing the point.
Earlier quoted context omitted.
I called out the notion that anyone ought to be depending on the defaults in the first place Regardless of whether you should depend on them, many many people do. Heck, many people don't even understand that there's a choice to be made: after all, everyone knows that Oracle is ACID compliant, right? Yes, many don't support SERIALIZABLE. Didn't contradict that either. Sorry, I was confused by the bit about "If your wo…
"Regardless of whether you should depend on them, many many people do. Heck, many people don't even understand that there's a choice to be made: after all, everyone knows that Oracle is ACID compliant, right?" Ignorance is not an excuse. It just isn't. "Just because a DB has a replication package available (like MySQL) does not mean that it is a distributed system. And the file backed DBs (like Berkeley) are definite…
I'm not interested in excusing anything, I'm interested in understanding the real world. And what I see is that a lot of people who insist on the absolute need for ACID don't really understand it because they're using non-ACID technology right now.
I do not understand what point you are trying to make here.
Consider MySQL with asynchronous replication to a slave. In a weak sense, that is a distributed system because the remote slave is on a different machine (and probably very distant) from the master. But the distributed bit here doesn't interfere with correctly implementing ACID: MySQL with async replication operates identically to single node MySQL: it just transmits the binary logs to a slave server. The database system itself is a single-node service whose state gets replicated at transaction boundaries.
In contrast, distributed shared-nothing databases like Volt have to work really hard to maintain consistency: there is no single node in those systems that does all the work and gets replicated: multiple nodes have to cooperate in order to get anything done.
Huh? You ought not be depending on the default isolation settings. If your workload needs serializability, set it. Most don't. CAP teaches us that ACID is a spectrum in a distributed system.
Did you read the post? First, it covers both default isolation and maximum available. Second, note that many databases (like Oracle 11g) don't actually give you serializable semantics at ANY setting. Third, most of these products are not distributed systems. Fourth, ACID is not a spectrum for distributed systems; it is basically impossible to apply without sacrificing availability. But that's perhaps not a big deal i…
While I appreciate how thorough the article is, it's a bit of a strawman. Pretty much everyone who makes use of a relational database in a professional capacity has to be aware of what transaction isolation level they're using, make their own choice about what to use, and then do things like acquire explicit update locks or do optimistic locking in order to ensure data integrity. But that doesn't mean that the ACID p…
What do you mean by consistency? I agree that there are many ways to ensure that application integrity constraints are not violated--without using serializability. My point is that, without ACID serializability, you'll have to do some extra work to ensure them in general [1].
The author of the post basically seems to treat any isolation level below serializability as some sort of sham perpetrated on the development community, and that's not the case
Weak isolation has a long tradition spanning decades [2] and is hardly a "sham." It's well known that weak isolation doesn't guarantee the ACID properties as traditionally defined. My point is that many databases don't provide ACID as they promise.
It's still a different world than trying to mimic ACID properties in a NoSQL database
In terms of current offerings, I'm sympathetic to this viewpoint, but you might be surprised how cheaply we can get properties like the transactional atomicity you mention.
In general, I'm curious how easily anyone's able to take their application level requirements and map them down into an isolation like "read committed," especially given how awkwardly they're defined [3] and how many corner cases there are.
[1] e.g., http://www.bailis.org/blog/when-is-acid-acid-rarely/#arbitra...
[2] "Granularity of Locks and Degrees of Consistency in a Shared Data Base," Jim Gray et al., 1976 http://diaswww.epfl.ch/courses/adms07/papers/GrayLocks.pdf
[3] e.g., http://www.bailis.org/blog/when-is-acid-acid-rarely/#weak-no...