couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: virtualizing databases
Date Fri, 31 May 2013 20:04:13 GMT
I discussed COUCHDB-1736 on dev@ the other day and just copied my comment into JIRA.  As you
observed, an alias system is somewhat akin to a degenerate case of sharding.  In BigCouch
we store the shard map for each clustered database in a special system database that is local
to each node in the cluster and is replicated between them.

The redirection to a remote CouchDB is interesting.  I'd assumed something like that would
be best accomplished via a reverse proxy in front of both servers.

Adam

On May 31, 2013, at 3:53 PM, Stephen Bartell <snbartell@gmail.com> wrote:

> 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