> > ... > > It can be a great advantage when scaling to be able to partition the > transactions across different parts of the database. If we want this to > be able to scale, I think we *have* to make it work without requiring > transactions across environments. There is no way that we can scale > as far as we'd like to by using a single mongo replica set for all > environments. >
You generally shard across replica sets, and if you shard by environ uuid (say by putting it as a prefix on all the _ids) then each of those is a different write master. It seems conceptually easier than trying to route to a different collection set. Certainly sharding will be easier to rebalance (I think) than moving the collections around. John =:-> > > This talk is about mysql, not mongo, but I believe some of the lessons > are relevant to us. https://www.youtube.com/watch?v=qATTTSg6zXk > > By my calculations, with a maximum-sized namespace file, a single > mongo should be able to support over 90000 environments > using a separate collection-set for each environment. > > From my recollection of juju performance, we will be lucky to scale > a single mongo up to 1000 environments, let alone 90000, so I suspect we'd > never > get remotely that far. Perhaps there are other disadvantages > from having many collections though. > > It would be nice if we could make this crucial architectural decision in > the light of some actual measurements. We may all have some kind > of gut feeling for how this might perform, but without actually measuring, > we just don't know. > > As usual, my first reaction is KISS. > > cheers, > rog. >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
