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