We have an app that is basically an ERP. Some of the resources in the ERP are satellite tracked. So the information related to the resource itself is minimal, but the satellite tracker produces data every 3 minutes. Our instinct was to store the satellite information in it's own db or even it's own cluster and store the ERP information in it's own cluster.

What do you think?

  • 1
    can you explain why you are thinking you want to store it in a separate db? – Asya Kamsky Jun 21 '12 at 12:15
  • I think you're right, I can't really think of a performance reason to do this. – Lee Jun 22 '12 at 12:00

Well, 2.2 will add database level concurrency (this is available for testing in the 2.1 development branch as I write this answer), so if you are concerned about lock contention between the two, then separate databases would be a good idea.

You don't really mention what your criteria are here to make the decision, so the new 2.2 feature is the only relevant one I can think of - feel free to comment or expand and I'd be happy to answer further.

  • Thats for the reply. It seems that I need to dive a little deeper into MongoDB first. Seeing as Collections are queried independently, there might not be any reason to separate the data into different DBs. Sharding will take care of scaling. And if we find in the future that we want to split it out, it looks like it wouldn't be that hard to move the entire collection into it's own DB. This is a migration project so just starting to plan ahead. Thanks again. – Lee Jun 22 '12 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.