4 ms·

MongoDB at Etsy, Part 2

• brown9-2 16y ago
  One of the things that Dan touched on was that MongoDB behaves well when the working set of data exceeds available physical RAM.... Which is to say, query performance is excellent when the database is small enough to keep entirely in RAM, but when the data blows past RAM, the performance then plateaus, limited only by your disk I/O subsystem. This is preferable and familiar; there’s no massive drop (or crash) in performance, there’s only a nice plateau of response at the bound-by-disk condition. Just curious, but anyone aware of which of the other document-based datastores (CouchDB, Tokyo etc) don't behave as sanely when the dataset size is greater than RAM size (and/or why this is)? Their "part one" article mentions that this type of behavior was a requirement for them, and that it eliminated some of these other datastores.
  • bbatsell 16y ago
    In their part 1 [1], they link to a summary of a presentation [2], which says that with Tokyo, "when the dataset was larger than memory performance decreased vastly." No actual benchmarks, though. [1]: http://codeascraft.etsy.com/2010/05/19/mongodb-at-etsy/ http://codeascraft.etsy.com/2010/05/19/mongodb-at-etsy/ [2]: http://journal.uggedal.com/tags/voldemort http://journal.uggedal.com/tags/voldemort
  • jchrisa 16y ago
    One of the reasons BBC chose CouchDB for their next-gen data store is the predictable performance under load. Here is a series of blog posts from one of their engineers, on their use of CouchDB: http://enda.squarespace.com/tech/tag/bbc-forge http://enda.squarespace.com/tech/tag/bbc-forge There are also a bunch of CouchDB case studies here: http://www.couch.io/case-studies http://www.couch.io/case-studies
• deleted 16y ago
  [deleted]