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

201–210 of 331 posts

Re: Don't use MongoDB

#201

Post by mnutt »

skrebbel wrote: post #146
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…

> If you want to come talk to the MongoDB team, both our offices hold open office hours[2] where you can come and talk to the actual development teams. We try to be incredibly open, so please come and get to know us. I envy how all your (potential) customers are from California.

I've been to their open office hours in NYC and, though we don't have a support contract, they were incredibly welcoming and helpful.

Re: Don't use MongoDB

#202

Post by jm3 »

willvarfar wrote: post #189
harryh wrote: post #162

Earlier quoted context omitted.

> have users of foursquare run into problems? Of course we've run into problems from time to time. No one goes from nothing to foursquare's level of success without running into some bumps along the way. > were they serious? did someone lose money? No. > it would answer whether to use an eventually consistent db MongoDB actually isn't really an eventually consistent datastore. It doesn't (for example) allow writes to…

http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ You had 11 hours downtime and didn't lose money? What about opportunity cost? Reputation? Now you have to share your secret :) (I guess, if you weren't profitable, you had nothing to lose?)

If you don't have paying customers (Foursquare), you're not going to lose much in hard dollars when your service falls over. Reputation points? Sure. Dollars, not so much.

Re: Don't use MongoDB

#203

Post by 9oliYQjP »

harryh wrote: post #194
willvarfar wrote: post #189

Earlier quoted context omitted.

http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/ You had 11 hours downtime and didn't lose money? What about opportunity cost? Reputation? Now you have to share your secret :) (I guess, if you weren't profitable, you had nothing to lose?)

The 11 hours of downtime was a pretty big deal, but it had very little to do with MongoDB. It was basically a huge failure in proper monitoring.

Kudos for not blaming the tool when that would have been the easiest route. It's worth mentioning that 10gen has MongoDB Monitoring Service out now. It makes monitoring MongoDB instances a lot more accessible and convenient.

Re: Don't use MongoDB

#204

Post by [deleted] »

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…

[deleted]

Re: Don't use MongoDB

#205

Post by ttcbj »

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…

Thanks for this response. I am currently working at a small company developing a system that will use Mongo. We originally looked at Mongo and thought we had 'better go with something safe.' However, the data we are working with varies unpredictably for different customers, and Mongo really helped. We eventually decided to switch to Mongo, and it has been a great thing for developer productivity.

We are hoping to go live with the first version of the system this spring. It will initially have a small amount of data (less than a hundred MB), will always have a high read to write ratio, and even the read load will be low by most standards for many years (the business provides a large amount of value to a small number of customers, rather than vice versa, thus the low volumes).

Anyway, on seeing this thread trending, I thought "oh, man, are we in for it when we hit production?" Your response - the openness of it - was reassuring. We will certainly be counting on not losing data next spring. We plan to use MongoHQ, and hope their expertise will help us there as well.

The development benefits have been so significant that I deeply hope Mongo is focusing on issues like not losing data. We would hate to have to switch to something less flexible.

Re: Don't use MongoDB

#206

Post by einhverfr »

nullymcnull wrote: post #139

These posts are exceptionally well-timed for me. I'm currently wrangling with one of those problems that is just not solved well with relational databases, or even the flat document store that my company already uses. I've been looking hard at Redis and Mongo, and of late I'm leaning towards Mongo. You know what? Having read these posts and the threads - and having extracted what little in the way of factual datapoin…

I think one of the reasons that NoSQL databases have been oversold is that a lot of projects don't have people on them who are good at engineering databases. The result is that folks use ORM's badly.

If you are going to use the database just to store data structures form your program, you might as well use NoSQL db's. However, in most cases, you get integration and migration wins by:

1) Placing your engineering effort on the database. Looking at the sort of real world data you are collecting, modelling it well in the database and then presenting an API to the application. The API will either be a relational one (i.e. views) or a procedural one (stored procedures). After a couple of iterations, the schema shouldn't be being fundamentally changed too much though there could be some minor tweaking.

2) Now, with a good API you can build an application on the database using a methodology of your choice. This could be done in an agile way.

Now if integration is not a goal, then sure you can do all the data validation in your application and you can use NoSQL databases. But relational databases are also powerful integration tools in their own right. I can't imagine LedgerSMB, for example, doing well on anything else for this reason alone.

Re: Don't use MongoDB

#207

Post by einhverfr »

jacques_chester wrote: post #140
einhverfr wrote: post #91

Earlier quoted context omitted.

First, the more I have looked, the more I have found that non-relational database systems are remarkably common and have been for a long time. The relational model is ideal in many circumstances. 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 hiera…

> 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 transfers the hierarchy to get the single record you want and you are not aggregating like you typically do in an OnLine Analytical Processing environment.

This is why OpenLDAP with a PostgreSQL backend sucks, while OpenLDAP with a non-relational backend (say BDB) does ok.

I am not saying anything new is under the sun, just that some of the old structures haven't gone away.

Re: Don't use MongoDB

#208

Post by einhverfr »

tptacek wrote: post #193
einhverfr wrote: post #98

Earlier quoted context omitted.

"Don't Use MySQL" still should be conventional wisdom. Indeed it's the only database system I have ever used where a system with a single transaction running only multi-row inserts into a table can (and frequently does) deadlock against itself. Don't get me wrong, time was when it was easier to use than PostgreSQL but that time is long since passed. One area I have continued to recommend MySQL has been in areas of co…

Given the size and success of MySQL deployments, it's getting awfully hard to evangelize that particular religion. I prefer Postgres, but life is too short to argue about it.

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.

Re: Don't use MongoDB

#209

Post by einhverfr »

deoxxa wrote: post #87
goldmab wrote: post #78

Earlier quoted context omitted.

Fair enough, but you can also have a schemaless store by using JSON fields in PostgreSQL or MySQL.

That's not an unfair comparison at all - indexing the data in a JSON blob is entirely possible and practical.

What you want to index regarding a large text file and what indexes you can create and use may be different.

Re: Don't use MongoDB

#210

Post by lawnchair_larry »

nomoremongo wrote: post #154

Pastebin author here. Refutations are going to fall into two categories, it seems: 1. Questioning my honesty 2. Questioning my competence Re #1, I'm not sure what you imagine my incentive to lie might be. I honestly just intended this to benefit the community, nothing more. I'm genuinely troubled that it might cause some problems for 10gen, b/c, again, Eliot & co are nice people. Re #2, all I can do is attempt to rea…

I don't understand why anyone is surprised or bothered that this would be an anonymous post.

Has anyone commenting ever used a piece of software that caused them major problems, while watching others with less experience talk about how great it is? For me, it is beyond my capabilities to refrain from speaking up about it.

His identity does not matter, and it would start a war between people or companies. He is not interested in doing that, and he is not speaking on behalf of a company. There is not really any other way to do it.

Sometimes people need to put information out there but don't want to be personally associated with the information. This is fairly logical, because they are not associated with the information. They just discovered what was already true.

Post reply on HN