Ndbm
Encyclopedia
ndbm is a Berkeley produced
version from 1986 of the AT&T dbm
database.
ndbm stores arbitrary data by use of a single key in fixed-size buckets.
internal block size (normally between 512 and 4096
bytes). Moreover all key/content pairs that hash together must
fit on a single block.
that corresponds to the hash of the key. If two or more keys
hashes to the same value, all data for those keys must be stored
in the same data block. dbm_store is supposed to return an
error in the event that a disk block fills up, but there are
situations where it doesn't, and you could just end up quietly
delete another entry.
Since you do not which keys hash together, you may not depend on
they hash to different buckets. If you are unlucky, all your
keys could hash to the same hash value and therefor all your data and
some unknown internal metadata must fit in one bucket, which is one block (normally
512-4096 bytes).
This means that the entire database is only guaranteed to be
fully stored and retrievable if it the entire dataset including
some internal metadata fits in one disk block. If you store more
data than that, some data may in some situations just quietly
disappear.
Obviously, because of this, if you are interested in being able
to retrieve the data you have save, ndbm should not be used, and
almost any other storage format is better than ndbm.
The problem is very seldom mentioned in the documentation. One of the few places is a note in the Solaris ndbm(3C) man page.
Still, for historical reasons, ndbm is delivered with several
operating systems and used by several programs and systems out
there.
version from 1986 of the AT&T dbm
Dbm
dbm was the first of a family of simple database engines, originally written by Ken Thompson and released by AT&T in 1979. The name is a three letter acronym for database manager....
database.
ndbm stores arbitrary data by use of a single key in fixed-size buckets.
Problems
The sum of the sizes of a key/content pair must not exceed theinternal block size (normally between 512 and 4096
bytes). Moreover all key/content pairs that hash together must
fit on a single block.
Discussion
When storing an entry, dbm_store stores the data in the blockthat corresponds to the hash of the key. If two or more keys
hashes to the same value, all data for those keys must be stored
in the same data block. dbm_store is supposed to return an
error in the event that a disk block fills up, but there are
situations where it doesn't, and you could just end up quietly
delete another entry.
Since you do not which keys hash together, you may not depend on
they hash to different buckets. If you are unlucky, all your
keys could hash to the same hash value and therefor all your data and
some unknown internal metadata must fit in one bucket, which is one block (normally
512-4096 bytes).
This means that the entire database is only guaranteed to be
fully stored and retrievable if it the entire dataset including
some internal metadata fits in one disk block. If you store more
data than that, some data may in some situations just quietly
disappear.
Obviously, because of this, if you are interested in being able
to retrieve the data you have save, ndbm should not be used, and
almost any other storage format is better than ndbm.
The problem is very seldom mentioned in the documentation. One of the few places is a note in the Solaris ndbm(3C) man page.
Still, for historical reasons, ndbm is delivered with several
operating systems and used by several programs and systems out
there.