in reply to Re: tied hashed and deleting keys and their valeus
in thread tied hashed and deleting keys and their valeus

This means that the Btree and Hash databases are grow-only

wow, that's. crazy. what a bad system! I'll try the object interface... does that work with the AnyDB_File as well?

what possesed someone to make a db package like that? I guess its a tradeoff for being able to hold large amounts of info in the first place (grumble grumble)

 

-justin simoni
!skazat!

  • Comment on Re: Re: tied hashed and deleting keys and their valeus

Replies are listed 'Best First'.
Re: Re: Re: tied hashed and deleting keys and their valeus
by jeroenes (Priest) on Jan 31, 2001 at 15:14 UTC
    Well, you can imagine that whenever you have a 2Gigabyte file, it takes really a lot of time to shift the whole thing let's say 10 bytes. If the database is occupied with that every delete for about 15 minutes, the user isn't happy.

    If you really want to save space, the copy isn't a really bad option.

    Jeroen
    "We are not alone"(FZ)

Re: Re: Re: tied hashed and deleting keys and their valeus
by Fastolfe (Vicar) on Jan 31, 2001 at 22:05 UTC
    This is a relatively known and generally widely accepted drawback to using DB files. As another poster mentions, the overhead involved in re-building the DB file after the deletion of a row within it would make using the DB file horribly slow and expensive. Space is re-used where it can. In other words if you come back later and insert a new row, it will try to re-use some of the space already allocated (but 'deleted'), but it's not going to make an effort to shift everything else around to accomodate. This is precisely the same problem that leads to filesystem fragmentation.

    If you want efficient data storage, consider using a real database instead.

Re: Re: Re: tied hashed and deleting keys and their valeus
by extremely (Priest) on Jan 31, 2001 at 23:11 UTC
    Well, the speed vs. space trade off is the most common optimization there is. In this case it is a perfectly fine tradeoff that they made. How often do you think it is that DBs shrink significantly?

    --
    $you = new YOU;
    honk() if $you->love(perl)

      I use the DB File to save mailings from a lightweight Mailing List Manager I develop. The only time something needs to be removed is when the administrator deletes an email message that saved in the DB FIle archive. The keys are created using the date, so no 2 keys are ever used twice. If the removed entries' space is reused later, that's perfectly fine. My test archive was about 3.5 megs, about 100 messages worth.

      I still have the problem of entries not being removed at all. Anyone else have this?

       

      -justin simoni
      !skazat!

        Nobody seems to reply here, and I feel somebody should... but I think other monks could provide better insights.

        I don't know very much about the other dbases mentioned in AnyDBM_File. It appears that you have a choice. Which DBM are you using? Your 'lack of deletion' may be a DBM related problem. Have you tried the same test using BerkeleyDB? If it's not on your system, point your browser to sleepycat.

        If you want further discussion, just /msg me.

        Cheers,

        Jeroen
        "We are not alone"(FZ)