On 2/24/11 2:50 AM, Alex Karasulu wrote:
On Wed, Feb 23, 2011 at 8:51 PM, Stefan Seelmann<seelm...@apache.org> wrote:
It made me think that maybe using a hashed index for Rdn is probably a
better idea, because then we won't need this comparison to be done (the
equals method would be enough) and also because it would be faster (finding
an element in a Hash table is an O(1) operation - at least, theorically -
when looking in a BTree is an O(log2(N)))
I think in the current state the RDN index doesn't need to be ordered
data structure, a hash table is sufficient.
However we still need to cleanup the backends. One idea I had is to
get rid of the onlevel and sublevel index and use the RDN index
instead. I did that in the HBase prototype where the onelevel and
sublevel index are no physical indexes but backed by the RDN index
table. But if we do that then I think the RDN index needs to be a
ordered data structure to be able to traverse the index using a
cursor.
Yes we need an ordered index and hence we need to be able to compare
two RDN values to sort.
we can use the Rdn Hashcode to do that, no ?
I never considered making the onelevel and sublevel indices backed by
the RDN index. It makes sense to do this and would improve performance
because there's less house keeping to do and less IO on separate
indices.
Interesting.
To be investigated, sure.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
