Mongodb a cluster of machines doing jobs -

i have setup 72 machines take jobs rabbitmq queues , perform crud operations on sharded mongodb on 4 machines , arbeiter, want know if makes difference/sense let 1 machine handle crud operations, running on same network.

on side note reason thinking because makes tracking progress easier.

four instances light sharded solution, perhaps talking replication?

in mongodb concept of replication used high availability, not performance. minimum recommended configuration 3 nodes, 1 primary, 1 secondary , arbiter. purpose of arbiter being handle elections on node primary, breaking deadlock on 2 nodes handing majority of votes one. more stable replica sets have @ least 3 nodes of primary, secondary, secondary..., , possibly arbiter, arbiter again used have odd number of votes giving majority 1 node in election.

in sharded configuration, collection split determined shard key across shards in cluster. main purpose of sharding when data has working set larger available ram on single node. allows queries distributed across cluster or targeted shard contains required data, in case distributing load or not tying resources of given node.

sharding requires additional nodes known config servers. these nodes hold meta data regarding location of data on shards, , interrogated router direct requests each shard. in production have 3 config servers protect against 1 going down.

in case, sharded clusters typically comprised of replica set within each shard. replica set, primary node accepts connections read/write operations. can set connections allow reads secondary nodes if can live data possibly being inconsistent, 1 node every accept writes, replicating other secondary nodes. shards, writes sent primary of shard or shards depending on shard key chosen.

so number of servers involved in crud operations depends entirely on configuration.