Hi, Thanks for educating me, that makes sense. Is the one collection that can't be sharded the one holding the root of the repo ? (my oak terminology might not be right, sorry)
Ian On 30 January 2013 19:53, Thomas Mueller <[email protected]> wrote: > Hi, > > As far as I understand, this was within one shard and replica (one > mongod). See also: http://www.infoq.com/news/2010/08/MongoDB-1.6 > > For scalable writes, we would need to write concurrently to different > shards. Even if all operations within one shard are synchronized (and I > don't think that's the case), Oak would still be scalable. Concurrent > operations within one mongod might improve performance / throughput > however. > > > The current MongoMK does have a scalability problem in my view, because > there is at least one collection that can't be sharded. But I guess this > is something we need to solve anyway, if we really want to have a scalable > solution. > > Regards, > Thomas > > > > > On 1/29/13 11:42 PM, "Ian Boston" <[email protected]> wrote: > >>Hi, >>Are the concurrency characteristics of MongoDB [1] relevant to write >>concurrency in Oak ? >> >>IIUC from the presentation MongoDB pre 2.2 had global exclusive write >>locks and post 2.2 has per database exclusive write locks which might >>be scoped to the shard if the update only impacts a single shard. >> >>I am assuming that any storage implementation for Oak won't rely on >>this characteristic and could use a less synchronised storage >>mechanism from one of the other providers ? >> >>I ask, because I don't know if this is relevant, and want to be educated. >> >>Thanks >>Ian >> >>1 http://www.10gen.com/presentations/concurrency-internals-mongodb-v22 >
