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

171–180 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#171

Post by threeseed »

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.

Not sure if you are aware but what you are asking for never happens.

It is not professional or appropriate for vendors to be revealing (a) that clients are having issues and need support and (b) the specific workings of technologies or processes within the client's business.

Re: MongoDB gets support for multi-document ACID transactions

#172

Post by mycelium »

luckydata wrote: post #70
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.

My biggest gripe as a "lateral manager" (I don't manage engineers, I manage products) is that I see those things happen all the time, and I spend time coaching developers to interact effectively with their managers as much as I can. It's frustrating when I see people that should know better (because I know they heard me) not taking notes about serious issues they want to discuss with their superiors, not knowing how…

This completely squares with my experiences as well — a lot of instances of complaints about management are hollow because developers aren't managing upward correctly. Their followup on their issues is missing, or non-actionable.

Do you have any resources you've found helpful improving your skill at this?

Re: MongoDB gets support for multi-document ACID transactions

#173

Post by mustardo »

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.

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 you can use third party tools) or changing queries to expect data in multiple "schemas" which quickly gets painful

Good Luck!

Re: MongoDB gets support for multi-document ACID transactions

#174

Post by karmakaze »

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.

Funny to list MySQL here which preceded MongoDB with cheap/fast now, correctness later.

Re: MongoDB gets support for multi-document ACID transactions

#175

Post by mustardo »

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 onerous is mostly on the developer...

For any "real" system that is going to be in production for a long time this becomes a real problem

There are tools to "migrate" data but they come with all the limitations of the Mongo isolation model

Typically you either

* Write ad hoc (possibly using some tooling) code to iterate over your old data adding or mutating the field(s) in question

* Write queries such that they can handle the data being present, absent or in different forms for all of time. As you could expect this is a large burden

Re: MongoDB gets support for multi-document ACID transactions

#176

Post by fnayr »

mustardo wrote: post #173
fnayr wrote: post #101

Earlier quoted context omitted.

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.

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…

Yes players can sell items to other players, so that's the one place so far I've needed to worry about atomicity, but even mongodb docs give examples with how to deal with something like that: https://docs.mongodb.com/manual/tutorial/perform-two-phase-c...

So yes, it's annoying for a very small % of what I'm doing, but 99% of my updates/writes are within a single document, so I find it very nice for development.

Re: MongoDB gets support for multi-document ACID transactions

#177

Post by NeoBasilisk »

Bitcoin_McPonzi wrote: post #128

What I like most about MongoDB is that it's "web scale" http://www.mongodb-is-web-scale.com/ It's because of shards. Shards are the secret ingredient in the web scale sauce. They just work.

I will never stop loving this. Here is a youtube link in case anyone can't/won't run flash on that site.

https://www.youtube.com/watch?v=b2F-DItXtZs

Re: MongoDB gets support for multi-document ACID transactions

#178

Post by user5994461 »

jeffdavis wrote: post #136
chipotle_coyote wrote: post #127

Earlier quoted context omitted.

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".

And those have been using Oracle, or Sybase or IBM for 3 decades.

Re: MongoDB gets support for multi-document ACID transactions

#179

Post by drmirror »

mustardo wrote: post #173
fnayr wrote: post #101

Earlier quoted context omitted.

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.

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.

Re: MongoDB gets support for multi-document ACID transactions

#180

Post by mygo »

mustardo wrote: post #173
fnayr wrote: post #101

Earlier quoted context omitted.

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.

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…

> 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 you can use third party tools) or changing queries to expect data in multiple "schemas" which quickly gets painful

You can have schemas with MongoDB. There are various libraries to facilitate database design by schema specification.

Also renaming or restructuring your data is not necessarily an easy task with SQL. The nature of a database dictates that how good it works for your application depends on up to how well thought-out your schema is. Having to change your schema around is tasking. One of the reported advantages of document stores when they were becoming trendy was that it was easy to change your schema since your schema is essentially determined and regulated at the application layer.

Also MongoDB has ACIDic transactions now (freaking finally) so if it’s as-advertised then I feel like half of your argument is not really a strong one any more.

Post reply on HN