Received: by 10.43.9.8 with SMTP id ou8mr3645753icb.4.1349372296950; Thu, 04 Oct 2012 10:38:16 -0700 (PDT) X-BeenThere: mongodb-user@googlegroups.com Received: by 10.50.214.34 with SMTP id nx2ls6756349igc.1.gmail; Thu, 04 Oct 2012 10:38:07 -0700 (PDT) Received: by 10.42.32.8 with SMTP id b8mr3606909icd.12.1349372287143; Thu, 04 Oct 2012 10:38:07 -0700 (PDT) Received: by 10.42.32.8 with SMTP id b8mr3606907icd.12.1349372287122; Thu, 04 Oct 2012 10:38:07 -0700 (PDT) Return-Path: Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by gmr-mx.google.com with ESMTPS id rf8si1052780igb.2.2012.10.04.10.38.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:38:07 -0700 (PDT) Received-SPF: pass (google.com: domain of ckwil...@gmail.com designates 209.85.223.182 as permitted sender) client-ip=209.85.223.182; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ckwil...@gmail.com designates 209.85.223.182 as permitted sender) smtp.mail=ckwil...@gmail.com; dkim=pass header...@gmail.com Received: by mail-ie0-f182.google.com with SMTP id k10so2669833iea.27 for ; Thu, 04 Oct 2012 10:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=mb0mrPMqaObaSATvylioQOrL7czD7oGVU8Aqg73OhyU=; b=HpbRmQnhB7KdZGudxl59JgdHv3J5klrv/uJpLi7/Bl1u55WaOPcnGTbHJsuEvVhqTk S6KYajnzOOJ6c6w72I5jpR6KQ+PSwjkGjRegP30kH6KhFvTtpF4LazERQQPRUhB5ov6v fisFpsL4L60CWroExp5wY+ONhbAqiUk4vw8bIA5NExBquefQDfgD0+yPmUepQZc02bkn zWC6K5Ygb2l9j28IWMIFmIa+eltqd07pclf1y2BVTtUgwaLXtQeWs7WzvLbs7pED4Syl z9t1uqEN2phR0qTf9bogRsjIPNquSBAnBatfq2010HiMA0sjt+4LGXeNIv3jZA+iG9dP uz9w== Received: by 10.50.180.131 with SMTP id do3mr6135035igc.56.1349372287001; Thu, 04 Oct 2012 10:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.104 with HTTP; Thu, 4 Oct 2012 10:37:46 -0700 (PDT) In-Reply-To: <9de45bb0-6201-4424-8db6-1805c6620a7f@googlegroups.com> References: <686be91b-9d76-4513-8709-d977e98646a2@googlegroups.com> <8a2207be-06eb-4f64-9430-b29afeb0d771@googlegroups.com> <9de45bb0-6201-4424-8db6-1805c6620a7f@googlegroups.com> From: Chris Wilcox Date: Thu, 4 Oct 2012 10:37:46 -0700 Message-ID: Subject: Re: [mongodb-user] Moving a collection to a new database (v2.2) To: mongodb-user@googlegroups.com Content-Type: multipart/alternative; boundary=14dae9340615d6230c04cb3f3792 --14dae9340615d6230c04cb3f3792 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, We (or rather our cloud provider) is using disk drives. I believe the slow down you're concerned about would only be on read operations. I assumed that the write operation took only as long as writing to memory. Do you know if that's true? Our application's bottleneck (we are 90% sure) is on write--due to *write locking*. Because our application is not read heavy I suspect that the decreased performance you're concerned about wouldn't effect us significantly. -Chris On Thu, Oct 4, 2012 at 6:31 AM, Stephen Lee wrote: > Actually, I meant the opposite of that. 0:) > > You might see some improvement in performance if you're using SSD's. > Otherwise, the overhead of having multiple databases, with fewer > collections per database, might slow you down. > > > On Wednesday, October 3, 2012 1:39:39 PM UTC-4, Stephen Lee wrote: >> >> If you have SSD's, then the overhead of having multiple databases, with >> fewer collections per database, might slow you down, too. >> >> On Tuesday, October 2, 2012 4:46:32 PM UTC-4, Chris Wilcox wrote: >>> >>> Hi Luciano, >>> >>> Thanks for your response. We actually have already upgraded our entire >>> cluster. All our MongoDB servers are running 2.2 currently. >>> >>> One of our application's main bottlenecks is the write-locking which >>> occurs when we write to one of several collections in our sharded cluster >>> (call them `bottleneck_coll1` and `bottleneck_coll2` in `database_a`). In >>> 2.2, write-locking only occurs on a per database level (not globally like >>> in previous versions). To take advantage of this new write-locking model, >>> we'd like to move `bottleneck_coll2` to a new database (`database_b`). >>> >>> I'm trying to figure out the easiest way to move this collection. >>> >>> Cheers, >>> -Chris >>> >>> >>> On Tue, Oct 2, 2012 at 6:44 AM, Luciano Issoe wrote: >>> >>>> Did you consider upgrading the entire cluster? >>>> >>>> >>>> On Fri, Sep 28, 2012 at 4:59 PM, Chris Wilcox wrote: >>>> >>>>> To take advantage of the improved concurrency in Mongodb 2.2--namely >>>>> database level locking--we would like to move a sharded collection to a new >>>>> database. >>>>> >>>>> I have been unable to find any documentation which will help with this >>>>> particular scenario. >>>>> >>>>> I know I cant just "rename" this sharded collection: >>>>> https://groups.google.com/d/**topic/mongodb-user/** >>>>> lajAcp3HkZ4/discussion >>>>> >>>>> The only thing I can think of is mongodump *the entire* collection and >>>>> mongorestore into a new database. What are my other options? >>>>> >>>>> Cheers! >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "mongodb-user" group. >>>>> To post to this group, send email to mongod...@googlegroups.com >>>>> To unsubscribe from this group, send email to >>>>> mongodb-user...@googlegroups.**com >>>>> See also the IRC channel -- freenode.net#mongodb >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "mongodb-user" group. >>>> To post to this group, send email to mongod...@googlegroups.com >>>> To unsubscribe from this group, send email to >>>> mongodb-user...@googlegroups.**com >>>> See also the IRC channel -- freenode.net#mongodb >>>> >>> >>> -- > You received this message because you are subscribed to the Google > Groups "mongodb-user" group. > To post to this group, send email to mongodb-user@googlegroups.com > To unsubscribe from this group, send email to > mongodb-user+unsubscribe@googlegroups.com > See also the IRC channel -- freenode.net#mongodb > --14dae9340615d6230c04cb3f3792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stephen,

We (or rather our cloud provider) is using d= isk drives.

I believe the slow down you're con= cerned about would only be on read operations. I assumed that the write ope= ration took only as long as writing to memory. Do you know if that's tr= ue?

Our application's bottleneck (we are 90% sure) is o= n write--due to *write locking*. Because our application is not read heavy = I suspect that the decreased performance you're concerned about wouldn&= #39;t effect us significantly.

-Chris


On Thu, Oct 4, 2012 at 6:31 AM, Stephen = Lee <stephen....@10gen.com> wrote:
Actually, I meant the opposite of that. =A00:)

You might= see some improvement in performance if you're using SSD's. =A0Othe= rwise, the overhead of having multiple databases, with fewer collections pe= r database, might slow you down.


On Wednesday, October 3, 2012 1:39:39 PM UTC-4, Stephen Lee wr= ote:
If you have SSD's, then the= overhead of having multiple databases, with fewer collections per database= , might slow you down, too.

On Tuesday, October 2, 2012 4:46:32 PM UTC-4, Chris Wilcox wrote:
Hi Luciano,

Thanks for your response. We actually have already upgraded our entire clus= ter. All our MongoDB servers are running 2.2 currently.

One of our application's main bottlenecks is the write-locking wh= ich occurs when we write to one of several collections in our sharded clust= er (call them `bottleneck_coll1` and `bottleneck_coll2` in `database_a`). I= n 2.2, write-locking only occurs on a per database level (not globally like= in previous versions). To take advantage of this new write-locking model, = we'd like to move `bottleneck_coll2` to a new database (`database_b`).<= /div>

I'm trying to figure out the easiest way to move th= is collection.

Cheers,
-Chris


On Tue, Oct 2, 2012 at 6:44 AM, Luciano = Issoe <mia...@gmail.com> wrote:
Did you consider upgrading the entire cluster?


On Fri, Sep 28, 2012 at 4:59 PM, Chris Wilcox <ckwi...@gmail.com> wrote:
To take advantage of the improved concurrenc= y in Mongodb 2.2--namely database level locking--we would like to move a sh= arded collection to a new database.

I have been unable to find any documentation which will help= with this particular scenario.=A0

I know I cant j= ust "rename" this sharded collection: ht= tps://groups.google.com/d/topic/mongodb-user/lajAcp3HkZ4/disc= ussion

The only thing I can think of is mongodump *the entire*= collection and mongorestore into a new database.=A0What are my other optio= ns?

Cheers!

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user+unsubscribe@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

--14dae9340615d6230c04cb3f3792--