Thank you Ryan for this detailed answer. As my indexed column will be in
100% of the keys (dense case), I think I'll need to forget about IHbase ;)
Cheers
TuX
Ryan Rawson wrote:
Another way to think about it is that IHBase helps when the data is
not dense (ie: every row has the column you may be looking for), and
not sparse (where 1 column in millions or billions match) but
somewhere inbetween. That sweet spot where you might return anywhere
between 10-30% of the rows from a region.
Of course these are just suggestions and recommendations not hard and
fast rules.
You might also want to look at THBase - it uses a transactional add-on
to maintain a secondary index (ie: another table that is an index of a
primary table). It has different performance characteristics (one
write is translated into many writes and involves an RPC), but an
option to consider.
Finally, you can always maintain secondary indexes by yourself in your
app. Write and update 2 tables (the primary, the index). This is
obviously less integrated and simple but also works.
-ryan
