I am running some experiments on more like this and the results seem rather
odd - I am doing something wrong but just cannot figure out what.
Basically, the similarity results are decent - but not great.
*Issue 1 = Quality*
Toyota Camry : finds Altima (good) but then next one is Camry Hybrid
wher
he top (tf should be 1 for your
> data).
> Enable &debugQuery=true and look at explain section to see show score is
> getting calculated.
>
> You should try giving different boosts to class, type, drive, size to
> control the results.
>
>
> On Sun, Mar 31, 2013 at 8:52 P
Amazon ec2 to bring up your solr, you should be
>able to get a micro instance for free trial.
>
>
>On Mon, Apr 1, 2013 at 5:10 AM, dc tech wrote:
>
>> I did try the raw query against the *simi* field and those seem to return
>> results in the order expected.
>>
ith a password
>(note that the basic password authentication sends passwords in clear text if
>you're not using HTTPS, best lock the thing down behind a firewall).
>
>Dave
>
>
>-Original Message-
>From: DC tech [mailto:dctech1...@gmail.com]
>Sent: Tuesday, April 02,
Definitely in 4.x release. Did you try it and found a problem?
See example below
1. Search for SUVs and boost Honda models
q=suv&boost=query({! v='honda'},1)
2. Search for SUVs and boost Honda OR toyota model
a) Using OR in the query does NOT work
q=suv&boost=query({! v='honda or toyota'},1)
b) Using two query functions and summing the boosts DOES w
6, 2013 at 10:19 AM, Yonik Seeley wrote:
> On Sat, Apr 6, 2013 at 9:42 AM, dc tech wrote:
> > See example below
> > 1. Search for SUVs and boost Honda models
> > q=suv&boost=query({! v='honda'},1)
> >
> > 2. Search for SUVs and boost Honda OR t
To minimize my own typing when setting up SOLR schema or config, I created
a simple Excel that can reduce the amount of typing that is required.
Please feel free to use it if you find it useful.
solr_schema_shared.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.shee
honda
text,score
suv
query($boostq,1)
true
edismax
DEBUG:
suv
suv
BoostedQuery(boost(+(text:suv),query(text:toyota text:honda,def=1.0)))
boost(+(text:suv),query(text:toyota text:honda,def=1.0))
On Sun, Apr 7, 2013 at 9:07 AM, Yonik Seeley wrote:
> On Sun, Apr 7, 2013 at 8:39 AM, dc
Are you storing the full 1,000 pages in the index? If so, that is
probably not helping either.
On 7/23/10, ahammad wrote:
>
> Hello,
>
> I have an index with lots of different types of documents. One of those
> types basically contains extracts of PDF docs. Some of those PDFs can have
> 1000+ pag
1,500 threads seems extreme by any standards so there is something
happening in your install. Even with appservers for web apps,
typically 100 would be a fair # of threads.
On 7/28/10, Christos Constantinou wrote:
> Hi,
>
> Solr seems to be crashing after a JVM exception that new threads cannot
Are you storing the entire log file text in SOLR? That's almost 3gb of
text that you are storing in the SOLR. Try to
1) Is this first time performance or on repaat queries with the same fields?
2) Optimze the index and test performance again
3) index without storing the text and see what the perfor
Have you looked at the relevance scores? I would speculate elevate
matches would have constant, high score.
On 8/3/10, Vishal.Arora wrote:
>
> Suppose i have elevate.xml file and i elevate the ID :- Artist:11650 and
> Artist:510 when i search for corgan
> this is elevate File
>
>
I think depends on what you need:
1) Simple,unique category - use display facet
2) Categories may be duplicate from display perspective (eg authors) :
store display#id in facet field but show only display
3) Internationalization requirements - store I'd but have ui pull and
display the translated l
I am a little confused - how did 180k documents become 100m index documents?
We use have over 20 indices (for different content sets), one with 5m
documents (about a couple of pages each) and another with 100k+ docs.
We can index the 5m collection in a couple of days (limitation is in
the source) w
; breaking it GC-wise.
>
> i'm going to try adding in System.gc() calls to see if this runs ok
> (albeit slower)...
> otherwise i'm pretty much at a loss as to what could be causing this GC
> issue/
> solr hanging if it's not a GC issue...
>
> thanks :)
>
Tri:
What is the volume of content (# of documents) and index size you are
expecting? What about the document complexity in terms of # of fields, what
are you storing in the index, complexity of the queries etc?
We have used SOLR with 10m documents with 1-3 second response times on the
front end
Michael,
The cutoff filter would be very useful for us as well. We want to use
it for more like this feature where only the top n similar docs tend
to be reallt similar.
On 5/4/10, Michael Kuhlmann wrote:
> Am 03.05.2010 23:32, schrieb Satish Kumar:
>> Hi,
>>
>> Can someone give clues on how to
We are using SOLR in a production setup with a jRuby on Rails front end
with about 20 different instances of SOLR running on heavy duty hardware.
The setup is load balanced front end (jRoR) on a pair of machines and the
SOLR backends on a different machine. We have plenty of memory and CPU and
th
Another approach would be to do query time boosts of 'my' items under
the assumption that count is limited:
- keep the SOLR index independent of bought/like
- have a db table with user prefs on a per item basis
- at query time, specify boosts for 'my items' items
We are planning to do this in the
In our specific case, we would get the user's folders and then do a
function query that provides a boost if the document.folder is in {my
folder list}.
Another approach that will work for our intranet use is to add the
userids in a multi-valued field as others have suggested.
On 5/20/10, MitchK
it scale if users already favorited/liked hundreds of item? The query
> can be quite long.
>
> Looking forward to your idea.
>
>
>
> On Thu, May 20, 2010 at 6:37 PM, dc tech wrote:
>
>> Another approach would be to do query time boosts of 'my' items under
>
We are evaluating using nested documents vs. simply flattening the document.
Looking through the documentation, it is not very clear to me if the nested
documents are fully mature, and support the full richness of SOLR
(streaming, mature faceting) etc...
Any opinions or guidance on that?
For *
with than flattened docs.
>
> Best,
> Erick
>
> On Tue, Mar 6, 2018 at 6:48 AM, Dc Tech wrote:
> > We are evaluating using nested documents vs. simply flattening the
> document.
> >
> > Looking through the documentation, it is not very clear to me if the
> nested
I am SOLR fant and had implemented it in our company over 10 years ago.
I moved away from that role and the new search team in the meanwhile
implemented a proprietary (and expensive) nosql style search engine. That
the project did not go well, and now I am back to project and reviewing the
technolo
the other. Or maybe after that exercise you are still wondering
> what to choose, in which case you just follow your gut feeling and make a
> choice :)
>
> Jan
>
>> 15. jan. 2020 kl. 10:07 skrev Charlie Hull :
>>
>>> On 15/01/2020 04:02, Dc Tech wrote:
&g
26 matches
Mail list logo
