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

11–20 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#11

Post by SCdF »

_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 of MongoDB to ever want to use it again.

Re: MongoDB gets support for multi-document ACID transactions

#12

Post by drmirror »

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 available. There is no speed impact on cases when you don't use them. And most of the time, you shouldn't use them, otherwise you wouldn't be capitalizing on the advantages of JSON. I think that's a game changer, but then again: I do work for MongoDB.

Re: MongoDB gets support for multi-document ACID transactions

#14

Post by toomuchtodo »

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.

Use PostgreSQL.

https://www.postgresql.org/docs/10/static/datatype-json.html

Re: MongoDB gets support for multi-document ACID transactions

#15

Post by nathan_long »

andy_ppp wrote: post #9
_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 agree here, but I’d go further; build things people want, not the idealistic future some day version where we eventually get to a priority feature for a lot of people like releasing fast scalable software quickly (I’m not saying Rethink didn’t do this but they prioritised correctness and sharding, features fewer people need). For most apps built with Mongo this transaction support isn’t a problem (until it is).

Both approaches have downsides.

The TCP/IP stack was built and used while the OSI model was being designed, and it won all the mindshare. Perhaps it would have been better to have separate presentation and session layers, but we don't; the application layer handles that stuff. It works well enough.

OTOH, this quote is wise:

> It is easier to optimize correct code than to correct optimized code (Bill Harlan)

I think this is doubly true for databases; at least with obfuscated code, you can recover the underlying meaning with work and exploration.

Losing or corrupting data is the worst thing a database can do. Given "this will be correct and hopefully we can scale it" vs "this will be fast and hopefully we can keep it correct", I'd choose the former for any "source of truth" data every time.

There are tricks for speeding up queries - indexes, cacheing (including materialized views), sharding, read replicas, etc.

There are no tricks for recovering data you lost.

Re: MongoDB gets support for multi-document ACID transactions

#16

Post by drcongo »

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…

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.

Re: MongoDB gets support for multi-document ACID transactions

#17

Post by btown »

egeozcan wrote: post #8
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.

"Mongres is a PostgreSQL extension that runs a custom background worker speaks mongo wire protocol." https://github.com/umitanuki/mongres

There's also https://www.torodb.com/stampede/docs/1.0.0-beta3/relational-... which tails the Mongo oplog and makes a fully-relational read replica, adding columns and indices as needed. An amazing (and free) shortcut to using analytics tools if Mongo's your main datasource.

Re: MongoDB gets support for multi-document ACID transactions

#18

Post by andy_ppp »

nathan_long wrote: post #15
andy_ppp wrote: post #9

Earlier quoted context omitted.

I agree here, but I’d go further; build things people want, not the idealistic future some day version where we eventually get to a priority feature for a lot of people like releasing fast scalable software quickly (I’m not saying Rethink didn’t do this but they prioritised correctness and sharding, features fewer people need). For most apps built with Mongo this transaction support isn’t a problem (until it is).

Both approaches have downsides. The TCP/IP stack was built and used while the OSI model was being designed, and it won all the mindshare. Perhaps it would have been better to have separate presentation and session layers, but we don't; the application layer handles that stuff. It works well enough. OTOH, this quote is wise: > It is easier to optimize correct code than to correct optimized code (Bill Harlan) I think t…

> I think this is doubly true for databases; at least with obfuscated code, you can recover the underlying meaning with work and exploration.

True for databases, but not true for businesses.

> Losing or corrupting data is the worst thing a database can do.

Clearly people building simple crud websites with slick JS features didn’t agree otherwise Mongo would be gone and Rethink would be worth hundreds of millions of dollars.

Re: MongoDB gets support for multi-document ACID transactions

#19

Post by alyson-cabral »

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 WiredTiger storage engine aquired by MongoDB. https://www.mongodb.com/presentations/wiredtiger-timestamps-...

Re: MongoDB gets support for multi-document ACID transactions

#20

Post by mat_keep »

toomuchtodo wrote: post #14
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.

Use PostgreSQL. https://www.postgresql.org/docs/10/static/datatype-json.html

or not, as the case may be https://www.mongodb.com/compare/mongodb-postgresql
Post reply on HN