Recent Features
| |||||||||||||
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided.The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided.Posted Feb 8, 2012 14:08 UTC (Wed) by nix (subscriber, #2304)In reply to: The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. by Wol Parent article: XFS: the filesystem of the future?
From what I can make out, in relational you can't even guarantee a row is a single atom!Well, the relational algebra does not discuss storage at all, and does not stipulate where relations might reside on permanent storage (nor *which* might: you could perfectly well store join results permanently for all it cares). But in practice, in SQL... just try INSERTing half a row. You can't. Atomicity at the row level is guaranteed. I hate SQL, but at least it does this right.
(Log in to post comments)
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 8, 2012 15:00 UTC (Wed) by Wol (guest, #4433) [Link] Well, the relational algebra does not discuss storage at all, and does not stipulate where relations might reside on permanent storage Which is exactly my beef with relational databases. C&D FORBID you from telling the database where relations should be stored for efficiency. But in REALITY it is highly probable that, if you access one attributed associated with my primary key, that you will want to access others. But it's a complete gamble retrieving the same attribute associated with other primary keys. Because Pick guarantees (by accident, admittedly) that all attributes are stored in the same atom as the primary key they describe, all those attributes you are statistically most likely to want are exactly the attributes that coincidentally get retrieved together.
Cheers,
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 8, 2012 15:05 UTC (Wed) by Wol (guest, #4433) [Link]
Atomicity at the row level IN THE DATABASE is guaranteed, yes.
What I meant was it's not guaranteed at the physical level in the datastore. Two cells in the same row could be stored in completely different "buckets" in the database, for example the data is stored in an index with a pointer from the row. I know that probably doesn't happen but if the guy who designed the database engine thinks it's more efficient there's nothing stopping him.
So even if you the database programmer *think* an operation should be atomic right down to the disk, there's no guarantee.
Cheers,
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 8, 2012 21:53 UTC (Wed) by nix (subscriber, #2304) [Link]
It happens quite a lot, increasingly often now that databases are lifting the horrible restrictions many of them had on the total amount of data stored per row (Oracle and MySQL had limits low enough that you could hit them in real systems quite easily).
If it matters that data is written to the disk atomically, you have already lost, because *nothing* is written to the disk atomically, not least because you invariably have to update metadata, and secondly because no disk will guarantee what happens to partial writes in the case of power failure. So, as long as you have to keep a journal or a writeahead log to deal with that, why not allow arbitrarily large amounts of data to appear to be written atomically? Hence, transactions.
It is true that programs that truly use transactions are relatively rare: in one of my least proud moments I accidentally changed the rollback operation in one fairly major financial system to do a commit and it was a year before anyone noticed. However, when you *do* have code that uses transactions, the effect on the code complexity and volume can be dramatic. As a completely random example, I've written backtracking searchers that relied on rollback in about 200 lines before, because I could rely on the database's transaction system to do nearly all the work for me.
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 9, 2012 20:30 UTC (Thu) by Wol (guest, #4433) [Link] It happens quite a lot, increasingly often now that databases are lifting the horrible restrictions many of them had on the total amount of data stored per row (Oracle and MySQL had limits low enough that you could hit them in real systems quite easily). Sorry, I have to laugh here. It's taken Pick quite a while to get rid of the 32K limit, but that limit does date from the age of the dinosaur when computers typically came with 4K of core ... And no limit on the size of individual items, or the number of items in a FILE. Cheers,
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 9, 2012 20:38 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
if a single item is larger than the track size of a drive, it is physically impossible for the write to be atomic. You don't need to get this large to run in to problems though, any write larger than a block runs the possibility of being split across different tracks (or in a RAID setup, across different drives). If you don't tell the filesystem that you care about this, the filesystem will write these blocks in whatever order is most efficient for it.
The entire noSQL family of servers is based on relaxing the reliability constraints of the classic ACID protections that SQL databases provided. Posted Feb 10, 2012 16:25 UTC (Fri) by Wol (guest, #4433) [Link]
:-)
Look at the comment you're replying to :-) In early Pick systems I believe it was possible for a single item to be larger than available memory ...
Okay, it laid the original systems wide open to serious problems if something went wrong, but as far as users were concerned Pick systems didn't have disk. It was just "permanent memory". And Pick was designed to "store all its data in ram and treat the disk as a huge virtual memory". I believe they usually got round any problem by flushing changes from core to disk as fast as possible, so in a crash they could just restore state from disk.
Cheers,
|
|||||||||||||