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. Chris > cheers > > > -- > Filipe David Manana, > [email protected] > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men."
