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

231–240 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#231

Post by jmakeig »

nithril wrote: post #223
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,…

> MongoDB has identified a real pain point: many developers don't like to use SQL to interface with a transactional database. The pain point relates less to SQL but more to the RDBMS and the rigid schema. SQL is spreading and may become a ubiquitous query language.

The problem isn’t the schema, it’s that you must have exactly one at all times. Sometimes you need zero, sometimes you need many. Having a fixed schema in production reduces unpredictability and provides optimization opportunities. The journey to get to that fixed schema, however, generally benefits from more flexibility.

Re: MongoDB gets support for multi-document ACID transactions

#232

Post by overcast »

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

I think many high profile games have over the last few years, have proven this does not work. Gamers are finally fighting back with their wallets.

Re: MongoDB gets support for multi-document ACID transactions

#233

Post by stevenwoo »

Thaxll wrote: post #188
stevenwoo wrote: post #155

Earlier quoted context omitted.

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.

OK I should have been clearer about my interpretation - I read flying in experts as they flew in experts from MongoDB and stumped them so that had me thinking maybe this is not possible if they stumped them. Earlier in this thread one of the engineers from MongoDB says Epic solved the issue but had not updated the blog so I was wrong about that.

Re: MongoDB gets support for multi-document ACID transactions

#234

Post by jbellis »

alyson-cabral wrote: post #19

I'm the Product Manager on the Core Server responsible for the multi-document transactions project. For those of you interested in learning more about how we're building transactions in MongoDB, I suggest checking out this video that discusses creating WiredTiger timestamps to enforce correctness in operation ordering across the storage layer. The description is presented by Dr. Michael Cahill, the co-founder of the…

Hi Alyson,

Thanks for the link! It looks like the video covers using timestamps to implement replicated mvcc correctly from primary to other replicas.

The interesting next step is how you go from there to multi-document across different primaries. Or is this limited to documents in a single shard?

Re: MongoDB gets support for multi-document ACID transactions

#235

Post by overcast »

jaequery wrote: post #93

Mongodb can be quite a nightmare once you start requiring anything more than a 1:1 relationship, which is pretty much any kind of app that is doing anything meaningful. Having to resort to doing things like map/reduce for a simple group by / order is not the way to go IMO. I think you later truly realize the beauty of SQL once you get far down that rabbit hole. Initially I rode on the Mongo's NoSQL bandwagon when I s…

"Also, I don't know who codes using raw SQL, it's been years languages have had ORMs that made queries look just like a Mongo query."

Baloney. Anything relatively complex will definitely require you to optimize in raw SQL. Abstracting all that out in an ORM is horrible.

Re: MongoDB gets support for multi-document ACID transactions

#236

Post by neovive »

furicane wrote: post #24
neovive wrote: post #13

Has anyone worked with MySQL JSON data types in production? For most projects, I prefer working in SQL via a query builder or ORM for abstraction, but find a few features that would benefit from denormalized JSON storage.

I've been using MySQL 5.7 since its release in production. I used to store JSON data in a blob, but when they released JSON support - I just couldn't wait to use it. It's working really, really good. JSON support solves a ton of problems we used to have, and we used EAV model to tackle those problems (I won't get into details, the discussion will go the other way). I deal with a few hundred MySQL deployments ranging…

Thanks for the advice and vote of confidence in MySQL JSON support. I don't anticipate reaching that kind of scale, but it's great to hear about large, successful, production deployments. These days I try to stick with a very stable back-end stack and innovate more on the front-end.

Re: MongoDB gets support for multi-document ACID transactions

#237

Post by krylon »

metheus wrote: post #121
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-ma…

It will be interesting to learn about database design in a non-relational environment. I guess you can replicate a relational structure in MongoDB, but then why not use an RDBMS in the first place?

As far as I understand it, MongoDB's claim to fame is a) handling huge amounts of data and b) clustering. Neither of these apply to me, so the only reason to use Mongo would be data that does not match the relational model well. I am still looking for a use case, any use case, that might make a valid excuse to learn it, but so far I have come up empty.

I am a little worried that I am facing a situation somewhat like the one when I tried to learn Lisp. Learning Lisp was very hard for me because I had absorbed the structured programming approach so deeply that the functional part of Lisp programming seemed downright alien to me. At first, at least. So for the time being, I cannot tell with any certainty if problems that are a good match for a document store are just so rare, or if I am just incapable of modeling my data in ways other than the relational model.

Re: MongoDB gets support for multi-document ACID transactions

#238

Post by metheus »

takeda wrote: post #210
metheus wrote: post #195

Earlier quoted context omitted.

The EnterpriseDB benchmark is just a hit piece. See https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postg...

> It is benchmarking PostgreSQL psql against MongoDB Javescript shell (SpiderMoney/v8). That’s not a very fair benchmark is it? Isn't javascript engine used whenever you interact with MongoDB?

Goodness, no.

Re: MongoDB gets support for multi-document ACID transactions

#239

Post by metheus »

krylon wrote: post #237
metheus wrote: post #121

Earlier quoted context omitted.

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-ma…

It will be interesting to learn about database design in a non-relational environment. I guess you can replicate a relational structure in MongoDB, but then why not use an RDBMS in the first place? As far as I understand it, MongoDB's claim to fame is a) handling huge amounts of data and b) clustering. Neither of these apply to me, so the only reason to use Mongo would be data that does not match the relational model…

Think about it less in terms of relational/non-relational and more in terms of tabular/document. Tables can only model things in terms of relations. Documents can model them either as embedding or as external references, depending on access patterns.

A decent example is a person record with their email addresses and phones. In a relational DB, you would always and only model those as three sepearate tables, and you would quite frequently need a three way join to assemble that person again.

In MongoDB, you would definitely have an array of emails and an array of phone numbers embedded in that person document, sparing the join on those queries. But in an ecommerce context, you would likely not embed an array of all past orders with all the line items into that person, instead you’d have an array of previous order numbers.

But an order document would have an embedded array of line items, sparing the DB a bunch more joins (and the attendant indices you’d need for joining line items to orders efficiently).

Getting the 10 most recent orders from a customer would involve joining the customers collection with the orders collection (MongoDB’s join is the `$lookup` aggregation stage), but it wouldn’t involve joining the line items to the order.

Is that replicating a relational structure? A little column A, a little column B.

Re: MongoDB gets support for multi-document ACID transactions

#240

Post by ChicagoDave »

Fins wrote: post #230
ChicagoDave wrote: post #226

Earlier quoted context omitted.

Application architecture is inherently malleable, yes. But when properly implemented, micro service architecture is actually a great idea. I can’t help if your experience has not been the same as mine.

Certainly, one can architect anything, use NoSQL for critical data storage, or use Kafka for synchronizing two SQL databases with the same schema and living on the same netowrk(an actual proposal from a fan of microservices, btw). But whether it should be done is another question, and I have yet to see a single example of microservices being a good idea. Not "it works" -- obviously, you can get it to work, but being…

The Accenture link I posted is a living example of a highly successful micro-services architecture in a critical internal application in a large corporation.

What more do you want?

Post reply on HN