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

71–80 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#71

Post by krylon »

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 things. I think I am going to look at it again sometime.

EDIT: Typo

Re: MongoDB gets support for multi-document ACID transactions

#72

Post by luckydata »

vog wrote: post #58
_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…

On the other hand, PostgreSQL is a very good example of a successful implementation of the opposite strategy, that is, "correctness first". And since PostgreSQL fills that niche very well (correctness + real ACID + extensibility + decent performance), maybe it was really PostgreSQL who killed RethinkDB?

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, I'm just stating that it's clear there's a need or they wouldn't have gotten any traction.

Now they are maturing the product to the point it might be a safe bet for some use cases, it remains to be seen if their approach to product development will pay dividends or the reputation they have created for themselves has created a time bomb that will eventually kill them.

Re: MongoDB gets support for multi-document ACID transactions

#73

Post by mcintyre1994 »

malloryerik wrote: post #54
mcintyre1994 wrote: post #7

Earlier quoted context omitted.

This is basically what Microsoft's Cosmos DB is, you store JSON documents, don't have to define a schema and you can query them with SQL.

And you can also bake in graph relations, right? How has your experience been with CosmosDB?

To be honest I've only used it for pretty trivial things, I didn't do any joins. From the docs [0] it looks like they only have self joins, so joining on children or something like that but not across documents/collections.

Depending how much graph relation stuff you need you might be better off just using the graph API. I have no experience with that though. Or they support a MongoDB API if that covers your needs too.

Like I said I've only done basic stuff, but I really liked it - it's performant and really easy to set up and use. I used the Python API and it was really easy, then I switched to the Node one to try using it in Azure functions (Python library imports aren't really supported there) and that's nice too - it uses promises and works great. It also doesn't feel like a giant lockin (IMO) - their APIs work anywhere and there's no magic in Azure AFAIK to make you put your compute there if you're using the Database.

[0] https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-sql...

Re: MongoDB gets support for multi-document ACID transactions

#74

Post by lkrubner »

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 fixed the problems he identified. Consider how the situation had evolved by 2017:

MongoDB 3.4 Passes Jepsen – The Industry’s Toughest Database Test

Jepsen Evaluation Demonstrates MongoDB Data Safety, Correctness & Consistency

On February 7th 2017, Kyle Kingsbury, creator of Jepsen, published the results of his tests against MongoDB 3.41. His conclusions:

"MongoDB has devoted significant resources to improved safety in the past two years, and much of that ground-work is paying off in 3.2 and 3.4. MongoDB 3.4.1 (and the current development release, 3.5.1) currently pass all MongoDB Jepsen tests….These results hold during general network partitions, and the isolated & clock-skewed primary scenario."

https://www.mongodb.com/mongodb-3.4-passes-jepsen-test

MongoDB has become an excellent document-store database. If you are still repeating FUD from 2010, then you are simply out of date. It's time to come up to speed on the reality of 2018.

Re: MongoDB gets support for multi-document ACID transactions

#75

Post by hunterjrj »

jasondc wrote: post #53
majidazimi wrote: post #49

Call me when they added Triggers, Stored Procedures, Common Table Expressions, Window Functions,...

Triggers?? Where you add some application logic to the database, 10 years go by, and no one has any idea how the triggers work? Or even how to test them? I've never seen triggers used successfully in any production application (maybe they work at first, but give them time, and a few code changes).

What you're describing is a fault in an organization's maturity with respect to documentation and NOT a fault of a database feature.

Re: MongoDB gets support for multi-document ACID transactions

#76

Post by williamstein »

luckydata wrote: post #72
vog wrote: post #58

Earlier quoted context omitted.

On the other hand, PostgreSQL is a very good example of a successful implementation of the opposite strategy, that is, "correctness first". And since PostgreSQL fills that niche very well (correctness + real ACID + extensibility + decent performance), maybe it was really PostgreSQL who killed RethinkDB?

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: https://www.citusdata.com

Re: MongoDB gets support for multi-document ACID transactions

#77

Post by williamstein »

nemild wrote: post #52
_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…

I also quoted Rethink's post in "The Marketing Behind MongoDB" in part 3 of my series on MongoDB: > I sympathize with RethinkDB's team — they did what thoughtful engineers are trained to do. Engineering purity and humility is a tiny part of building a sustainable, venture-backed company. https://www.nemil.com/mongo/

Despite their claims to the contrary, RethinkDB also released and claimed 'ready for production use' a version of the product that was pretty broken. I used it heavily and hit numerous serious bugs. The RethinkDB devs did do a very good job of tracking down and fixing them. Software is hard.

Re: MongoDB gets support for multi-document ACID transactions

#78

Post by scarface74 »

riku_iki wrote: post #63
scarface74 wrote: post #46

I keep hearing about how people have been burned by Mongo but nothing specific. Does anyone care to give any specifics?

I never used MognoDB, but read many stories that few years ago MognoDB default configuration permitted data loss: server returned write success response to client without syncing data to replica or disk, and if your server died then your data gone. Additionally some time ago MongoDB had single-threaded writes with collection level lock, which could cause poor write performance.

That's one thing I keep "hearing". The default configuration now is a WriteConcern of 1 - meaning at least the primary has to have written it successfully. You can choose 2 or majority among others.

Re: MongoDB gets support for multi-document ACID transactions

#80

Post by Fiahil »

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

While MongoDB might be a decent document store, I found that Elasticsearch is better at this job (as a secondary datastore). Its aggregation capabilities are juste far better than MongoDB's with the added bonus of being really good for all kind of searches.
Post reply on HN