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

121–130 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#121

Post by metheus »

krylon wrote: post #71

I looked into MongoDB a couple of years back, because it was the hot thing at the time. About fifteen minutes in, I try to find out how to do transactions. That is strange, I thought, the manual says nothing about transactions. I asked a popular search engine and was a little shocked to find out there were no transactions. That was a dealbreaker for me. If MongoDB has now grown support for transactions, that changes…

While doing so, I recommend you think some about the meaning of embedding relationships vs. referencing them in other collections. MongoDB can do both (the aggregation framework provides joins in the form of the $lookup stage).

If you have a “one-to-many(some)” kind of relationship, embedding is a good option, and gets you ACID semantics without even resorting to multi-statement transactions.

If you have a “one-to-many(thousands or more)” kind of relationship, objectID references (a la foreign key) is more likely what you want.

Re: MongoDB gets support for multi-document ACID transactions

#122

Post by chipotle_coyote »

qaq wrote: post #106
chipotle_coyote wrote: post #87

Earlier quoted context omitted.

There are several companies that are leveraging PostgreSQL for their own businesses, but that doesn't seem to me to be a rebuttal of the OP's assertion that PostgreSQL couldn't survive as a company itself. Citus Data is not "PostgreSQL as a company," it is "a company that exists because PostgreSQL already existed."

Well majority of key Postgres contributors work for 2ndQuadrant, EnterpriseDB, Crunchy Data, Citus etc. It basically means PostgreSQL is a distributed company and it would survive fine but being distributed it looks like it is able to innovate faster and is more resilient.

| It basically means PostgreSQL is a distributed company

I would argue that it means that different companies using PostgreSQL help fund PostgreSQL development. That's not the same thing as being a single company. It's a model which clearly works very well for PostgreSQL, but it doesn't really give us good data on whether the "single company doing closed source development" (e.g., Oracle) and "single company driving the bulk of open source development" (e.g., MongoDB) models would have worked as well for them.

Re: MongoDB gets support for multi-document ACID transactions

#123

Post by stevenwoo »

redwood wrote: post #69
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.

Another way of reading that post is that MongoDB is being used for some of the highest throughput concurrent workloads out there... and those are always hard to optimize. Doing a lift and shift for a "grass is greener" alternate solution is not a clear cut path to victory at all ... but it's certainly a giant science project to contemplate.

Yes, I kind of wish MongoDB had come out and said what they are doing to help Epic Games here if this is something to address that issue or what the plan/thoughts are on the most newsworthy usage of MongoDB in a while.

Re: MongoDB gets support for multi-document ACID transactions

#124

Post by da_chicken »

e12e wrote: post #59
drcongo wrote: post #16

Earlier quoted context omitted.

There's a whole 'nother generation of devs coming through who have never been burned by MongoDB though. Obviously they will be eventually, but by then another generation will come along to repeat the cycle.

I love deriding mongodb as much as the next dev that hasn't used it much; but I'll just note that while I'd still be hard pressed to prefer mysql over postgres - there was a long period where mysql was put to tasks it was ill suited for, especially prior to around version 4.x. So while "hype first" might reap a deservedly abundant and bitter harvest of developer hatred - it doesn't preclude evolving into a genuinely…

Both true, although I can completely understand why devs went with MySQL over PostgreSQL at that time. I remember that during the same time period that MySQL was drawing seemingly endless criticism for generally poor RDBMS behavior (3.x and 4.x), PostgreSQL was notorious for having poor performance due to insanely undersized default settings. Like out of the box it was sized to run with at most 10 MB of RAM or similar that was just unrealistic.

I also remember it also had a lot of quirks and missing features prior to v8. I assume it was leftover cruft from Ingres, but I remember PostgreSQL v6 and v7 being unreasonably complicated to get configured just because the defaults were so off reality.

One thing you can say about PostgreSQL, though, is that it's developers don't rest on their heels. Every major release packs in a ton of new features. They've gone from being fairly low or middling on the feature set to being pretty near the top. Even point releases have me saying, "Wow, that's really nice to have."

Re: MongoDB gets support for multi-document ACID transactions

#126

Post by tejasmanohar »

crdoconnor wrote: post #97
tejasmanohar wrote: post #60

Earlier quoted context omitted.

>Most people that “get it right” the first time around do not get any recognition whatsoever. I've heard similar complaints before. And, I get it, too-- at a glance, that person is playing the "superhero" by saving the project. But, good management will insist on root causing failures where this will unravel. If it's a recurring problem, you should bring it up with management.

>But, good management will insist on root causing failures where this will unravel. You can have management that understand tech who will get to the bottom of the problem and you can have management who don't understand tech. They won't. Management who don't understand tech will either keep somebody on hand who they know and trust who does understand tech (e.g. a consultant) or, more likely, they'll just keep rewardi…

I'd say that good management needs to understand how their subordinates think and operate, even if they haven't played their exact role (e.g. engineer). The best managers that I've worked with, both lateral (e.g. PM) and direct (e.g. EM), take the time to get familiar with engineering processes if they don't know about them already and speak their language.

Re: MongoDB gets support for multi-document ACID transactions

#127

Post by chipotle_coyote »

jeffdavis wrote: post #96
luckydata wrote: post #72

Earlier quoted context omitted.

If you're playing the long game and not looking to make a profit that's fine, but PostgreSQL as a company would have been doomed a long time ago. You have to keep in mind the timelines of the business and what they need to do to keep the lights on. MongoDB has identified a real pain point: many developers don't like to use SQL to interface with a transactional database. I'm not going into the merits of SQL vs. NoSQL,…

"PostgreSQL as a company would have been doomed a long time ago" PG has astonishing feature throughput . With each yearly release, they add 1-3 wow features, 6-10 major features, and countless smaller features still worthy of the release notes. That's really, really impressive for any database, commercial or otherwise. There's a perception that postgres is slow to add features because sometimes the feature latency is…

Postgres has kept the lights on for a lot of companies for a long time. I absolutely reject the idea that good engineering is at odds with business success.

I don't think they're at odds, per se, but having been around through the original dotcom bubble, PostgreSQL (or "Postgres95," as I'm pretty sure it was still called when I was introduced to it!) was mostly known to, well, database nerds for at least the first decade of its life. One person's "solid foundation" is another person's "technically correct but practically crawling" -- a perception that, rightly or wrongly, PostgreSQL fought against for a very long time. And I think that's what OP was trying to get at: if PostgreSQL was being developed primarily by a single VC-funded company, they just might not have had the luxury to spend years building that solid foundation.

(I'll allow that as an ex-RethinkDBer, I may have some bias here: I loved many things about the product and especially about the product, but it's hard not to suspect we should have focused on speed and, y'know, revenue earlier than we did.)

Re: MongoDB gets support for multi-document ACID transactions

#129

Post by derekperkins »

munk-a wrote: post #99
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.

Yes, come over to the actually greener lawn of Postgres, it is amazing how much more powerful than MySQL it has become with recursive CTEs https://www.postgresql.org/docs/current/static/queries-with.... and some rather amazing JSON support https://www.postgresql.org/docs/current/static/functions-agg...

JSON has been great in MySQL for a few years now since 5.7, and recursive CTEs are coming in the next couple months with 8.0. I don't think you can make a wrong choice between the two these days, but choosing Mongo over either is almost always the wrong decision.

https://www.infoworld.com/article/3228154/sql/whats-new-in-m...

Re: MongoDB gets support for multi-document ACID transactions

#130

Post by SamReidHughes »

nailer wrote: post #67
nulagrithom wrote: post #61

Earlier quoted context omitted.

I used it about 3 years ago and my first thought was "How broken will multi-document ACID transactions be?" I still want to like MongoDB, I still miss its style of query vs SQL, but I'd have a hard time advocating its use again... Sometimes it's tempting to use it for projects that I know will remain small, but even then it's not worth the overhead of standing up a different DB when I have a perfectly good SQL server…

Check out Rethink. It seems to be what you're after.

It's probably better to go with Cockroach or TiDB. RethinkDB has problems of its own.
Post reply on HN