[SERVER-4188] Limit on number of Databases? Design approach to partition by database a good idea? Created: 02/Nov/11  Updated: 29/Feb/12  Resolved: 02/Nov/11

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Question Priority: Blocker - P1
Reporter: Ray Smith Assignee: Scott Hernandez (Inactive)
Resolution: Done Votes: 0
Labels: databasedesign
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu (latest)


Participants:

 Description   

Hi,

I have an application that is virtually partitioned on a relational database (MySQL) and we are moving to Mongo. We have 20,000 accounts (with an accountid) partition field. I have a question surrounding our design approach with moving to Mongo.

We currently hoped to give each account it's own database and then have a central account manager db to control routing. This appears to be working really well and performance is awesome.

We could not find any limit anywhere on DB numbers per installation. There was a reference to the file access limits (which we increased to 65536 on our ubuntu installation)

Should we collapse all accounts into a single DB, using an account key field, apply combined indexes etc and then rely on auto-sharding? Or is it ok to continue to create new databases per account to reduce the index overheads for large accounts?

Your help is much appreciated



 Comments   
Comment by Scott Hernandez (Inactive) [ 02/Nov/11 ]

Sharding is really best done at the collection level, not by creating many databases. You are probably better off using a single collection with the account fields as the shard-key if you want to use Sharding in MongoDB. There is nothing wrong with what you have done except you have to maintain it and create your own partitioning.

It is better to ask these types of questions here (http://groups.google.com/group/mongodb-user). In fact, you will find people have already asked and answered these types of questions.

Generated at Thu Feb 08 03:05:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.