Some thoughts....
Typically one does not want to store pieces of tightly interrelated information in different systems. The chances of things getting out of sync is significant and now instead of one problem on your hands you have two. One thing you can do with Mongo though is use it to pipeline your data in or data out. My preference is to keep everything in PostgreSQL to the extent this is possible. However, I would note that doing so really requires expert knowledge of PostgreSQL programming and is not for shops unwilling to dedicate to using advanced features. I see a somewhat different set of options than you do. Since my preference is not something I see listed I will give it to you.
You can probably separate your metadata into common data, data required for classes, and document data. In this regard you would have a general catalog table with the basic common information plus one table per class. In this table you would have an hstore, json, or xml field which would store the rest of the data along with columns where you are storing data that must be constrained significantly. This would reduce what you need to put in these tables per class, but would allow you to leverage constraints however you like. The three options have different issues and are worth considering separately:
hstore is relatively limited but also used by a lot of people. It isn't extremely new but it only is a key/value store, and is incapable of nested data structures, unlike json and xml.
json is quite new and doesn't really do a lot right now. This doesn't mean you can't do a lot with it, but you aren't going to do a lot out of the box. If you do you can expect to do a significant amount of programming, probably in plv8js or, if you want to stick with older environments, plperlu or plpython. json is better supported in 9.3 though at least in current development snapshots, so when that version is released things will get better.
xml is the best supported of the three, with the most features, and the longest support history. Then again, it is XML.....
However if you do decide to go with Mongo and PostgreSQL together, note that PostgreSQL supports 2 phase commit meaning you can run the write operations, then issue PREPARE TRANSACTION and if this succeeds do your atomic writes in Mongo. If that succeeds you can then COMMIT in PostgreSQL.
You have 5 servers serv1,serv2,serv3,serv4,serv5 and you want to set up 5 instanses inst1,inst2,inst3,inst4,inst5. Each instance should have at least 2 data nodes (PRIMARY and SECONDARY) and 1 ARBITER
serv1: inst1_PRI, inst5_SEC, inst4_ARB
serv2: inst2_PRI, inst1_SEC, inst5_ARB
serv3: inst3_PRI, inst2_SEC, inst1_ARB
serv4: inst4_PRI, inst3_SEC, inst2_ARB
serv5: inst5_PRI, inst4_SEC, inst3_ARB
This architecture provide fault tolerance of 1. If one server goes down all instances are continue to work. If you loose 2 servers one instance should be affected ...
Best Answer
Max connection count is usually %80 of ulimit value which is 1024 in most linux distros by default. That gives you 819 connections. It can be changed by changing ulimit value.
In MongoDB, each host can use 10 connections which is set by MongoOptions.connectionsPerHost property. These connections are controlled by an internal connection pool. It is thread-safe and you can have up to ConnectionPerHost x threadsAllowedToBlockForConnectionMultiplier threads running simultaneously. threadsAllowedToBlockForConnectionMultiplier also can be changed, its default value is 5. That is by default, you can have 50 simultaneous threads running from one host. Threads more than that value will get the "Out of semaphores to get db connection" exception.
You can change MongoOptions.connectionsPerHost and threadsAllowedToBlockForConnectionMultiplier values appropriately according to your needs.
If you are using drivers on a web application, you should use it as singleton class. No need to 'open connection-> do some work -> close connection' loop. Just declare a global connection once (and initialize in init method of your servlet) and use it in your entire web application.