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

211–220 of 331 posts

Re: Don't use MongoDB

#211

Post by ehwizard »

newman314 wrote: post #195
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…

Given the response, what are some best practices/gotchas for MongoDB then? It might be helpful for 10gen to put together a short doc on what to watch out for evaluators.

In addition to the documentation, videos from the conferences are a great place to start:

http://www.10gen.com/presentations/mongoboston-2011/schema-d... http://www.10gen.com/presentations/mongosf-2011/practical-sc...

Re: Don't use MongoDB

#212

Post by einhverfr »

marshray wrote: post #153
zzzeek wrote: post #135

Earlier quoted context omitted.

Interesting to note is that early versions of Postgres, we're talking the pre-6 versions around 1995 here, were awful . Not like I was a very sophisticated user at that time myself but it definitely ate my data back then - we switched to MSQL at that time which at least didn't do that.

Wasn't it still basically a university project for researching MVCC at that point? I love universities of course but we must admit they produce interestingly-architected abandonware sometimes. My sense was that it got a pretty thorough review and revision/rewrite in the transition from Postgres to PostgreSQL.

PostgreSQL has evolved a LOT in the last decade even. I thought the university project was looking at OO paradigms in relational databases (inheritance between relations and the like).

The change from Postgres to PostgreSQL was largely a UI/API change and the move from QUEL to SQL. However, over time virtually all of the software has been reviewed and rewritten. It's an excellent project, and I have been using it since 6.5.......

Re: Don't use MongoDB

#214

Post by maxmcd »

jm3 wrote: post #202
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?)

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.

Drawing a line between the difference in losing money for a paying service and a free service, while technically correct, is not the best business practice. Any online business looses money by being down, whether they can easily quantify it or not.

Re: Don't use MongoDB

#215

Post by tptacek »

einhverfr wrote: post #208
tptacek wrote: post #193

Earlier quoted context omitted.

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.

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?

Re: Don't use MongoDB

#216

Post by kanwisher »

bbulkow wrote: post #157

Disclosure: I wrote a product called Citrusleaf, which also plays in the NoSQL space. My focus in starting Citruseaf wasn't features, it was operational dependability. I had worked at companies who had to take their system offline when they had the greatest exposure - like getting massive load from the Yahoo front page (back in the day). Citrusleaf focuses on monitoring, integration with monitoring software, operatio…

We use Citrusleaf at my job, definitely one of the fastest nosql stores I've seen. However it doesn't nearly have the kind of flexiblity that mongodb has, we tend to use it more as a persistent cache like redis then a real database, its not quite as easily to write queries in it.

Re: Don't use MongoDB

#217

Post by kanwisher »

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.

Half the startups in NYC use mongo, but that might be cause they are connected to Union Sq Ventures

Re: Don't use MongoDB

#219

Post by itaborai83 »

I feel like a dick, but I have got to ask. Is it Disney? Disney is on both the couchbase and 10gen sites. Both sites mention that they are using their NoSQL solutions to power their social and online games. Couchbase powers Zynga and can arguably be considered the leader on this specific market. Am I close?

Re: Don't use MongoDB

#220

Post by linuxhansl »

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…

Dislaimer: One of the HBase committers here.

There is/was a LOT of hype in NoSQL. Hype and very little understanding what NoSQL is about and specifically why/when choosing a NoSQL database makes sense and when it does not.

It is not about SQL vs. not. It is about consistency, availability, and partition tolerance, and which of these you are willing to give up. Surprisingly few people know about the CAP theorem and what it implies.

Generally there two main reasons why you switch to NoSQL (Not Only SQL) databases. 1. You need to scale out (add more storage and query capacity by adding more machines). 2. You do not want to be locked into a relational schema.

There is no magic in NoSQL! To scale out these stores give up exactly those features that would impede scaling out (for example global transactions).

What one has to realize that you give up a lot by letting go of relational databases: Fast ad hoc queries, transactions, consistency, and the entire theory and research behind it. I don't see why relational databases are "unsexy". A good query planner is almost a work of art and it is amazing what they can do. In fact we use them alongside HBase.

Instead of ad hoc queries you either get slow map/reduce type "queries" or you need to plan your queries ahead of time and denormalize the data accordingly at insert time.

You better have very good reasons for the switch.

When we evaluated NoSQL stores a while back (for #1 type problems) I was quite the skeptic. We looked at Riak, Redis, MongoDB, CouchDB, Cassandra, and HBase). Eventually we settled on HBase because needed consistency over availability and we needed more than just a key value store, and we already some Hadoop projects... and I started to drink the cool-aid :)

Personally, I am not a big fan of eventually consistent (but highly available) stores, because it is extremely difficult to reason about the state of the store; and the application layers bears a lot of extra complexity. But your mileage may vary.

HBase of course is new as well, and I needed to start fixing bugs and adding new features that we needed.

As with "Java is better than C++" type discussions, here too, what store to use depends on the use case. As parent points out any hype about anything is a bad thing, because it typically replaces reasons as an instrument of decision making.

(not sure what I was getting at, so I'll just stop here).

Post reply on HN