hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: HBase Design Considerations
Date Thu, 27 May 2010 15:28:50 GMT
On Thu, May 27, 2010 at 4:23 PM, Daniel Einspanjer

> Mozilla's Socorro 2.0 project requires a search mechanism that is similar
> in
> requirements to what Saajan mentions in this thread.
> At the moment, I'm investigating integrating ElasticSearch with HBase to
> provide
> this functionality.  We will likely be releasing Socorro 2.0 in the late
> July or
> early August timeframe.
> I'd very much like to chat with Saajan and Steven further about use cases
> and
> implementation plans to see where we might be able to effectively
> collaborate.

We're currently hard at work on a number of different components of Lily,
basically arriving with a 'proof of architecture' (that is: an HBase-backed
WAL/queue that integrates SOLR with our Lily content model stored in HBase)
by mid July. We choose to build the queue system backed with HBase
persistency since we wanted the queue to be distributable as well.

In terms of search, we opted for SOLR and a mapping between our own content
model and SOLR fields. We're still hard at work on that, so I can't tell you
much about that. Our content model might be slightly higher-level than what
you would need for Socorro's purposes (we support versionable data, and
various field types, with a link type as well).

We're basically in heads-down mode at the moment, I hope I'll be able to
share some concrete planning and design considerations during my Berlin
Buzzwords talk the week after next week. From there on, we'll try to
communicate more regularly concerning progress.

Does that help? Hm. Not much, I guess.

Oh: the license will be Apache. No strings attached!


Steven Noels                            http://outerthought.org/
Outerthought                            Open Source Java & XML
stevenn at outerthought.org             Makers of the Daisy CMS

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message