durusmail: durus-users: Re: A newcomer and BerkeleyDB
A newcomer and BerkeleyDB
2005-12-15
2005-12-15
2005-12-15
2005-12-15
Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-15
Re: Alternative storage WAS A newcomer and BerkeleyDB
2005-12-16
2005-12-16
2005-12-16
Re: A newcomer and BerkeleyDB
2005-12-16
2005-12-15
2005-12-16
2005-12-16
2005-12-16
2005-12-16
2005-12-16
Re: A newcomer and BerkeleyDB
Jesus Cea
2005-12-16
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Schemenauer wrote:
>>  While you are packing a database, access to objects are blocked.
> Not true in version 3.

Glad to read that.

> However, other applications may have reference cycles within
> the persistent set of objects.

I agree.

>>  - BerkeleyDB is not affected by write ratio.
>
> I find that hard to believe.  In any case, Durus client will be
> affected by a high write rate.  If the write rate is high enough
> then it's probably more efficient to have a database that can
> locking.

The problem is not write rate but to write to the same objects. That is,
conflicts. In my project I would have a lot of writes, but fairly spreaded.

> Sounds like a fun project.  You might also look into
> DirectoryStorage as an alternative to BerkeleyDB.

You are talking about DirectoryStorage for ZODB, I suppose. I know it.
If you use a "decent" filesystem (reiserfs, for example) the
multimillion object count is not a problem. I am wondering about the
garbage strategy they use. Any idea?.

Update: I just read the FileStorage code. It use mark & sweep.

> Durus was
> designed to be simple and we sacrificed on scalability to achieve
> that.

Durus simplicity is the factor because I choose it instead of the
overkill ZODB.

I admit that current DURUS solve a lot of issues, like the index or the
online packing. Still, packing requires double space and memory use is
high (if you have a lot of objects). Silly inconvenients, I admit.

Maybe BerkeleyDB is overkill for Durus: for small databases, current
Durus runs fine, and for big ones Durus design probably doesn't scale.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBQ6JIMZlgi5GaxT1NAQLTiAQAi9hanI0aqvEAPiIEzLf3B6RRZ9OBKNjq
k0OaLK8cocDACX7LeoKY8tjB4Uwnuq9hbkAeeajFYWA5tFaEWVlDvYHZlzaeIrXx
yK1EBRp+Vx+MkapPT48FoemwWZ1HJkHu0GqkK4BILLzi+6tJUboY0fuqY47EFDkf
nqC5Eo3fYeE=
=qTrp
-----END PGP SIGNATURE-----
reply