couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: /_all_dbs and security
Date Mon, 01 Mar 2010 08:01:11 GMT

On 28 Feb 2010, at 09:39, J Chris Anderson wrote:

> On Feb 28, 2010, at 7:42 AM, Filipe David Manana wrote:
>>> this is the best reason I've heard for making it a security document. I
>>> wonder how much slower the 7.5k dbs scan proceeds when it has to look up
>>> documents instead of linked objects? do you mind adding a doc-read to the
>>> tight loop just to see what it does to performance?
>> $ time curl http://localhost:5984/_all_dbs | wc -l
>> % Total    % Received % Xferd  Average Speed   Time    Time     Time
>> Current
>>                                Dload  Upload   Total   Spent    Left
>> Speed
>> 100  100k    0  100k    0     0    576      0 --:--:--  0:02:57 --:--:--
>> 555
>> 7397
>> real    2m57.811s
>> user    0m0.000s
>> sys    0m0.020s
>> Alot more as expected.
>>> the 7.5k thing isn't important once we have a _dbs db, but the cost it will
>>> expose as a benchmark will be proportional to the cost incurred on opening
>>> any db for any operation, and thus significant.
>> True. Traversing the b-tree of _dbs to find if a particular doc exists, and
>> then eventually insert it (which could imply re-balancing  the tree from
>> time to time) would take several disk accesses.
>> Any other ideas on how to implement _all_dbs efficiently?
> The reason for no storing _security as a doc is an optimization. So we extend that optimization,
and have something like a  security_changed event for a db, that the _dbs database can react
to. The model isn't different from subscribing to _changes, it'd just be a separate code path.
> I think we can add your filter to _all_dbs, it seems "fast enough". People with millions
of dbs will still need to do something special in front of couch, but they probably won't
be changing their whole system to use the Reader ACLs anyway, as they already have a bunch
of namespaced db-names.

I'm not too happy about "half baked" solutions here where we go out
of our way to avoid them in other places.

If we attempt to make this work, we should get it right and not have
some invisible performance drop-off.

I think _dbs is the way to go, but we still need to vet it for design


> Chris
>> cheers
>> -- 
>> Filipe David Manana,
>> PGP key -
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."

View raw message