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

131–140 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#131

Post by hobofan »

stevenwoo wrote: post #39
SCdF wrote: post #11

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 have no idea how capable MongoDB is these days, as I haven't used Mongo in years (and even then it was not for long). However, I do not know any developers who, after living through the "hype first, features later" strategy, have been left with a positive enough opinion…

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.

> mentioned in passing they had stumped all the experts they could find to look at unsolveable issues they had with MongoDB

That's not really what the article is saying, unless we interpret the following text differently.

"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." -> "We have started to look into the problem together with experts" and not "Experts have tried and failed".

Re: MongoDB gets support for multi-document ACID transactions

#132

Post by drmirror »

stevenwoo wrote: post #123
redwood wrote: post #69

Earlier quoted context omitted.

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.

I am one of the team of MongoDB engineers working with Epic on this issue, and I can assure you that the situation is under control and we have everything in place to scale this application to much higher numbers. However, we're not publishing details about our support cases, especially while they are in progress. That is something for Epic to decide, and I do assume they will eventually say in public just how well MongoDB is, in fact, performing for them.

Re: MongoDB gets support for multi-document ACID transactions

#133

Post by threeseed »

btilly wrote: post #86
_wc0m wrote: post #6

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. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

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 other databases.

Re: MongoDB gets support for multi-document ACID transactions

#134

Post by javiermaestro »

fnayr wrote: post #101
jeremiep wrote: post #62

Earlier quoted context omitted.

Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to…

Video games storing player data are a great example of nonrelational data. I'm intending on writing a blog post after I finish my game detailing the structure of data I store and why it was so perfect for mongodb.

Please do, because I'm interested in seeing how non-relational it is... I truly believe it has to be otherwise, so I'd love to read your findings!

Re: MongoDB gets support for multi-document ACID transactions

#135

Post by andyana »

munk-a wrote: post #104
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,…

There seems to be two points in this comment, one talking about the development of PostgreSQL and the other talking about the usability of it. PostgreSQL remains one of the most mysteriously difficult common DBMSs to setup which is unfortunate, but since the advent of MongoDB they've adopted all the ease of use features that are warranted from it. Developing a quick-and-dirty product prototype on postgres is a breeze…

I find it easier to setup than MySQL, but with package managers today, both are a breeze. Can you explain why it is "mysteriously difficult"?

Re: MongoDB gets support for multi-document ACID transactions

#136

Post by jeffdavis »

chipotle_coyote wrote: post #127
jeffdavis wrote: post #96

Earlier quoted context omitted.

"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 de…

VC-backed startups are not the entire business world. Some businesses don't consider correctness a "technicality".

Re: MongoDB gets support for multi-document ACID transactions

#137

Post by nemo44x »

jeremiep wrote: post #62
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…

Its usually only after a while you realize almost every piece of meaningful data is relational. It just didn't look that way when the project started. But now you're committed on the wrong database and its very costly to switch back to SQL. Literally every project I saw using MongoDB ended up going back to SQL within the first 2 years after realizing the data is indeed very much relational and theres no clean way to…

Most meaningful data is in fact not relational. When you consider machine generated data, logs, metrics, network event data and all other types of data like this you find there are not relations in it.

This data is meaningful because it allows to analyze what's going on over massive systems, detect when problems will happen, find bottle necks in applications and infrastructure, among many other use cases.

Application domain data tends to be relational I'd agree. But in general, this makes up a very small percentage of meaningful data in the world.

Re: MongoDB gets support for multi-document ACID transactions

#138

Post by boubiyeah »

_wc0m wrote: post #6

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. The RethinkDB retrospective[0] contains a lot of insight into how MongoDB has succeeded despite being vastly inferior on a technical level back when it first launched. I have to admit them a certain respect for executing their strategy so successfully. Choice quote: Every t…

Agreed. It was a complete piece of crap when it was around version 1.4-1.6 but it's pretty good now!

Re: MongoDB gets support for multi-document ACID transactions

#139

Post by Thaxll »

stevenwoo wrote: post #39
SCdF wrote: post #11

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 have no idea how capable MongoDB is these days, as I haven't used Mongo in years (and even then it was not for long). However, I do not know any developers who, after living through the "hype first, features later" strategy, have been left with a positive enough opinion…

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.

Post reply on HN