A Year with MongoDB

Re:A Year with MongoDB by aschobel on Friday April 13, 2012 @04:00PM (#3838601)

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

[ Parent | on HN ]

Re:A Year with MongoDB by bretthoerner on Friday April 13, 2012 @04:03PM (#3838614)

> 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.

[ Parent | on HN ]

Re:A Year with MongoDB by siavosh on Friday April 13, 2012 @04:11PM (#3838640)

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

[ Parent | on HN ]

Re:A Year with MongoDB by madworld on Friday April 13, 2012 @05:42PM (#3838986)

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)

[ Parent | on HN ]

Re:A Year with MongoDB by aschobel on Saturday April 14, 2012 @03:57PM (#3841837)

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.

[ Parent | on HN ]

Re:A Year with MongoDB by strlen on Friday April 13, 2012 @05:58PM (#3839035)

> 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).

[ Parent | on HN ]

Re:A Year with MongoDB by aschobel on Saturday April 14, 2012 @03:52PM (#3841823)

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.

[ Parent | on HN ]

Re:A Year with MongoDB by guywithabike on Friday April 13, 2012 @05:43PM (#3838988)

450 ops/sec is nothing.

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

[ Parent | on HN ]

Re:A Year with MongoDB by lalmalang on Friday April 13, 2012 @05:53PM (#3839022)

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.

[ Parent | on HN ]

Re:A Year with MongoDB by gatesvp1 on Monday April 16, 2012 @01:20PM (#3848299)

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.

[ Parent | on HN ]