oices here:
> >> 1> live with the differing results until you get done re-indexing
> >> 2> index to an offline collection and then use, say, collection
> >> aliasing to make the switch atomically.
> >>
> >> Best,
> >> Erick
> >>
>>
>> On Thu, Aug 3, 2017 at 8:07 AM, David Hastings
>> wrote:
>>> Hey all, I have yet to run an experiment to test this but was wondering
>> if
>>> anyone knows the answer ahead of time.
>>> If i have an index built with documents before implementi
ction and then use, say, collection
> aliasing to make the switch atomically.
>
> Best,
> Erick
>
> On Thu, Aug 3, 2017 at 8:07 AM, David Hastings
> wrote:
> > Hey all, I have yet to run an experiment to test this but was wondering
> if
> > anyone knows the answe
ll, I have yet to run an experiment to test this but was wondering if
> anyone knows the answer ahead of time.
> If i have an index built with documents before implementing the commongrams
> filter, then enable it, and start adding documents that have the
> filter/tokenizer applied, will
Hey all, I have yet to run an experiment to test this but was wondering if
anyone knows the answer ahead of time.
If i have an index built with documents before implementing the commongrams
filter, then enable it, and start adding documents that have the
filter/tokenizer applied, will searches
April 2017 22:18
> To: solr-user@lucene.apache.org
> Subject: CommonGrams
>
> Hi, was wondering if there are any known drawbacks to using the CommonGram
> factory, in regards to such features as the "more like this"
>
Hi, was wondering if there are any known drawbacks to using the CommonGram
factory, in regards to such features as the "more like this"
On 2/10/2017 2:55 PM, David Hastings wrote:
> of right now has 22 million documents and sits around 360 gb. at this
> rate, it would be around a TB index size. is there a common
> hardware/software configuration to handle TB size indexes?
Memory is the secret to Solr performance. Lots and lots of
Hey All,
I followed an old blog post about implementing the common grams, and used
the 400 most popular words file on a subset of my data. original index
size was 33gb with 2.2 million documents, using the 400, it grep to 96gb.
I scaled it down to the 100 most common words and got to about 76gb,
-
From: Salman Akram [mailto:salman.ak...@northbaysolutions.net]
Sent: Wednesday, April 27, 2011 1:43 PM
To: solr-user@lucene.apache.org
Subject: Re: CommonGrams indexing very slow!
Thanks for the response. We got it resolved! .
We made small indexes in bulk using SOLR with Standard File Forma
g so we can see your mergeFactor and
> ramBufferSizeMB settings?
>
> Tom
>
> > > All,
> > >
> > > We have created index with CommonGrams and the final size is around
> > 370GB.
> > > Everything is working fine but now when we add more documents int
documents
and committing triggers a cascading merge. (But this is a WAG without seeing
what's in your indexwriter log)
Can you also send your solrconfig so we can see your mergeFactor and
ramBufferSizeMB settings?
Tom
> > All,
> >
> > We have created index with CommonGram
you by any chance optimizing?
>
> Best
> Erick
>
> On Wed, Apr 27, 2011 at 11:04 AM, Salman Akram
> wrote:
> > All,
> >
> > We have created index with CommonGrams and the final size is around
> 370GB.
> > Everything is working fine but now when we add
Are you by any chance optimizing?
Best
Erick
On Wed, Apr 27, 2011 at 11:04 AM, Salman Akram
wrote:
> All,
>
> We have created index with CommonGrams and the final size is around 370GB.
> Everything is working fine but now when we add more documents into index it
> takes forever (
All,
We have created index with CommonGrams and the final size is around 370GB.
Everything is working fine but now when we add more documents into index it
takes forever (almost 12 hours)...seems to change all the segments file in a
commit.
The same commit used to take few mins with normal index
Anyone?
On Mon, Jan 17, 2011 at 7:48 PM, Salman Akram <
salman.ak...@northbaysolutions.net> wrote:
> Hi,
>
> I am trying to use CommonGrams with SOLR - 1604 patch but doesn't seem to
> work.
>
> If I don't add {!complexphrase} it uses CommonGramsQueryFilterFact
Hi,
I am trying to use CommonGrams with SOLR - 1604 patch but doesn't seem to
work.
If I don't add {!complexphrase} it uses CommonGramsQueryFilterFactory and
proper bi-grams are made but of course doesn't use this patch.
If I add {!complexphrase} it simply does it the old
Ok sorry it was my fault.
I wasn't using CommonGramsQueryFilter for query, just had Filter for
indexing. The query seems fine now.
On Mon, Jan 17, 2011 at 1:44 PM, Salman Akram <
salman.ak...@northbaysolutions.net> wrote:
> Hi,
>
> I have made an index using CommonGrams. N
Hi,
I have made an index using CommonGrams. Now when I query "a b" and explain
it, SOLR makes it +MultiPhraseQuery(Contents:"(a a_b) b").
Shouldn't it just be searching "a_b"? I am asking this coz even though I am
using CommonGrams it's much slower than
Hi Norberto,
After working a bit on trying to port the Nutch CommonGrams code, I ran into
lots of dependencies on Nutch and Hadoop. Would it be possible to get more
information on how you use shingles (or code)? Are you creating shingles for
all two word combinations or using a list of words
On Wed, 26 Nov 2008 10:08:03 +1100
Norberto Meijome <[EMAIL PROTECTED]> wrote:
> We didn't notice any severe performance hit but :
> - data set isn't huge ( ca 1 MM docs).
> - reindexed nightly via DIH from MS-SQL, so we can use a separate cache layer
> to lower the number of hits to SOLR.
To mak
On Mon, 24 Nov 2008 13:31:39 -0500
"Burton-West, Tom" <[EMAIL PROTECTED]> wrote:
> The approach to this problem used by Nutch looks promising. Has anyone
> ported the Nutch CommonGrams filter to Solr?
>
> "Construct n-grams for frequently occuring terms and p
uot;man on the moon" etc.)
>
> The approach to this problem used by Nutch looks promising. Has anyone
> ported the Nutch CommonGrams filter to Solr?
>
> "Construct n-grams for frequently occuring terms and phrases while
> indexing. Optimize phrase queries to use the n-
to various problems with false hits and some things becoming
> impossible to search with stop words turned on. (For example "to be or
> not to be", "the who", "man in the moon" vs "man on the moon" etc.)
>
> The approach to this problem used
r
not to be", "the who", "man in the moon" vs "man on the moon" etc.)
The approach to this problem used by Nutch looks promising. Has anyone
ported the Nutch CommonGrams filter to Solr?
"Construct n-grams for frequently occuring terms and phrases while
i
25 matches
Mail list logo
