[question] speed
Hi all I'm working on some presentation for my co-workers about Lucene/Solr index/search process. The question is why lucene (especially Solr) is such a fast engine? Has it something to do with index file formats (http://lucene.apache.org/java/docs/fileformats.html)? or is it all about using reverse indexing strategy? I'm have been digging into Lucene/Solr for nearly three month but only as an advanced user so I am not familiar with the details of engine implementation thank you Traut
Re: [question] speed
On 4/22/07, Traut <[EMAIL PROTECTED]> wrote: I'm working on some presentation for my co-workers about Lucene/Solr index/search process. The question is why lucene (especially Solr) is such a fast engine? I think some of it is the nature of open source. You have people who care, contributing patches to make things faster. There's no such thing as "well this meets requirements, now lets move on to the next feature checkbox". Has it something to do with index file formats (http://lucene.apache.org/java/docs/fileformats.html)? That's certainly the foundation. The scorers above that need to be fast too. or is it all about using reverse indexing strategy? AFAIK, full-text search products generally use an inverted index. So Solr is fast because Lucene is fast (and getting faster). Solr also adds a lot of smart configurable caching, and very fast set implementations that speed up filtering and faceting. -Yonik
Re: Facet Browsing
On 4/19/07, Mike Klaas <[EMAIL PROTECTED]> wrote: What if we made a policy of including a "added in version XX" to wiki documentation of features that aren't yet in a release? The XX could link to a page that includes a link to the nightly build and CHANGES.txt, or the release package for already-released versions. Seems like we should document it. I don't know if linking to the exact nightly build is worth the trouble though. If we document it in some consistent manner that can easily be searched, it would be easier to change after a release. -Yonik
Re: Facet Browsing
On 4/22/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: Seems like we should document it. I don't know if linking to the exact nightly build is worth the trouble though. If we document it in some consistent manner that can easily be searched, it would be easier to change after a release. Sounds good. If it is sufficiently unobstrusive, it probably isn't even necessary to change it later. -Mike
does solr handle updates quickly?
Hi, I'm new to Solr. I've just started playing around with it and learning what it can do. I'd like to include a vote field on all of my indexed documents. Users vote on the content they like. A vote tally is displayed along with the each document returned in the results of a search. Let's say I create a vote field of type SortableIntField. Users vote relatively frequently. Assume I send update commands to solr which change only the vote field approximately 1 time for every 50 searches a user performs. What effects will this have on my index? Will search performance degrade. Thanks, Tait
Re: snapshooter on OS X
What does your directory structure look like? The scripts assume that
all the scripts are in the bin directory which is under $solr_root.
So $solr_root is set to be two directory level up from where the
script is.
It turns the cp command in OS X and BSD can not be used to create hard links.
We will need to use the ln command instead.
Bill
On 4/21/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
Has anyone run the distribution scripts successfully on OS X? If so,
what did you have to change, if anything, to get them to work?
I'm getting a couple of issues in snapshooter:
1. The line . ${solr_root}/bin/scripts-util fails saying command not
found. This is presumably because solr_root is not being set
2. The cp command fails when trying to make the links b/c the -l
attributed does not seem to exist for the cp command on OS X
I am running bash 3.2.0 on 10.4.9
Thanks,
Grant
Re: snapshooter on OS X
I am using the solr home that comes with the example. The curious
thing is I get the error in item 1 when running on linux, as well.
The error says something about command not found line 15, but all the
files I looked at, line 15 was a comment. I _think_ it is referring
to an error in reading scripts.conf, but I am not sure.
I will put a bug in for the link issue for now and try to write up
some scripts that work on OS X after ApacheCon. I will also _try_ to
investigate the other issue when time permits. Should we have
separate directories under bin for different platforms or should we
try to have one script to rule them all?
On Apr 22, 2007, at 10:18 PM, Bill Au wrote:
What does your directory structure look like? The scripts assume that
all the scripts are in the bin directory which is under $solr_root.
So $solr_root is set to be two directory level up from where the
script is.
It turns the cp command in OS X and BSD can not be used to create
hard links.
We will need to use the ln command instead.
Bill
On 4/21/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
Has anyone run the distribution scripts successfully on OS X? If so,
what did you have to change, if anything, to get them to work?
I'm getting a couple of issues in snapshooter:
1. The line . ${solr_root}/bin/scripts-util fails saying command not
found. This is presumably because solr_root is not being set
2. The cp command fails when trying to make the links b/c the -l
attributed does not seem to exist for the cp command on OS X
I am running bash 3.2.0 on 10.4.9
Thanks,
Grant
Re: snapshooter on OS X
On 4/22/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote: Should we have separate directories under bin for different platforms or should we try to have one script to rule them all? I think we should try to keep the same scripts until it becomes too burdensome. -Yonik
Re: snapshooter on OS X
On 4/23/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote: ...The error says something about command not found line 15, but all the files I looked at, line 15 was a comment... Running your script with bash -x myscript should help, it will echo commands before executing them. -Bertrand
