MongoDB gets support for multi-document ACID transactions • Hacker News Board

Re: MongoDB gets support for multi-document ACID transactions

#61

Post by nulagrithom » Thu, Feb 15, 2018, 4:55 PM UTC

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 used it about 3 years ago and my first thought was "How broken will multi-document ACID transactions be?"

I still want to like MongoDB, I still miss its style of query vs SQL, but I'd have a hard time advocating its use again...

Sometimes it's tempting to use it for projects that I know will remain small, but even then it's not worth the overhead of standing up a different DB when I have a perfectly good SQL server I can muddle through already.

Re: MongoDB gets support for multi-document ACID transactions

#62

Post by jeremiep » Thu, Feb 15, 2018, 4:57 PM UTC

drmirror wrote: post #12

overcast wrote: post #2

Next up will be SQL compliance, and we'll be back to a relational database. I'm curious as to what the impact to speed will be, and what the use cases for these types of databases is now that the major SQL players support JSON.

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 model it using documents.

You always end up with either tons of duplication across documents, which is hell to maintain, or tons of multi-document queries with hacks to look ACID, which is also hell to maintain.

Sure Mongo makes it easy to prototype applications, but it makes it very complex to build robust and maintainable software. Its especially bad if you think your data isn't relational, because it almost certainly is.

Disclaimer: I believe Datomic to be the game changing database; because it values simplicity and composition and these attributes drive the entire design.

Re: MongoDB gets support for multi-document ACID transactions

#63

Post by riku_iki » Thu, Feb 15, 2018, 4:57 PM UTC

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.

Re: MongoDB gets support for multi-document ACID transactions

#64

Post by segmondy » Thu, Feb 15, 2018, 5:01 PM UTC

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

You test triggers the same way you test any code.

You setup your preconditions, you execute any action, you assert your post condition. You can use something like http://pgtap.org/documentation.html to write your database tests.

Triggers have a place in app development, and sometimes are the best things to use.

Re: MongoDB gets support for multi-document ACID transactions

#65

Post by mathieuuu » Thu, Feb 15, 2018, 5:01 PM UTC

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:

- Mongo has been built to store json objects -> Yes, but from what I understand benchmarks indicate that PostgreSQL is faster at reading/storing/indexing json/jsonb content. I don't think that it is good reason to use it.

- Mongo is schemaless -> There might be some usecases, but I bet in most cases this problem can be worked around. Especially in a database with JSONB support.

- MongoDB horizontal scaling is way easier than PostgreSQL. Yes, it seems that scaling horizontally Mongo is extremely easy compared to any other relational database.

And ... that's it. But there is probably more.

At the moment, here's how I would summarize MongoDB benefits if asked my opinion when starting a project:

- For a small projects or a prototype: ease of use, ease of configuration, don't require too much thinking into my data model while I am experimenting

- For a bigger project: horizontal scaling should be easier

Does that sound accurate to you? Am I missing anything important?

Re: MongoDB gets support for multi-document ACID transactions

#66

Post by Pxtl » Thu, Feb 15, 2018, 5:04 PM UTC

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.

Re: MongoDB gets support for multi-document ACID transactions

#67

Post by nailer » Thu, Feb 15, 2018, 5:05 PM UTC

nulagrithom wrote: post #61

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…

I used it about 3 years ago and my first thought was "How broken will multi-document ACID transactions be?" I still want to like MongoDB, I still miss its style of query vs SQL, but I'd have a hard time advocating its use again... Sometimes it's tempting to use it for projects that I know will remain small, but even then it's not worth the overhead of standing up a different DB when I have a perfectly good SQL server…

Check out Rethink. It seems to be what you're after.

Re: MongoDB gets support for multi-document ACID transactions

#68

Post by ChicagoDave » Thu, Feb 15, 2018, 5:05 PM UTC

BillinghamJ wrote: post #32

ChicagoDave wrote: post #25

This is interesting, especially for micro-service architectures (one table, one service) that need to modify multiple tables.

No, it doesn’t work for that use-case. It would all need to happen within a single service in a single invocation. To enable transactions across network boundaries, you need to enable the transactional safety at the application/API level. And, for the record, one service per table is a terrible idea. It would have none of the benefits of a service-oriented architecture, while adding all the complexity and caveats of…

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.

Re: MongoDB gets support for multi-document ACID transactions

#69

Post by redwood » Thu, Feb 15, 2018, 5:06 PM UTC

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.

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.

Re: MongoDB gets support for multi-document ACID transactions

#70

Post by luckydata » Thu, Feb 15, 2018, 5:10 PM UTC

tejasmanohar wrote: post #60

FPGAhacker wrote: post #28

Earlier quoted context omitted.

There is a trend I noticed where I work. Most people that “get it right” the first time around do not get any recognition whatsoever. It is the people that screw up, release with big flaws that the customer then pressures the company about, that are heralded as heroes and bacon savers when the fix those flaws. After 3 years and as many releases.

>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 to escalate issues that threaten the well being of the product or the team but that their direct superior doesn't believe are urgent etc...

Developers complain about management but tend to forget that managers are people just like everyone else, and we need to apply some skill to our interactions if we are to get the results we desire.