> So our options are: > 1) Open the block numbers database with sorted duplicates enabled. Then scan > through it for dupes, keep the correct one in each case, close the database, > and re-open it again with sorted duplicates disabled. > 2) Keep the block numbers index open with sorted duplicates enabled. When we > need to look up a block number, deal with the fact that there may be multiple > keys referring to it, and delete as appropriate. Deal with the fact that this > may cause keys in the main database that don't exist in the store. > 3) Improve the data stored on disk: Store the LRU access time, and the key, > on > disk. Probably we would need migration code. > 4) Use a completely different database for the index. > 5) Use a completely different database for the whole store, and trust it not > to lose the data. (from our experience with BDB, it is likely that it will!) > 6) Roll our own database code.
It seems to me that BDB has been rejected as the proper solution multiple times on this mailing list. Maybe I misunderstood, but in particular I remember when I was going to follow up with Oracle about memory usage issues but stopped when consensus seemed to find that BDB wasn't worth pursuing for various other reasons. ~Chris
