On Fri, Jul 4, 2014 at 6:01 AM, roger peppe <roger.pe...@canonical.com> wrote: > There is another possiblity: we could just use a different collection > name prefix for each environment. There is no hard limit on the number > of collections in mongo (see > http://docs.mongodb.org/manual/reference/limits/).
For sharding and for good space management in general it's better to have data in a collection that gets automatically managed by the cluster. It's also much simpler to deal with in general, even if it does require code changes to get started. > - for a small environment, table indexes remain small and lookups fast > even though the total number of entries might be huge. Same as above: when it gets _huge_ you need sharding either way, and it's easier and more efficient to manage a single collection than 10k. > - each environment could have a separate mongo txn log, so one busy > environment that's constantly adding transactions will not necessarily > slow down all the others. There is, in general, no need for sequential > consistency between > environments. With txn there's no sequential consistency even within the same environment, if you're touching different documents. > - database isolation between environments is an advantage when things > go wrong - it's easier to fix or delete individual environments if their > tables are isolated from one another. Sure, it prevents bad mistakes caused by not taking the environment id in consideration, but deleting "foo:*" is just as easy. > I suggest that, at the least, taking this approach would be a quick > road to making the state work with multiple environments. It > would not preclude a move to changing to use composite keys > in the future. We already know it's a bad idea today. Let's please not do that mistake. gustavo @ http://niemeyer.net -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
