Live data from Hacker News

MongoDB gets support for multi-document ACID transactions

techcrunch.com

1–10 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

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

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.

Re: MongoDB gets support for multi-document ACID transactions

#4
> At its core, MongoDB is a document database and — almost by default — these kind of databases aren’t ACID compliant, especially when it comes to multi-document transactions. For the most part, that’s not a big deal for companies that use database systems like MongoDB because they are not trying to write to multiple documents at the same time.

No. At least in the open-source world, you can see many applications make multi-document "transactions". I don't see how it would be different in companies using MongoDB.

> Because of this, though, many MongoDB users still run relational databases in parallel with their document database.

No. For the most part, they do write to multiple documents and not think about consistency.

At least the situation seems to be getting remedied. Better late than never.

Re: MongoDB gets support for multi-document ACID transactions

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

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.

Which is why I'm depressed RethinkDB failed to take off :(

Re: MongoDB gets support for multi-document ACID transactions

#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 time MongoDB shipped a new release and people congratulated them on making improvements, I felt pangs of resentment. They’d announce they fixed the BKL, but really they’d get the granularity level down from a database to a collection. They’d add more operations, but instead of a composable interface that fits with the rest of the system, they’d simply bolt on one-off commands. They’d make sharding improvements, but it was obvious they were unwilling or unable to make even rudimentary data consistency guarantees.

But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well.

[0] http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html

Re: MongoDB gets support for multi-document ACID transactions

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

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.

Re: MongoDB gets support for multi-document ACID transactions

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

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

Re: MongoDB gets support for multi-document ACID transactions

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

Re: MongoDB gets support for multi-document ACID transactions

#10
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…

Clearly the evidence bears out the success of that strategy, but it's hard not to summarize it as, "Apparently a lot of developers, applications, and users don't need a database that works." But I don't know what that's really an indictment of exactly.
Post reply on HN