Having a MongoDB database named maindatabase which has 3 document collections named users, tags and categories, I would like to know if it is possible having them splitted on three different servers separately (on different cloud service providers).
I mean not as a replica, but just one collection for server (one db with just categories collection on a server, one with users on another server and one for tags on the third server) may be routed by a mongos Router selectively.
Anyone know if it is possible?
Aside from #matulef's answer regarding manual manipulation of databases through movePrimary, maybe this calls for a simpler solution of just maintaining 3 database connections: one per server, each in a different cloud provider's data center as you originally specified. You wouldn't have the simplicity of a single mongos connection point, but with your three connections, you could then directly manipulate users, tags, and categories on each of their respective connections.
Unfortunately you can't currently split up the collections in a single database this way. However it is possible to do this if you put each collection in a different database. In a sharded system, each database has a "primary shard" associated with it, where all the unsharded collections on that database live. If you separate your 3 collections into 3 different databases, you can individually move them to different shards using the "movePrimary" command:
http://www.mongodb.org/display/DOCS/movePrimary+Command
There is, however, some overhead associated with making more databases, so it's not clear whether this is the best solution for your needs.
Related
I am pretty new to MongoDB. I am creating an application where I will have users and a lot of other data.I have already created a database where I am storing user information using MongoDB. Now I have to create a new database or collection to store rest of the data. What are the pros and cons of creating different or different collection ?
I use MongoDB in a very similar way and have already thought a lot about dividing my database. Here are some of the things we considered:
Using 2 databases is harder to maintain, your application will have to know which database to update, also it can increase the costs (even more if you intend to monitor the databases and host on different infrastructure).
Mongo 2 used to lock the entire database when updating, so I think it would be better to separate then, but Mongo 3 with WiredTiger locks only the document, so you won't have the problems we used to have in the past.
One good thing about splitting the database in two is that even if your data explodes one database, the other will still work
IMHO, if you use a decent machine to store your databases and monitor it the right way, you won't have any troubles keeping just one until your system is giant with millions of active users. You can also use Replica Sets and Sharding to increase efficiency.
I am running several NodeJS instances on separate compute engines all accessing the same MongoDB. In each instance I am running a background housekeeping process which scans the entire customer collection in the database. I am using cursors to access documents, fetching the next customer one by one.
This yields a number of competing housekeeping processes, all wanting to access the same documents (customers) in the same order.
What I am looking for instead, is for my housekeeping processes to cooperate rather than compete.
So if I had two instances I could construct two opposite direction cursors. But if I have 3 or more instances or if I want to be tolerant to any number of instances going up and down without duplicating or phantoming customers, I need to find a different approach.
I was thinking, does MongoDB provide cursors addressable by name from multiple NodeJS instances such that all instances fetch the next document from the same cursor, never obtaining the same document?
If not, can anyone suggest a good pattern to apply to this problem?
I know this question has been asked a number of times here. However, I am unable to find a satisfying answer and reach on a conclusion.
This question is specifically for Mongo DB version 3.2. Should I have separate DBs and collection for different apps, or just one DB with all collections within it?
To simplify it further, let’s say I have about 15-20k apps on a server. Is it advisable to create a different database for each of these apps (with 10 collections/app), or create just one database and store all collections (20k apps * 10 collections = 200k collections) in it?
Also, this would be called from single Node app so need to consider the performance on having multi DB connections.
Should I have separate DBs and collection for different apps, or just one DB with all collections within it.
As I understand there is not any concrete answer or any concrete algorithm for this question It depends on no of connections with the database actually.
No of connections depends on the upcoming concurrent requests count so first see logically that Is it really worth to create a different database for each of these apps
Or another way (with 10 collections/app)
second way is you can judge the response time with some load testing (If possible)
I am building a Multitenant MongoDb system. How to switch between Db's depending upon request. I am using MongoDb with Node js using MongoDb native Driver.
Your MongoClient object has a method .db(dbname) which returns a reference to a different database object using the same connection.
But you might want to consider to just store the data of all tennants in the same collections of a single database and add a field tennant to every document which you then include in every query. When you have individual collections or even an individual databases per tenant, the maintenance effort for your database administrator increases linearly with the number of tenants you have, because many maintenance and configuration tasks (like configuring sharding, for example) need to be performed on every collection of every database separately.
I'm creating a platform where customers (users) are from different organisations. So I would like to keep their data totally separated according to organisations they belong. How would you suggest to store such data in mongo db? On which level?
Are you keeping the data separate for security reasons (i.e. compliance or regulation) or simply for administration/ease-of-use?
If it's the former, I'd go with separate databases at the very least, if not separate MongoDB instances. Separate instances enables you to perform segregation at an IP level through something like iptables so that you can tie down different instances to different IP ranges, representing the different organisations presuming they will be accessing the data.
If it's the latter, I'd still go with separate databases because it gives you the ability to have different users on a database level and from version 2.2, concurrency will be on a database level (so there's no sharing of the write lock, for example, that you'd have if you split it out on collection level).
As a FYI, here's some additional information on schema design in MongoDB -
Schema Design
Schema Design Presentation by Kyle Banker
Schema Design Blogs from Customers
MongoSF2012: mongodb-schema-design-insights-and-tradeoffs
There was actually a schema introduction webinar held last week that you can now listen to.
You can create a document for each organization and put the user's details into sub-documents inside the root document.
If the overall users' profiles are so big that don't fit into MongoDB document size (16 mg), then you can use different approach by creating a document for every user and add a field referring to the organization.