That's an interesting question (really). Before reading Mastering Algorithms with Perl (O'Reilly & Associates), I would have assumed that as you add elements to a conventional Perl hash there must be some increase in the amount of time it takes to look up one of the elements. Even after reading MAwP, which gives an introduction to how hashes are implemented, I might have thought that the order of growth as you add elements would be O(log N), which is a fancy way of saying that as you add elements there is a relatively small growth in the length of time it takes to perform lookups.

"...might have thought...", I say, because MAwP puts that theory to rest and sets the record straight when it specifically states that a well written hashing algorithm will yield O(1) order of growth, which is a fancy way of saying that there is no growth in the computational work of looking up hash elements as the hash grows large.

Here is a test verifying that theory with respect to Perl's internal hashes.

use Benchmark qw/:all/;

@lrg_hash{ 0 .. 20000 } = ();

@sml_hash{ 0 .. 10 } = ();
$sml_hash{ 5000 } = undef; # Create a hash key of the same name in
                           # %sml_hash as in %lrg_hash.

cmpthese (  500000, {
            Big     => '$lrg_hash{5000}=1;',
            Little  => '$sml_hash{5000}=1;'
} );

__OUTPUT__
           Rate    Big Little
Big    378788/s     --    -1%
Little 381679/s     1%     --
[download]

Clearly there is an insignificant time difference.

I'm not familiar with MLDBM's internal algorithm, but if it is a well written hash, as are Perl's hashes, you can expect O(1) order of growth. Go ahead and let the DB grow to 50,000 elements, or 500,000 elements, it won't matter. To confirm this, I ran the following benchmark:

use MLDBM;
use Benchmark qw/:all/;
use Fcntl;

$dbL = tie %lrg_hash, 'MLDBM', 'lrgtest.dbm', O_CREAT|O_RDWR, 0640
    or die $!;
$dbS = tie %sml_hash, 'MLDBM', 'smltest.dbm', O_CREAT|O_RDWR, 0640
    or die $!;


@lrg_hash{ 0 .. 20000 } = ();


@sml_hash{ 0 .. 10 } = ();
$sml_hash{ 5000 } = undef; # Create a hash key of the same name in
                           # %sml_hash as in %lrg_hash.

cmpthese (  5000, {
            Big     => '$lrg_hash{5000}=1;',
            Little  => '$sml_hash{5000}=1;'
} );


__OUTPUT__
         Rate    Big Little
Big    3247/s     --    -4%
Little 3378/s     4%     --
[download]

Although the DB access slows things down considerably, there is no appreciable difference between the speed of looking up a hash element in the 20,000 element hash, and the 11 element hash.

But once the files were built, retrieval was never a problem -- retrieval time does not increase noticeably with the amount of data being stored (in terms of number of keys or overall content). That's the whole point of DBM files.

(I think the problem with building the DBM file has to do with how often, and in what manner, the tool has to rebuild its hashing table -- the indexes used for seeking to the data for a given key -- as more keys are added. The DBM flavors that keep the hash index and data in separate files are likely to be faster than those that create only a single file with indexes and data combined.)

So if growing the database will be an ongoing activity in your app (such that users would be bothered if there were a 2-minute lag when they hit a button to add data), you'll want to test MLDBM in terms of how long it takes to add increments of, say, 5K records at a time, and look out for either occasional or consistent delays in each increment.

An adequate test would be to generate an appropriate number of "random" strings with suitable length, maybe using MD5 checksums as the keys or something like that.

My question is will the speed diminish as the volume of data increases to say 10,000 or possibly 50,000? Will it get to a point where reading the data is unbearable slow?

There's a saying among programmers, especially in the Perl community:

When in doubt, benchmark!

I suggest that you read the docs for Benchmark.