Nov 22, 2016 at 5:47 PM, Chitra R
> > wrote:
> > > >>
> > > >>
> > > >> Kindly post your suggestions.
> > > >>
> > > >> Regards,
> > > >> Chitra
> > > >>
> > > >>
your suggestions.
> > >>
> > >> Regards,
> > >> Chitra
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
&
;
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sat, Nov 19, 2016 at 1:38 PM, Chitra R
> wrote:
> >>>
> >>> Hey, I got
t;>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Nov 19, 2016 at 1:38 PM, Chitra R wrote:
>>
R wrote:
>
>> Hey, I got it clearly. Thank you so much. Could you please help us to
>> implement it in our use case?
>>
>>
>> In our case, we are having dynamic index and it is variable depth too. So
>> flat facet is enough.No need of hierarchical facets.
>
it is variable depth too. So
> flat facet is enough.No need of hierarchical facets.
>
> What I think is,
>
>
>1. Index my facet field as normal doc value field, so that no special
>operation (like taxonomy and sorted set doc values facet field) will be
>done
Hey, I got it clearly. Thank you so much. Could you please help us to
implement it in our use case?
In our case, we are having dynamic index and it is variable depth too. So
flat facet is enough.No need of hierarchical facets.
What I think is,
1. Index my facet field as normal doc value
I think you've summed up exactly the differences!
And, yes, it would be possible to emulate hierarchical facets on top
of flat facets, if the hierarchy is fixed depth like year/month/day.
But if it's variable depth, it's trickier (but I think still
possible). See e.g. the Commit
between both cases, hope so.
In taxonomy, building hierarchical facets at index time makes faceting cost
minimal at search time than flat facets in doc values.
Except (memory,time and NRT latency) , Is any another contrast between
hierarchical and flat facets at search time?
Kindly post your
Okay. I agree with you, Taxonomy maintains and supports hierarchical facets
during indexing. Hope hierarchical in the sense, we might index the field
Publish date : 2010/10/15 as Publish date: 2010 , Publish date: 2010/10
and Publish date: 2010/10/15 , their facet ordinals are maintained in
t; Hey, thank you so much for the fast response, I agree NRT refresh is
> somewhat costly operations and this is the major pitfall, suppose we use doc
> value faceting.
>
>
> While indexing SortedSetDocValuesFacetField , it stores
> path and dimension of the
pitfall, suppose we use
doc value faceting.
While indexing SortedSetDocValuesFacetField , it stores
path and dimension of the given field internally. So Can we achieve
hierarchical facets using DrillDownQuery? Hope, purpose of storing path and
dimension is to achieve hierarchica
nally. So Can we achieve
> hierarchical facets using DrillDownQuery? Hope, purpose of storing path and
> dimension is to achieve hierarchical facets. If yes (ie we can achieve
> hierarchy in SSDVFF) , so what is the need to move over taxonomy?
> Else I missed anything?
>
>
>
we achieve
hierarchical facets using DrillDownQuery? Hope, purpose of storing path and
dimension is to achieve hierarchical facets. If yes (ie we can achieve
hierarchy in SSDVFF) , so what is the need to move over taxonomy?
Else I missed anything?
What is the real purpose to
calculate facet counts
> only for matching docs. otherwise, it carries any other benefits?
Well, compared to the taxonomy facets, SSDV facets don't require a
separate index.
But they add latency/heap usage, and they cannot do hierarchical
facets yet (though this could be fixed if someone just
where they
> all rely on the same low-level data structure - Lucene!
>
> Shai
>
>
> On Thu, Nov 10, 2016 at 12:32 PM Kumaran Ramasubramanian <
> kums@gmail.com>
> wrote:
>
> > Hi All,
> > We all know that Lucene supports faceting by
viding
> Taxonomy(Separate index and hierarchical facets) and
> SortedSetDocValuesFacetField ( flat facets and no sidecar index).
>
> Then why did solr and elastic search go for its own implementation ?
> ( that is, solr uses block join & elasticsearch uses aggregations
Hi All,
We all know that Lucene supports faceting by providing
Taxonomy(Separate index and hierarchical facets) and
SortedSetDocValuesFacetField ( flat facets and no sidecar index).
Then why did solr and elastic search go for its own implementation ?
( that is, solr uses block
> we are using hierarchical facets (from
> org.apache.lucene.facet.taxonomy), in our case 1 entry can have
> several
> values referencing more leaves in the hierarchical facet.
>
> At search time we are noticing that if we search for exactly 1 entry
> we
> have count = 1
Hello everyone,
we are using hierarchical facets (from
org.apache.lucene.facet.taxonomy), in our case 1 entry can have several
values referencing more leaves in the hierarchical facet.
At search time we are noticing that if we search for exactly 1 entry we
have count = 1 in the hierarchical
Yes, hierarchical faceting in Lucene is only supported by the taxonomy
index, at least currently.
Shai
On Tue, Nov 25, 2014 at 3:46 PM, Vincent Sevel
wrote:
> hi,
> I saw that SortedSetDocValuesFacetCounts does not support hierarchical
> facets.
> Is that to say that hierarchica
hi,
I saw that SortedSetDocValuesFacetCounts does not support hierarchical facets.
Is that to say that hierarchical facets are only supported through the Taxonomy
index?
I am using lucene 4.7.2.
Regards,
vince
DISCLAIMER
This message is intended
22 matches
Mail list logo