Re: RFComments on various DBM strategies

[johncon.com">john]

> Sender: usenix.org!sage-members-owner
> X-Authentication-Warning: mox.perl.com: Host localhost didn't use HELO protocol
> Reply-To: tchristperl.com
> Date: Fri, 07 Oct 94 09:00:01 MDT
> From: Tom Christiansen <tchristmox.perl.com>
> Sender: sage-members-ownerusenix.org
> Precedence: bulk
> Content-Type: text
> Content-Length: 1489
> 
> For doing thing in Perl, I'd like to standardize on Berkeley DB, but I
> hear it's hard to support.  Here's a stab at a feature table.  If you've
> knowledge in this area, and have a spare momemnt, I'd appreciate it if you
> might please fill in what you can.  (These are all "supported" under
> perl5, but which one should a person choose and why is a FAQ whose answer
> I don't know.)
> 
> 
> 			    odbm    ndbm    sdbm    gdbm    bsd-db
> 
>     Comes w/ perl           no      no      yes     no      no
>     Comes w/ many unix os   yes     yes     no      no      no
>     Builds ok on !unix      ?       ?       yes     yes     ?
>     Code Size               ?       ?       small   big     big
>     Database Size           ?       ?       small   big?    ok?
>     Speed                   ?       ?       slow    ok      ok?
>     FTPable                 no      no      yes     yes     yes
>     Easy to build          N/A     N/A      yes     yes     no[1]
>     Size limits             1k      4k      1k[2]   none    none 
>     Byte-order independent  no      no      no      no      yes 
>     Licensing restrictions  ?       ?       no      yes     no 
> 
>     [1] unless your system is explicitly supported.  Requires symbolic links.
>     [2] by default, can be redefined
> 
> I'm especially interested in the question? areas, mistakes, or omissions.
>

Hi Tom. I did btreeperl using Berkeley DBM for perl 4.036. One of the
issues that prompted this was that bsd-db supports btrees, and that
will allow multiple identical keys, and the operators "less than,"
"greater than," etc. One of the issues is that bsd-db is not
concurrent multi-user (unless you serialize transactions in a
client-server scheme.) It is my understanding that the authors of
bsd-db are in the process of adding TA processing, etc., so I would
suppose that it is under a major re-write at this time. Bsd-db is a
good choice, IMHO-it is heavily cached and is very fast, (to about 25K
transactions per minute on my 16MHZ 386 at home,) and I didn't have
too much trouble doing all of the system ports-the only significant
issue is that there is not documentation on how to do it. Bsd-db is
supposedly a re-write the index code of the postgres database indexing
system. The authors are at Berkeley, and are responsive to the mailing
address in the sources.

One issue on using btrees is that multiple keys do not fit into the
associative array paradigm well-which is one of the corner stones of
Perl.

L. Wall will probably disagree with me, but I think a btree scheme
should be added to perl/Perl to facilitate corporate wide distributed
databases. Perl is an ideal environment to do this-eg., get away from
the centralized IS concept-but robustness and concurrency would be an
issue and should be addressed in the btree engine-which also means we
need an fsync(2) call in Perl (hint hint.)

BTW, ndbm does not come "standard" on the system V systems-it is
usually only in the BSD compatability libraries, which have a
perception of being "buggie." GDBM seems to run much slower than the
ndbm's, and is not source code compatable-in ndbm the key/data area is
static (thus the key/data information is destroyed on the next fetch
call,) and in gdbm the key/data area has to be free'd when you are
through with it (otherwise, a memory leak.)

One issue that is not addressed in the above table (I don't know how
important it is) is MSDOS compatability. Extensible hash gizmos
usually have some issues in the frail MSDOS file system.

	Just some opinions ...

	John

--

John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA.
VOX 408.370.2688, FAX 408.379.9602
johnjohncon.com