Re: nndb mailing list?

[David Blacka <blackad@ipcsun3.den.mmc.com>]

>>>>> "Brad" == Brad Miller <bmiller@cs.umn.edu> writes:

 Brad> The GroupLens Better Bit Bureau uses gdbm as its database, and I can
 Brad> vouch for the fact that performance over NFS is really really bad.
 Brad> Also, if you happen to get into a situation where you are frequently
 Brad> updating the data associated with one key, the database will start to
 Brad> grow all out of proportion.  The only solution to this seems to be to
 Brad> call gdbm_reorganize, but that is terribly slow.  I've had some database
 Brad> files go from 46Meg back down to 8Meg with one call to reorg!
 Brad> \Brad

All gdbm_reorganize actually does is just pull everthing out of the
current database, and write it into a new one that replaces it.  So it
isn't a real speedy process, but it needs to be done to prevent the
database from growing to infinite size.

As far as nndb is concerned, we've found that the MH style backend is
probably the best solution, both space and speed wise.  While a
berkely db article database is lightning fast, it is *huge*.  The MH
style article db is not a whole lot slower, and only sucks up inodes.
The xover db (which is still some sort of db file) still can get
large, though.

I'm definately going to make the GDBM files reorganize occasionally.
Unfortunately, there isn't an equivalent berkeley db command.

-- 
David Blacka                    |dblacka@fuentez.com
Software Engineer               |Fuentez Systems Concepts