Re: Antw: LMDB usage with long or variable length keys

["Alex V." <alex.v.odesk@gmail.com>]

On 4/24/2015 10:45 AM, Ulrich Windl wrote:
> > > > "Alex V."<alex.v.odesk@gmail.com>  schrieb am 24.04.2015 um 08:54 in Nachricht
> <5539E88C.3080006@gmail.com>:
> > On 4/24/2015 9:02 AM, Ulrich Windl wrote:
> > > I think this depends very much on your access patterns (which you didn't
> > explain).
> > > Regards,
> > > Ulrich
> > What required is `get(key)` and `set(key, val)`. And, optional but not
> > unwanted, range lookup.
> Still unclear: What is the expected ratio between get and set for a specific key? Do you ever delete keys? If so, how many accesses do you expect before deleting a key?
>
> You could hash your keys using MD5 or SHA, and use the first 16 bytes as key. As your access pattern does not include enumerating the original keys, that would work, saving space vs. consuming some extra CPU cycles. I can think of other algorithms, but you were not specific with your access pattern.
>
> Regards,
> Ulrich
I haven't figured all the details yet, I am just looking for different 
possibilities. number of `get`s is probably many times higher than 
number of `set`s or `delete`s. One possible usage case is database that 
stores source files metadata(symbols) for autocompletion/navigation, 
something like "source navigator ng"(it uses bdb). Another use case is 
almost the same, with urls as keys and word index as metadata. Looks 
like basename/url parts hierarchy will do, I am going to test it some day.