-Re: Lucene instead of HFiles?
Michael Segel 2012-10-05, 11:14
Actually I think you'd want to do the reverse.
Store your Lucene index in HBase. Which is what we did a while back.
This could be extended to SOLR, but we never had time to do it.
On Oct 5, 2012, at 4:11 AM, Lars George <[EMAIL PROTECTED]> wrote:
> Hi Otis,
> My initial reaction was, "interesting idea". On second thoughts though I do not see how this makes more sense compared to what we have now. HFiles combined with Bloom filters are fast to look up anyways. Adding Lucene as another "Storage Engine" (getting us close to Voldemort or MySQL with replaceable storage backends) does seem to not add any value, and more so, might even have a few drawbacks. Especially range scans will suffer, as HFiles and their block oriented layout plus caching makes for really fast I/O. Lucene is for search, not xyzbytes of data transfers. And simply replacing the block index and Blooms with Lucene is also I think overkill. Just saying.
> On Oct 5, 2012, at 5:34 AM, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
>> Has anyone attempted using Lucene instead of HFiles (see
>> https://twitter.com/otisg/status/254047978174701568 )?
>> Is that a completely crazy, bad, would-never-work,
>> don't-bother-trying-this-at-home, it's-too-late-go-to-sleep idea? Or
>> Search Analytics - http://sematext.com/search-analytics/index.html
>> Performance Monitoring - http://sematext.com/spm/index.html