Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use MongoDB

pastebin.com

Post reply on HN
Print view View original

221–230 of 331 posts

Re: Don't use MongoDB

#221

Post by lubujackson »

ehwizard wrote: post #138

From CTO of 10gen First, I tried to find any client of ours with a track record like this and have been unsuccessful. I personally have looked at every single customer case that’s every come in (there are about 1600 of them) and cannot match this story to any of them. I am confused as to the origin here, so answers cannot be complete in some cases. Some comments below, but the most important thing I wanted to say is…

Great response. I'll take this over an anonymous, half-informed screed any day.

Re: Don't use MongoDB

#222

Post by samstokes »

harryh wrote: post #141

Hi, I run engineering for foursquare. About a year and a half ago my colleagues and I and made the decision to migrate to MongoDB for our primary data store. Currently we have dozens of MongoDB instances across several different data clusters storing over a TB of data and handling 10s of thousands of requests per second (mostly reads but the write load is reasonably high as well). Have we run into problems with Mongo…

Would you be able to sum up the things you consider Mongo to be extremely good at? Particularly in comparison to things like Riak (which I believe supports a similar data model), or indeed compared to an RDBMS.

All databases perform poorly if you try to use them for use cases they don't fit, but I find with NoSQL databases it can be hard to find concise, objective statements of which use cases each is ideal for.

Re: Don't use MongoDB

#223

Post by yaix »

Some guy posted some unproven random claims on pastebin, and people take it that serious? "It must be true, I've seen it on the Internet!" 500+ upvotes? c'mon.

Re: Don't use MongoDB

#224

Post by kanwisher »

j_baker wrote: post #161
moe wrote: post #129

Earlier quoted context omitted.

I don't think that counts as an argument. When you strip MongoDB down to the parts that actually have a chance of working under load then you end up pretty close to a slow and unreliable version of redis. Namely, Mongo demonstrably slows to a crawl when your working-set exceeds your available RAM. Thus both redis and mongo are to be considered in-memory databases whereas one of them is honest about it and the other n…

If I recall correctly, mongo only requires that the index gets stored in memory. The actual data itself can go on disk.

If you actually use Mongo in practice, everything needs to be in ram to have any kind of performance

Re: Don't use MongoDB

#225

Post by einhverfr »

Vivtek wrote: post #117
jacques_chester wrote: post #71

Earlier quoted context omitted.

These are not new approaches to data modelling. Document databases, network databases and hierarchical databases (IMS, CODASYL etc) predate relational databases by decades. Relational is the universal default for a simple reason. When first introduced it proved to be far better, in every conceivable way, than the technologies it replaced. It's as simple as that. Relational is a slam-dunk, no-brainer for 99.99% of use…

I agree entirely - I think when people rebel against "relational databases" they're actually just realizing that the normalization fetish can be harmful in many application cases. You're better off with MySQL or PostgreSQL managing a key-value table where the value is a blob of JSON (or XML, which I've done in the past), then defining a custom index, which is pretty damn easy in PostgreSQL. Then you have hundreds of…

Normalization is a tricky thing. On one hand, highly normalized databases have better flexibility in reporting, IMHO. On the other, you lose some expressiveness regarding data constraints. High degrees of normalization would be ideal if cross-relation constraints were possible. As they are not, typically one has to normalize in part based on constraint dependencies just as much as data dependencies.

Re: Don't use MongoDB

#226

Post by einhverfr »

tptacek wrote: post #215
einhverfr wrote: post #208

Earlier quoted context omitted.

Ok, let me rephrase. MySQL has a niche too. It's somewhere between that of a NoSQL database and that of a real RDBMS. MySQL does well for single app databases (as NoSQL does), but where the relational data then needs to be fed through other database systems for multi-app access.

It seems to do well for all of Facebook too, doesn't it? I know Facebook seems banal because we interact with it in some way several times a week, but is your head wrapped around how huge that thing is?

It's not about the size of the database or deployment. It's about the number of applications interacting across the same relational interface. The fact that applications can turn off strict mode is a big blow in this area. You can't be sure your data is "obviously correct" to paraphrase a different HN post.

One of my customers logs certain web data into a MySQL database and loads/processes it in a PostgreSQL database every day. The data is then accessed in Pg by at least three different applications.

That's reasonable, btw.

Re: Don't use MongoDB

#227

Post by einhverfr »

va_coder wrote: post #102
CarlHoerberg wrote: post #46

Earlier quoted context omitted.

Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..

Schemaless is awesome. Are you dba or a developer? If you're a developer like me schemaless is awesome because of it's flexibility. I focus less time on the how to do stuff and more time on the what stuff should we do. I've been using Hibernate for 9 years and I finally came to the conclusion that it's just not worth the pain. When working on RDBMS I'm using straight SQL from now on.

Schemaless also dispenses with the ability to declare what correct data is in the schema. For critical apps that's a high caliber footgun. For critical apps that have to integrate with eachother, it's a nice piece of artillery aimed squarely at your foot.

Re: Don't use MongoDB

#228

Post by jacques_chester »

einhverfr wrote: post #207
jacques_chester wrote: post #140

Earlier quoted context omitted.

> However, it breaks down in semi-structured content, content where---parentheses for grouping---(hierarchical structure is important, data is seldom written and frequently read, and where read performance navigating the hierarchy is most important) and so forth. Again, this problem is not new. Database greybeards call this OLAP and it's been around since the 80s. There is nothing new under the sun in this trade.

No. I am talking about something like LDAP, not OLAP. LDAP may suck badly in many many ways but it is almost exactly not like OLAP. OLAP is typically used to refer to environments which provide complex reports quickly across huge datasets, so a lot of materialized views, summary tables, and the like may be used (as well as CUBEs and the like). Hierarchical directories are different. In a relational model you have to…

I was referring to the read/write preponderance. Normalisation optimises write performance, storage space and also provides strong confidence of integrity. But it means lots of joins, which can slow things down on the read side.

That's why OLAP came along. Structured denormalisation, usually into star schemata, that provide fast ad-hoc querying. I think part of the enthusiasm for NoSQL arises because most university courses and introductory database books will go into normalisation in great detail, but OLAP might only get name checked. So folk can get an incomplete impression of what relational systems can do.

If I had a purely K/V data problem -- a cache, for example -- I would turn to a pure K/V toolset. Memcache, for example.

Hierarchical datasets have long been the blindside for relational systems. Representable, but usually requiring fiddly schemes. But in the last decade SQL has gotten recursive queries, so it's not as big a problem as it used to be.

Re: Don't use MongoDB

#229

Post by jacques_chester »

SemanticFog wrote: post #84
jacques_chester wrote: post #71

Earlier quoted context omitted.

These are not new approaches to data modelling. Document databases, network databases and hierarchical databases (IMS, CODASYL etc) predate relational databases by decades. Relational is the universal default for a simple reason. When first introduced it proved to be far better, in every conceivable way, than the technologies it replaced. It's as simple as that. Relational is a slam-dunk, no-brainer for 99.99% of use…

You're absolutely right -- RDBMSes were designed to solve problems with the nosql-type approaches that preceded them. The nosql bandwagon is blindly rolling into the past, where it will crash into the old problems of concurrency and consistency under load. BTW if you want nosql-style schema flexibility within an RDBMS, then a simple solution is to store XML or JSON in in a character blob. Keep the fields you need to…

> BTW if you want nosql-style schema flexibility within an RDBMS, then a simple solution is to store XML or JSON in in a character blob.

In all sincerity, I would strongly recommend against this. If your problem absolutely defies normalisation, don't use a relational database.

Re: Don't use MongoDB

#230

Post by einhverfr »

jacques_chester wrote: post #228
einhverfr wrote: post #207

Earlier quoted context omitted.

No. I am talking about something like LDAP, not OLAP. LDAP may suck badly in many many ways but it is almost exactly not like OLAP. OLAP is typically used to refer to environments which provide complex reports quickly across huge datasets, so a lot of materialized views, summary tables, and the like may be used (as well as CUBEs and the like). Hierarchical directories are different. In a relational model you have to…

I was referring to the read/write preponderance. Normalisation optimises write performance, storage space and also provides strong confidence of integrity. But it means lots of joins, which can slow things down on the read side. That's why OLAP came along. Structured denormalisation, usually into star schemata, that provide fast ad-hoc querying. I think part of the enthusiasm for NoSQL arises because most university…

Normalization is formally defined based on data value dependencies. However, because there is no way to set constraints across joins, in practice, the dependencies of data constraints are as important as the dependencies of data values.

As far as recursive queries, I am not 100% sure this is ideal either from a read performance perspective. There are times when recursive queries are helpful from a performance perspective, but I don't see a good way to index, for example, path to a node. Certainly most databases don't do this well enough to be ideal for hierarchical directories. For example indexing the path to a node might be problematic, and I am not even sure you could do this reliably in PostgreSQL because the function involved is not immutable.

Post reply on HN