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
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.
openldap-technical@openldap.org
-
Alex V.