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

Re: MongoDB gets support for multi-document ACID transactions

#51

Post by sixdimensional » Thu, Feb 15, 2018, 4:37 PM UTC

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.

Just remember, SQL is and always was "not only relational" - a play on the, should be long dead and buried acronym NoSQL (IMHO). Structured query language - I know for a fact from actually doing it (see Cache database, Hadoop schemaless SQL, even a product I worked on that was SQL to Mongo, heck the SQL standard itself) - guess what - it works with object/document stores too!

Mongo could have implemented SQL on top of their storage engine a long time ago minus the joins. Instead they built their own query mechanisms. Mind you, mapreduce can't be reproduced explicitly in SQL, but SQL expressions can compile to Mapreduce (see Apache Hive), so even that was not an excuse.

Edit: NoSQL served a purpose to remind people that there were other options other than relational databases (including those that predate the relational model and those that came after it), but man, what a terrible and misleading misnomer.

Re: MongoDB gets support for multi-document ACID transactions

#52

Post by nemild » Thu, Feb 15, 2018, 4:41 PM UTC

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

Re: MongoDB gets support for multi-document ACID transactions

#53

Post by jasondc » Thu, Feb 15, 2018, 4:42 PM UTC

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

Re: MongoDB gets support for multi-document ACID transactions

#54

Post by malloryerik » Thu, Feb 15, 2018, 4:45 PM UTC

mcintyre1994 wrote: post #7

Waterluvian wrote: post #3

Earlier quoted context omitted.

That's what I was wondering too. It feels like SQL and NoSQL will meet in the middle: JSON with SQL support, SQL with JSON support.

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?

Re: MongoDB gets support for multi-document ACID transactions

#55

Post by amelius » Thu, Feb 15, 2018, 4:46 PM UTC

btown wrote: post #21

Lest we forget, we should wait for an Aphyr/Jepsen analysis before jumping to use this in production: it could go either the way of https://aphyr.com/posts/284-jepsen-mongodb or https://jepsen.io/analyses/mongodb-3-4-0-rc3

Good point!

The code is almost completely new, so definitely a thorough testing is required.

Re: MongoDB gets support for multi-document ACID transactions

#56

Post by outside1234 » Thu, Feb 15, 2018, 4:46 PM UTC

"Ship and iterate" almost always wins over "perfect and ship"

Re: MongoDB gets support for multi-document ACID transactions

#57

Post by misterbowfinger » Thu, Feb 15, 2018, 4:47 PM UTC

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

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 hodge-podge of interfaces that have no discernible consistency or unity of vision.

I mean... that's unfathomable to me too. He explains it later, that " MongoDB turned regular developers into heroes when people needed it"

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?

Re: MongoDB gets support for multi-document ACID transactions

#58

Post by vog » Thu, Feb 15, 2018, 4:48 PM UTC

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

Re: MongoDB gets support for multi-document ACID transactions

#59

Post by e12e » Thu, Feb 15, 2018, 4:51 PM UTC

drcongo wrote: post #16

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…

There's a whole 'nother generation of devs coming through who have never been burned by MongoDB though. Obviously they will be eventually, but by then another generation will come along to repeat the cycle.

I love deriding mongodb as much as the next dev that hasn't used it much; but I'll just note that while I'd still be hard pressed to prefer mysql over postgres - there was a long period where mysql was put to tasks it was ill suited for, especially prior to around version 4.x.

So while "hype first" might reap a deservedly abundant and bitter harvest of developer hatred - it doesn't preclude evolving into a genuinely useful product...

Re: MongoDB gets support for multi-document ACID transactions

#60

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

FPGAhacker wrote: post #28

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

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.