Moving a collection to a new database (v2.2)

[Chris Wilcox]

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!

[Luciano Issoe]

Did you consider upgrading the entire cluster?

--
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

[Chris Wilcox]

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

[Stephen Lee]

If you have SSD's, then the overhead of having multiple databases, with fewer collections per database, might slow you down, too.

[Stephen Lee]

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.

[Chris Wilcox]

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