incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Bartell <snbart...@gmail.com>
Subject Re: virtualizing databases
Date Fri, 31 May 2013 19:53:50 GMT
Thanks guys.

Benoit, it looks like the alias improvement  you are talking about is couchdb-1736? It still
looks like its baking. What I need is something a little bigger than aliases though. I'd like
the ability to redirect to a remote Couch.

Simon, my database list can get into the hundreds.  Like you say, I think I'll need to use
a proxy.  I want this thing to bolt right into couchdb using daemon services  or whatever
other plugin approach is available.  Once its activated, then it should start routing.  The
big question, kind of like what Benoit mentioned with aliases, is where does the configuration
live?  If a cluster of Couch's is involved, I think these configs should also replicate around.
 Do you know of anything like this that already exists?

By the way, I gave https_global_handlers a try.  This seems to work fine if the database is
local.  However, it doesn't work if the destination is remote and authentication is involved.
Is this because the remote database does not have a session? Is it because auth isn't passed
through the proxy? Is this a bug?

Thanks for your thoughts!

On May 28, 2013, at 8:21 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On May 29, 2013 3:23 AM, "Stephen Bartell" <snbartell@gmail.com> wrote:
>> 
>> Hi all.  I'm not sure if the subject really is the right terminology for
> what I'm trying to do.
>> 
>> What I want to do is maintain a routing table of database:destination
> pairs, so that on my couchdb I can name my databases however I want.  I
> want to virtualize my database names.
>> 
>> I can see how this concept might be the basis for sharding.  So maybe
> something like this already exists.  But sharding is not my goal here.  I
> want to use this mostly for maintenance.  Oftentimes I need to do some work
> on a database, like trimming it down or filtering some stuff out.  This
> work can take hours and I want the database always available to the end
> users.  So for example, I have a database endpoint called "database" which
> maps to "database_a". In the background I might begin a filtered
> replication from "database_a" to "database_b".  Users can still access
> "database" while "database_b" is being created.  When the replication to
> "database_b" is done, I want to change my proxy table so that requests to
> "database" now go to "database_b".  I can now forget about "database_a".
>> 
>> I'm sure many of you guys have run into this kind of thing before.  What
> would you guys recommend.
>> 
>> Thanks!
> 
> DB aliases may sove that. There is a ticket about it. The questiin now is
> where to store this meta info.
> 
> - benot


Mime
View raw message