Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Secondary indexes suggestions


Copy link to this message
-
Re: Secondary indexes suggestions
I think you need to think outside of the box...

I've thought about it a little more and while there's validity to indexing at the RS, there's a bit more of a headache.

But I think you've been too dismissive of looking at the index at the table level and not at the region level.

 
On Aug 14, 2012, at 8:59 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> Hey Lars,
>
> On Tue, Aug 14, 2012 at 5:08 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> Yep. It's not simple if (and only if) you data is changing a lot. Michael is right though, that it is simple problem if your data is static.
>
> Yeah, a good option for that are MR processes that emit in one shot
> HFiles for bulk import of infrequent updates into the primary table
> and all projections/materializations/indices. We have an application
> that does this in production.
>
>> Todd Lipcon and I were talking last week. And he mentioned primitives like logged updates,operations that will eventually complete, and as long as log-replay can be forced before a read operation they can be used for consistent indexes.
>
> Back to HBASE-3340 again. :-)
>
> Best regards,
>
>   - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB