3 ms·
Very interesting that they have 17,810 collections (aka tables). I wonder if it is common w/ MongoDB to design a data model in this way? Anybody have more inf
by mikebo 17y ago
Very interesting that they have 17,810 collections (aka tables). I wonder if it is common w/ MongoDB to design a data model in this way? Anybody have more info on this tradeoff vs. a smaller but larger size collections?
- dmytton 17y agoI've commented on this here: http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/#comment-818 http://blog.boxedice.com/2010/02/28/notes-from-a-production-... Essentially this decision was due to the disk space requirements because of the way MongoDB allocates files for each DB. There are no performance tradeoffs for using lots of collections. See http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+...
- mikebo 17y agoI'm actually not advocating for a database per customer. I was more wondering why you have so many collections -- surely they're not all representing different logical data. My guess is that you create some number of collections per customer? With the new built-in sharding support, couldn't you have a 'customer_id' field and collapse many of those collections into larger collections, then shard by 'customer_id'? I'm just trying to understand tradeoff between these two types of schemas.