Hacker News Reader

Comment by aschobel | Hacker News Reader

We love MongoDB at Catch, it's been our primary backing store for all user data for over 20 months now.

  > Catch.com
  > Data Size: 50GB
  > Total Documents 27,000,000
  > Operations per second: 450 (Create, reads, updates, etc.)
  > Lock % average 0%
  > CPU load average 0%

Global Lock isn't ideal, but Mongo is so fast it hasn't been an issue for us. You need to keep on slow queries and design your schema and indexes correctly.

We don't want page faults on indexes, we design them to keep them in memory.

I don't get the safety issue, 20 months and we haven't lost any user data. shrug

View on HN

> I don't get the safety issue, 20 months and we haven't lost any user data. shrug

Nobody loses any user data until they do.

This should be a deal breaker for any serious app. Does the performance hit of safe mode negate all other advantages of MongoDB?

That's most people's findings. If your dataset can fit in ram [1] and you don't care about your data being safe then there might be an argument for MongoDB. Once you care about your data, things like Voldemort, Riak, and Cassandra will eat Mongo's lunch on speed.

[1] But as Artur Bergman so eloquently points out, if your data can fit in ram, just use a native data-structure (http://youtu.be/oebqlzblfyo?t=13m35s)

Do you have a citation to back up the claim that you shouldn't use MongoDB for serious apps?

We have done billions of ops with Mongo and have never lost any data.

> Data Size: 50GB

I am sorry, to sound blunt, but that's an irrelevant data point. With a data set that fits comfortably into RAM (much less SSDs in RAID!), most any data store will work (including MySQL or Postgres).

> Operations per second: 450

Again, not a relevant data point. With a 10 ms seek time on a SATA disk, this is (again) well within the IOPS capacity of a single commodity machine (with RAID, a SAS drive, row cache, and operating system's elevator scheduling).

Agreed, this is a trivial amount of data.

Context is the article which made is seem like even 220GB is an ok amount, still can fit in memory.

450 ops/sec is nothing.

What's your breakdown between the operation types, and what kind of hardware are you on?

You'd think -- but the 10gen guys weren't surprised when we were struggling at this level (periodically), on a RS with two AWS large instances and relatively large objects. Absolute ops/sec in and of itself is relatively meaningless tbh.

Not a personal attack as Catch is a neat product, but these numbers are basically irrelevant.

This type of load can easily be handled by a simple SQL box. We did these types of #s with a single SQL Server box 4 years ago, except that your "total documents" was our daily write load.

Reply on news.ycombinator.com