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

201–210 of 245 posts

Re: MongoDB gets support for multi-document ACID transactions

#201

Post by SamReidHughes »

fastest963 wrote: post #167
SamReidHughes wrote: post #130

Earlier quoted context omitted.

It's probably better to go with Cockroach or TiDB. RethinkDB has problems of its own.

We are in the process of evaluating CockroachDB vs Rethink internally and we've found CockroachDB to perform very poorly without obvious disk or CPU issues. I'm curious if you've seen different especially as it relates to Rethink.

I didn't do comparisons. But RethinkDB has straightforward issues like a slow QL implementation using a lot of CPU and a lot of disk space usage. Change feeds have a few scaling issues if you want a lot of them. I don't know that it has mysterious kinds of excessive resource usage. I'm a dev of RethinkDB, not an end user, so I might be seeing the worst side of it. I haven't used Cockroach or TiDB.

Re: MongoDB gets support for multi-document ACID transactions

#202

Post by chris_wot »

mygo wrote: post #180
mustardo wrote: post #173

Earlier quoted context omitted.

On the surface it sounds like you might have a case for Mongo, lookout for scenarios like... * Trading in game items between two users (needs multi document atomic locks if you don't want duplicate or lost items) assuming your "schema" is a document per user * You want to rename or restructure an attribute in the future, with no schema it's not possible change migrate data easily without writing ad hoc code (maybe yo…

> You want to rename or restructure an attribute in the future, with no schema it's not possible change migrate data easily without writing ad hoc code (maybe you can use third party tools) or changing queries to expect data in multiple "schemas" which quickly gets painful You can have schemas with MongoDB. There are various libraries to facilitate database design by schema specification. Also renaming or restructuri…

If you need a schema, then go with an RDBMS.

Re: MongoDB gets support for multi-document ACID transactions

#203

Post by dankohn1 »

woolvalley wrote: post #153
Thaxll wrote: post #139

Earlier quoted context omitted.

- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…

You can cluster with postgres & mysql, but you have to implement the clustering / sharding logic yourself. Nowadays I would just use redis & cassandra if you need something beyond a collection of postgres instances. Most projects do not.

For clustering MySQL, take a look at Vitess. It was developed at YouTube and recently adopted into CNCF:

https://www.cncf.io/blog/2018/02/05/cncf-host-vitess/

(Disclosure: I'm executive director of CNCF.)

Re: MongoDB gets support for multi-document ACID transactions

#204

Post by ams6110 »

golergka wrote: post #103
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 don't know much about MongoDB. I am mostly a client-side developer after all. But every time I see a team transitioning from Mongo to something else, they transition to a relational database. May be their problem is not with MongoDB, but that their data is relational after all? Personally, I'd take a relational db over NoSQL for most of my needs, but all these stories don't really say anything about how Mongo compa…

> every time I see a team transitioning from Mongo to something else, they transition to a relational database

They are repeating the discoveries that people made in the 1970s about storing data in flat files vs. relational models.

Know history or be doomed to repeat it and all that.

Re: MongoDB gets support for multi-document ACID transactions

#205

Post by takeda »

Thaxll wrote: post #139
stevenwoo wrote: post #39

Earlier quoted context omitted.

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.

- That's not what they said. - You think people replace a MongoDB cluster by a single Posgres instance? You guys should really use HA, cluster in real life and stop reading reddit / HN and the hype behind PG, with 3.5M+ CCU no one would use an architecture with a single master / slave ( that's what pg is ). MongoDB / MySQL have bad press by people that never used it in real life and just repeat what they read online.…

> I could tell you horror story about pg not have an official replication system until 2011 when pg 9.0 landed.

I could tell you a horror story that happened to me just few weeks ago, where MariaDB just corrupted data out of nowhere due to a bug[1]. This happened multiple times and costed us multiple hours of work (including service being down) each time it happened until we realized the issue wasn't hardware but a software bug.

If you ask me, I take PostgreSQL approach of not having a broken replication before 2011 than MySQLs still corrupting data. Data usually is the most valuable asset a company has.

[1] https://jira.mariadb.org/browse/MDEV-10977

Re: MongoDB gets support for multi-document ACID transactions

#206

Post by spamizbad »

metheus wrote: post #192
spamizbad wrote: post #165

Earlier quoted context omitted.

Aggregates carry with them a memory limit. We currently use MongoDB 3.4. It's definitely much improved. The replication protocol that came along with 3.4 has been very reassuring. But aggregate queries really do not give you the power of SQL. They are great for transforming stuff for a report, but I would avoid using them for anything else unless 1) it can be cached (and therefor properly invalidated) and 2) doesn't…

>Aggregates carry with them a memory limit. I think you are referring to the 100MB RAM limit, but that’s not a hard limit, it’s more of a bad default. The `allowDiskUse` option lets MongoDB write intermediate results to the disk (which is exactly what SQL databases are doing). > But aggregate queries really do not give you the power of SQL. They are great for transforming stuff for a report, but I would avoid using t…

> I think you are referring to the 100MB RAM limit, but that’s not a hard limit, it’s more of a bad default. The `allowDiskUse` option lets MongoDB write intermediate results to the disk (which is exactly what SQL databases are doing).

While technically true, this isn't an apples-to-apples comparison. MongoDB's memory limit, as best I can tell -- and please correct me if I'm wrong -- is based on the contents of all documents and operations in the pipeline. Documents in MongoDB tend to be larger, so you can run into that limit faster than one might anticipate.

In Postgres, you have the equivalent of "work_mem". It defaults to 4MB, but most production installation will bump this up. Regardless, this limit is per operation (a join, a sort, etc), not per query. And often times the operation is against a specific fields, as opposed to the entirety of the record contents.

> I really don’t see a difference between what you can do with MongoDB and SQL. I can’t say much more without knowing specifically what impediments you have in mind, but I would certainly like to hear more. For example, why do you cite results caching and lack of real-time requirements?

This might be my own hangups or just us fighting our own specific problems, but I've never been happy with the latency I see come out of the aggregate pipelines we've created. I also don't like what they do to the server's memory.

Re: MongoDB gets support for multi-document ACID transactions

#207

Post by takeda »

golergka wrote: post #103
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 don't know much about MongoDB. I am mostly a client-side developer after all. But every time I see a team transitioning from Mongo to something else, they transition to a relational database. May be their problem is not with MongoDB, but that their data is relational after all? Personally, I'd take a relational db over NoSQL for most of my needs, but all these stories don't really say anything about how Mongo compa…

That's because nearly all data is relational. At first it seems like you don't need a relational database, in fact NoSQL seems easier to use at first.

As your data grows though you realize that your application become more and more complex. A single query might translate to multiple queries to the database, you need to handle scenarios where fields might not exist etc.

With relational data you might have more work at front, but then the database solves many of the problems for you.

As another person said, when you're using databases like MongoDB you're going back in time and reliving the history, because databases in the past looked a lot like that before Codd invented the relational model, for example [1].

Also the whole NoSQL thing seems to be cyclical, we had XML databases in early 2000s[2].

[1] https://en.wikipedia.org/wiki/Hierarchical_database_model

[2] https://en.wikipedia.org/wiki/XML_database

Re: MongoDB gets support for multi-document ACID transactions

#208

Post by ceohockey60 »

SamReidHughes wrote: post #130
nailer wrote: post #67

Earlier quoted context omitted.

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

It's probably better to go with Cockroach or TiDB. RethinkDB has problems of its own.

TiDB seems to have a pretty active community, judging by its repo (https://github.com/pingcap/tidb). Also, saw this thread on TiDB v MySQL recently that's pretty detailed (https://www.quora.com/How-does-TiDB-compare-with-MySQL). Looks like a good option worth trying out.

Re: MongoDB gets support for multi-document ACID transactions

#209

Post by jchb »

donttrack wrote: post #166
eksemplar wrote: post #142

Earlier quoted context omitted.

I work in a Danish muniplicity. Traditionally we've build everything on SQL because it's the world we function in, but we adopted the MEAN stack as a proof of concept a few years back and Mongo has been growing ever since. It does require building and maintaining schemas in a different manner, but when you do that, it's pretty great to work with, especially when we're doing design driven development that consists of…

I work on a mongodb installation in a danish municipality. From the technical side mongodb has been great to work with.

I am curious why a municipality needs custom software. I mean, the scandinavian countries had standardised paper forms for most municipal tasks (population register, ledgers etc) already in the 17-18th century, and those were used nationwide, or at least throughout a single province. Why can't the same be done with software?

Re: MongoDB gets support for multi-document ACID transactions

#210

Post by takeda »

metheus wrote: post #195
btilly wrote: post #184

Earlier quoted context omitted.

If you never tracked what happened in production, it may have worked most of the time well enough that you never saw how bad it was. But read https://aphyr.com/posts/284-call-me-maybe-mongodb and https://aphyr.com/posts/284-call-me-maybe-mongodb for an idea of how the promises in MongoDB documentation compared to the reality of the software under stress. And it wasn't just hypothetical either - there are plenty of ho…

The EnterpriseDB benchmark is just a hit piece. See https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postg...

> It is benchmarking PostgreSQL psql against MongoDB Javescript shell (SpiderMoney/v8). That’s not a very fair benchmark is it?

Isn't javascript engine used whenever you interact with MongoDB?

Post reply on HN