MongoDB turns on, tunes in, drops ACID and goes mobile Document database biz MongoDB is aiming to be all things to all people as it continues to court the enterprise and move up the stack, offering a mobile product, ACID compliance and global clusters. The latest raft of announcements, made at the 10-year-old firm's annual gabfest in New York, are part of efforts to win over both …
This post has been deleted by its author
They can believe whatever they want, but in the real world, transactional integrity is very important. Even more so when you're talking about clusters where the user's session can bounce like a ping pong ball between servers.
At least pragmatism prevailed and they pulled their head out of their backsides long enough to address the single biggest criticism people had about Mongo.
Now if only they came up with a consisted language for operating on NoSQL databases. Something structured.... Yeah... like... a structured query language... Hmm....
Not sure how good their transactional support is in practice, but reading the article makes it seems as if they were trying to enhance it, rather than getting rid of it.
>the decision to offer multi-document ACID transactions, a feature that is generally available from today.
So, maybe drops takes ACID would have been a better headline? Still a good fit for Jerry Garcia fans.
"We firmly believe that 80 to 90 per cent of applications don't need transaction"
That's similar to the rubbish the MySQL folks spouted, although they claimed it was referential integrity should be done in the application code. Having ported many MySQL and NoSQL applications to a real database (PostgreSQL mostly) I can assure you that most apps need transactions and data integrity at the DB layer to ensure you don't end up with bogus data,
"We firmly believe that 80 to 90 per cent of applications don't need transaction"
As well as that there was also:
"There are generations of devs and architects who have been conditioned by 30 or 40 years..."
I italicised conditioned because they're using it pejoratively; reflecting their skepticism of the need for transactional integrity, I can't help feeling a little skeptical of their conscientiousness in implementing it.
> I italicised conditioned because they're using it pejoratively; reflecting their skepticism of the need for transactional integrity, I can't help feeling a little skeptical of their conscientiousness in implementing it.
This.
And there was no need to either. Most of the players in RDBMS land weren't initially targeting enterprise. When did you hear any of them say that enterprises have been "conditioned" to think that they need clustering or hot backups or whatever. They simply did it then shouted about the great new feature in $(New version).
"Appealing to a broader church means making slight shifts – and one good example is the decision to offer multi-document ACID transactions, a feature that is generally available from today."
I don't know but, for us, the lack of multi document ACID transaction is exactly the reason why we only use it as logger instead of a wider data storage candidate. It is good to hear they put this into the engine but i just wonder if they implement this there will there be performance penalty? And does it really work as advertised? Honestly i think multi-document ACID transaction is no small undertaking and i only comfortable to use it in wider scope after, maybe, one or two major versions after it is rolled out.
Of course there is an overhead to ACID compliance. It isn't as if $(EVERYONEELSE) has a bunch of Thread.Sleep() calls hanging about. Atomicity requires that my transaction should either run to completion or be completely undone. That requires keeping track of my uncommitted changes until one of those outcomes. Not free. Consistency requires that constraints are honoured. You cannot merely insert a record, you need to assert the existence of every foreign key target. You cannot merely delete a record without checking for child records that would be orphaned. Isolation is a big cost. You cannot have a free for all with different concurrent users updating the same records. Otherwise you cannot have atomicity. This means (usually) some form of record locking, so now you need to lock and unlock things as you write them. Those locks have to be immediately visible across other threads, so you have to wait for CPU pipelines to flush at all sorts of times. And durability means that the thing cannot run off and cry in a corner with missing committed data, even in the event of a total failure of everything other than the storage. So now you cannot be satisfied that the commit has completed until the disk cache has been flushed. And you need to remember to use the appropriate APIs so the OS doesn't lie to you and return early.
Engineering is about tradeoffs. ACID compliance is about guaranteeing data correctness even at the cost of performance in some situations. Mongo et al have their uses. If my document store can be regenerated in the event of a failure, I may decide to forgo the correctness promises of a real DBMS to get better performance. But I cannot trust someone with my data where their worldview is that most people don't need ACID compliance. There are very few problems where data loss is inconsequential, and a half arsed attempt at ACID compliance is the worst of both worlds. You can very easily picture someone with that attitude not waiting for disk flushes and ending in a lot of bother when the proverbial hits.
I gave it a spin years ago and it was a resource hog like I'd never seen before. The documentation also left much to be desired and I had a general feeling that its popularity was fuelled by hype more than actual large-scale, long-horizon production use.
These days it's happily back to Postgres for me and I was left with a really bad taste in my mouth after giving Mongo an honest try so I don't think I'll be giving it a second opportunity any time soon, but I would still be interested in other people's views, especially if it did actually solve a problem for them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
