Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB gets support for multi-document ACID transactions

techcrunch.com

Post reply on HN
Print view View original

181–190 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#181

Post by Fins »

ChicagoDave wrote: post #145
BillinghamJ wrote: post #120

Earlier quoted context omitted.

None of the things you've just said make any difference to the fact that it doesn't make sense and is a terrible idea. I fail to see in what way my statements are "legacy" or not relevant to micro-services. My company (Cuvva, insurance in the UK) runs a "micro" service architecture and deals with these problems every day. It is not possible to use DB-level locking/transactions across network boundaries. It's just as…

I wasn't responding to the distributed transaction argument, though nothing in the MongoDB blog says it won't support it. I was specifically responding to "one table one service" which is the foundation of domain driven micro service architecture. To have a single domain silo'd and tested within its own boundaries. Whether you're firing events between services or just calling other services is a design decision, but…

Just because something can be done, including the fashionable microservices "architecture", it does not mean that it should be done, or that it is a good idea.

Re: MongoDB gets support for multi-document ACID transactions

#182

Post by colanderman »

ZenoArrow wrote: post #162
jasondc wrote: post #53

Earlier quoted context omitted.

Triggers?? Where you add some application logic to the database, 10 years go by, and no one has any idea how the triggers work? Or even how to test them? I've never seen triggers used successfully in any production application (maybe they work at first, but give them time, and a few code changes).

> "I've never seen triggers used successfully in any production application" Triggers have one or two good use cases, and plenty of bad use cases. I would suggest the strongest use case is for data validation. Databases don't have very sophisticated type systems, and custom data types can cause headaches. Database triggers allow you to ensure that the data stored in fields matches a set of criteria. To give a basic e…

Third case (and most important IMO): schema migrations. When doing major shuffling of a schema, you can use triggers to "redirect" accesses to the old tables or columns into new ones. This way, the schema updates can be applied without bringing down the application.

(Such triggers of course are removed once the application is updated, along with any old schema bits.)

Re: MongoDB gets support for multi-document ACID transactions

#183

Post by mustardo »

drmirror wrote: post #179
mustardo wrote: post #173

Earlier quoted context omitted.

On the surface it sounds like you might have a case for Mongo, lookout for scenarios like... * Trading in game items between two users (needs multi document atomic locks if you don't want duplicate or lost items) assuming your "schema" is a document per user * You want to rename or restructure an attribute in the future, with no schema it's not possible change migrate data easily without writing ad hoc code (maybe yo…

About the first use case, well it turns out MongoDB just introduced multi-document transactions today.

If only someone had posted that information to HN

Re: MongoDB gets support for multi-document ACID transactions

#184

Post by btilly »

threeseed wrote: post #168
gaius wrote: post #152

Earlier quoted context omitted.

This is something you heard from people who never really used it I used it at a previous job. Project to move a multi-tera dataset from an Oracle box (24 CPUs, 24G RAM, SAN) to a MongoDB cluster (10 boxes, each with 48 cores, 96G RAM and internal SSD). MongoDB couldn't perform for shit, and it couldn't stay up in a usable state for more than a few hours at a time. This is with 20x the processors and 40x the memory of…

See this is the sort of crazy things I used to see people do and wonder why they had problems. MongoDB is a document database. You can't just take relational database tables, move them across and expect it to behave the same. And frankly I don't feel sympathy for bad engineering practice. You don't do system migrations without fully testing and understanding all of the systems. But for those of us that had document o…

If you never tracked what happened in production, it may have worked most of the time well enough that you never saw how bad it was.

But read https://aphyr.com/posts/284-call-me-maybe-mongodb and https://aphyr.com/posts/284-call-me-maybe-mongodb for an idea of how the promises in MongoDB documentation compared to the reality of the software under stress. And it wasn't just hypothetical either - there are plenty of horror stories floating around from people who ran into those problems in production for uses cases that were supposed to be a fit for MongoDB.

And the performance argument didn't hold water either. As benchmarks like https://www.enterprisedb.com/node/3441 showed, decent relational databases consistently beat MongoDB on the same hardware. Yes, lots of people rewrote bad relational models and saw performance improve. But apples to apples, writing an application against a relational databases in the same way you would against MongoDB resulted in a win for the relational database.

So yes, there were lots of people saying exactly what you are saying now. But the ones who actually tested their systems and ran performance tests came to a very, very different conclusion.

Re: MongoDB gets support for multi-document ACID transactions

#185

Post by drmirror »

ZenoArrow wrote: post #156
drmirror wrote: post #12

Earlier quoted context omitted.

I beg to differ. (Disclosure: I work for MongoDB.) Using JSON as your data model, rather than relational tables, lets you build different applications that don't need multi-document transactions as often, because the data is already together in a single document. But when you do need multi-document transactions (a small percentage of applications do, and only few use cases inside those applications), they are now ava…

How does MongoDB handle schema changes? For example, let's say I want to add a mobile phone field to a customer record type. How would I go about doing that in MongoDB?

The short answer is: just do it. You can add any field to any document at any time. That's the beauty of JSON documents without schema constraints. Then of course you need to let your application understand that. But it turns out it's almost trivial to make an application display a phone number field if it finds one, and not display a phone number if there isn't one in the document.

Re: MongoDB gets support for multi-document ACID transactions

#186

Post by aneutron »

pweissbrod wrote: post #160
harryh wrote: post #38

Earlier quoted context omitted.

It's linked in the RethinkDB essay, but it's always worth explicitly calling out the "Worse Is Better" essay: http://dreamsongs.com/RiseOfWorseIsBetter.html Ignore its lessons at your peril. Your job isn't to build an engineering masterpiece. Your job, as pg says, is to build something people want.

Shipping early and working on stability later may work for something like a video game but not for a database my system depends on thanks

If you're in nation-wide healthcare, that strategy quickly becomes unacceptable.

Re: MongoDB gets support for multi-document ACID transactions

#188

Post by Thaxll »

stevenwoo wrote: post #155
Thaxll wrote: post #139

Earlier quoted context omitted.

- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…

I feel I need to quote the post mortem back at you so you point out where I mis read the quote. "Our top focus right now is to ensure service availability. Our next steps are below: Identify and resolve the root cause of our DB performance issues. We’ve flown Mongo experts on-site to analyze our DB and usage, as well as provide real-time support during heavy load on weekends." How does that disagree with my post?

You're implying they couldn't fix MongoDB or reached the limit which is false. In the current ( HN ) post they said they fixed it, I'm pretty sure they didn't have any experience in DBs in the first place hence why they asked for help.

Nowhere in the original post they mention issues related to MongoDB itself it was probably bad design on their side.

Re: MongoDB gets support for multi-document ACID transactions

#189

Post by dijit »

Thaxll wrote: post #139
stevenwoo wrote: post #39

Earlier quoted context omitted.

Epic had a post mortem blog post here that mentioned in passing they had stumped all the experts they could find to look at unsolveable issues they had with MongoDB. https://news.ycombinator.com/item?id=16340462 I kind of assumed the fix is going to be a rewrite with Postgres or MySQL.

- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…

> I could tell you horror story about pg not have an official replication system until 2011 when pg 9.0 landed.

And I would re-iterate that just because something isn't in mainline, doesn't mean it's not possible. Did you know that Pg didn't have native partitioning until Pg10? Somehow we managed to do partitioning before then.

I don't buy the argument that you need to ship broken features just to have them; Pg doesn't include it into base until it's a /good/ solution which is well engineered and has appropriate toggles. That is not a horror story.

> - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ).

I shipped a game which had similar CCUs (within the order of magnitude) and I can confirm that you can't do it with one postgresql machine, or.. actually you could but we chose to fsync() constantly to prevent corruption from ever happening and remove the RAID cache.. but you can shard on top of your database solution too.

Re: MongoDB gets support for multi-document ACID transactions

#190

Post by dijit »

threeseed wrote: post #133
btilly wrote: post #86

Earlier quoted context omitted.

MongoDB has successfully played the 'hype first, features later' strategy. Now it is well on the way to being a decent swiss-army-knife database. I was going to say that I won't believe that it is on its way to being a decent database until after an article appears on https://aphyr.com/tags/jepsen saying that MongoDB actually delivers on what it claims. So I looked for the most recent analysis of MongoDB and found ht…

I have used MongoDB in production for a number of Fortune 100 sized companies. It has always been a unique database that was ideal for scenarios when your data model was document orientated. > was an overhyped steaming pile of shit for a very long time No it wasn't. This is something you heard from people who never really used it. It had its faults but it was never a pile of shit nor was it substantially worse than o…

> No it wasn't. This is something you heard from people who never really used it. It had its faults but it was never a pile of shit nor was it substantially worse than other databases.

This is FUD, I have used mongodb, I have a certification in mongodb even.

Unless you know precisely what you're doing it's very easy to burn yourself. And mongo markets itself as being "easy to use out of the box" this is not a good thing to do.

I consider MySQL defaults to be unsafe, (as in, it used to corrupt data silently) but it's a godsend compared to the data consistency in mongodb.

There are countless promises it fails to deliver on too, I will not, ever, recommend it for a project. However in recent months I've heard it got better- This means I will stop deriding developers who now use it. But it does not mean I will be realistically allowing its use in the environments I work in. I tend to care about the data consistency in those.

Post reply on HN