Menu

#532 Very slow loading BDB ISAM database using non-unique alternate keys

GC 4.0
open
BDB (5)
5 - default
2022-10-08
2018-06-24
Artie A
No

Loading a BDB ISAM database that has many duplicate alternates is very slow.
It took 3500 secs to load 128K 70 character records.
If I make the alternate keys unique by adding part of the primary to the end of the alternate key, the load took only 6 secs.

Loading VBISAM database does not have this problem.
It took the same amount time to load unique and non-unique alternate keys.

1 Attachments

Discussion

  • Simon Sobisch

    Simon Sobisch - 2022-10-08
    • assigned_to: Simon Sobisch --> Ron Norman
    • Group: GC 3.0 --> GC 4.0
     
  • Simon Sobisch

    Simon Sobisch - 2022-10-08

    @rjnorman74: While VISAM is much faster in general - wouldn't it be reasonable to always do this in fbdb.c?

    While it would increase the file size- internally attaching the primary key (or all parts that are not already in for split keys) or - possibly better (at least smaller) - adding a record counter to all non-unique alternate keys seems like a useful thing to do (also to read secondary keys in the correct order).

    There could be an internal "version" marker to know if those are available or not (ideally as "meta data" in the .dat file).

    What do you think?

     
  • Ron Norman

    Ron Norman - 2022-10-08

    Correct! BDB is not fast.
    If you want even slower try using LMDB as that is the worst.
    Very BAD idea to change the file structure to work around poor performance when there is a much simpler and easier solution to just use V-ISAM.

     
    • Vincent (Bryan) Coen

      On 08/10/2022 17:53, Ron Norman wrote:

      Correct! BDB is not fast.
      If you want even slower try using LMDB as that is the worst.
      Very BAD idea to change the file structure to work around poor
      performance when there is a much simpler and easier solution to just
      use V-ISAM.

      Who or what maintains this product?

      My attempt earlier this year to use VBISAM was a total failure but there
      again it is yet another tool that is no longer fully maintained or
      maintained at all !

      While BDB (I assume here you mean that later versions)  at 18.1.40 etc
      as I have NOT found it slow at all at least on files holding > 1000 ISAM
      records.
      On top of which is is still fully maintained by Oracle.

      Ooh, above is using primary keys and one alternative key file with large
      keys, also with dups allowed.

      Vince

       

Log in to post a comment.