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

141–150 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#141

Post by tensor »

s_kilk wrote: post #92
misterbowfinger wrote: post #57

Earlier quoted context omitted.

From that post mortem: It was unfathomable to us why people would choose a system that barely does the thing it’s supposed to do (store data), has a big kernel lock, throws away errors at random, implements single node features that stop working when you shard, has a barely working sharding system despite it being one of the core features of the product, provides essentially no correctness guarantees, and exposes a h…

> I have a hard time understanding why devs choose / chose MongoDB. Postgres with JSON columns gets you so far, why would you go with MongoDB, given the issues it's had? Jsonb is a pretty recent addition to postgres, when compared with the MongoDB timeline. And even today postgres still doesn't have the replication/failover story that made MongoDB pretty compelling. I know, it's coming, whatever, but the point is tha…

The problem with that thinking is that the replication mattered. I'd argue it didn't, it was essentially a scam that people fell for. Who cares about failover when you're losing data due to a bad implementation? Who cares about replication when you can gain the same performance by using a performant database on a single node?

Did mongodb truly allow anyone to really horizontally scale? Most places that need massive horizontal scaling using something like mysql as far as I know.

Re: MongoDB gets support for multi-document ACID transactions

#142

Post by eksemplar »

SCdF wrote: post #11
_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 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…

I work in a Danish muniplicity. Traditionally we've build everything on SQL because it's the world we function in, but we adopted the MEAN stack as a proof of concept a few years back and Mongo has been growing ever since.

It does require building and maintaining schemas in a different manner, but when you do that, it's pretty great to work with, especially when we're doing design driven development that consists of a lot of prototyping.

I'm a fan, but I'm a manager on business development and digitisation, so I may be a little sheltered from whatever annoyances it may cause in operations.

Re: MongoDB gets support for multi-document ACID transactions

#143

Post by tensor »

lkrubner wrote: post #74

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently…

For good or bad, even though they've fixed these problems, I still don't have any trust in them as a company and will never recommend or look at their product. For me, their early days behaviour has defined their values as a company, and those are values I don't trust or agree with.

If they were willing to nearly scam people once, what is to stop them again in the future? Clearly their motive is money over quality and without a serious change of management I don't see why anyone should consider that they've changed.

Re: MongoDB gets support for multi-document ACID transactions

#144

Post by thawkins »

BillinghamJ wrote: post #120
ChicagoDave wrote: post #68

Earlier quoted context omitted.

Except I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.

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…

Not even using 'XA'?

Re: MongoDB gets support for multi-document ACID transactions

#145

Post by ChicagoDave »

BillinghamJ wrote: post #120
ChicagoDave wrote: post #68

Earlier quoted context omitted.

Except I've implemented it that way in highly visible, high traffic internal web applications that were lauded as some of the most successful transitions in company history in a very large corporation. So your argument is really legacy opinion and not relevant to micro-service architectures.

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 the encapsulation of a specific domain is the point and the primary benefit.

I have no idea what you're doing, but this is what I worked on:

https://www.accenture.com/us-en/success-performance-manageme...

Which proves that silo'd micro-services are cost-effective and produce real world results in a complex environment.

Feel free to knock more points off my karma. :)

Re: MongoDB gets support for multi-document ACID transactions

#146

Post by stevenwoo »

drmirror wrote: post #132
stevenwoo wrote: post #123

Earlier quoted context omitted.

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

Thanks for responding. I look forward to Epic updating their post mortem.

Re: MongoDB gets support for multi-document ACID transactions

#147

Post by vim_wannabe »

Pxtl wrote: post #66
mathieuuu wrote: post #65

We have been using mongo over the last three years on our project and it has been pretty smooth so far. However, lately I gave some thoughts into what our project would look like if we used PostgreSQL instead. I tried to figure out what problems Mongo solves that PostgreSQL doesn't. I am far from being a database expert, I just know enough basics to query what I need, so feel free to correct/complete the following: -…

Honestly, the existence of Mongo is mostly an indictment about how user-hostile conventional RDBMS is. The fact that other DBs can do what Mongo does is not helpful when there is no easy workflow to do what Mongo does. The fact that I theoretically implement a web-based CMS in C and it could be more performant than all these web-language CMS products doesn't mean that C is better for making a CMS.

Mongo is truly the Javascript of databases. It's even made in JS!

Re: MongoDB gets support for multi-document ACID transactions

#148

Post by mat_keep »

furicane wrote: post #47
mat_keep wrote: post #35

Earlier quoted context omitted.

great. Do i declare i worked at mysql for 5 years as well? Both before and after Oracle acquisition

How's that relevant? You're neither lead architect nor does your employment at MySQL / Oracle mean anything. Many incapable developers score positions at big companies. Without facts, maths and measurement you can be Linus Torvalds for all I care. The article at the URL provided is simply marketing ploy. I'm experienced enough to notice what's wrong with the comparison, but I won't take that article apart to prove an…

it was the reference to me as "You're a prime example that this new-age bullshit works and that's what's worrying". The same statements were leveled at anyone from mysql 10-15 years ago. I'm glad mysql works well for your use-case

Re: MongoDB gets support for multi-document ACID transactions

#149

Post by aeorgnoieang »

nemo44x wrote: post #137
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…

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…

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

I find that hard to believe. Maybe not that the raw data isn't already relational, but that there are no relations real or implied.

If logs contain info about 'things' and any of those things can be considered to be the 'same thing' for multiple entries, then there's a relation right there – entry to thing.

And even metrics and network event data I'd expect to be full of cryptic IDs that reference some 'thing', i.e. a typical 'code' for which it's really nice to have a table with at least a friendly description.

Admittedly some of this data – or maybe even most of this data – isn't very 'deeply relational', but it definitely seems that claiming that "there are [no] relations in it" isn't strictly true.

Re: MongoDB gets support for multi-document ACID transactions

#150

Post by mat_keep »

vim_wannabe wrote: post #147
Pxtl wrote: post #66

Earlier quoted context omitted.

Honestly, the existence of Mongo is mostly an indictment about how user-hostile conventional RDBMS is. The fact that other DBs can do what Mongo does is not helpful when there is no easy workflow to do what Mongo does. The fact that I theoretically implement a web-based CMS in C and it could be more performant than all these web-language CMS products doesn't mean that C is better for making a CMS.

Mongo is truly the Javascript of databases. It's even made in JS!

its mainly written in C++ and C
Post reply on HN