jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Faceted Search Implementation
Date Wed, 25 Aug 2010 09:24:14 GMT
On Tue, Aug 24, 2010 at 19:26, Korbinian Bachl - privat
<korbinian.bachl@whiskyworld.de> wrote:
> Hi James,
>
> IMHO this construct is not what Jackrabbit should do or can do well. You can
> save the data that way or others, however to query it later (usually for
> display on a website etc.) you might want to have a look at SOLR
> (http://lucene.apache.org/solr/). An example for facting is under
> http://www.lucidimagination.com/Community/Hear-from-the-Experts/Articles/Faceted-Search-Solr
> explained.
>
> Think that faceting isn't only the type/ product path - its the n-relevant
> feature/type path on a possible subsize/ submass of the original set.
> Usually faceting therefore is unique per page visit. Meaning you will have
> many concurrent facets from different sources on a different (sub)set. This
> could be done in jackrabbit, but IMHO won't scale nearly as well as a
> specialized search solution like SOLR where it won't matter if you have 10
> products or 10 million products.

Well, if you can boil it down to property matches or jcr:like calls,
as I proposed, it makes full use of the Lucene index, and the search
part will be fast.

The thing that on the other hand might be slower are large updates,
such as renaming of facets, because you have to modify all the content
nodes. But this is a general issue of de-normalized unstructured
storages, and if these operations do not occur frequently (as opposed
to searching and reading), it is a good trade-off.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Mime
View raw message