Re: localsolr sort
Haven't tried the 14th build, but the latest stable version is available on http://www.nsshutdown.com/solr-example.tgz Built last week -- View this message in context: http://www.nabble.com/localsolr-sort-tp24040799p24065745.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Backups using Java-based Replication (forced snapshot)
Thinking the same last week, as I was tailoring the snapshooter.sh script.
The data directory should be kept for the temp snapshot, as a way to ensure
linking is occurring on the same device.
snapshooter.sh
87 name=${data_dir}/${snap_name}
I think only this needs to be configurable for the final move.
Grant Ingersoll-6 wrote:
>
> On the page http://wiki.apache.org/solr/SolrReplication, it says the
> following:
> "Force a snapshot on master.This is useful to take periodic
> backups .command : http://master_host:port/solr/replication?
> command=snapshoot"
>
> This then puts the snapshot under the data directory. Perfectly
> reasonable thing to do. However, is it possible to have it take in a
> directory location and store the snapshot there? For instance, I may
> want to have it write to a specific directory that is being watched
> for backup data.
>
> Thanks,
> Grant
>
>
> --
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
> using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
>
--
View this message in context:
http://www.nabble.com/Backups-using-Java-based-Replication-%28forced-snapshot%29-tp23434396p23447792.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Spatial search using R-tree for indexed bounding boxes
There are many spatial solutions out there - R-tree - Quad-Tree - SRID with positional proximity like geohash - Voronoi diagrams etc.. All have their pros & cons as do Cartesian grids. Feel free to contribute the more there are, the more solutions that can be applied to different problems, I use a Cartesian method meets my needs for my work which has a substantial data set. If you look at the LocalSolr implementation of LocalLucene you'll notice that there are multiple grids indexed at different levels / tiers. In a very similar fashion to Quad-Trees. The reason, you can 'zoom' in as low as you need to. There are multiple filters occurring for the geo filters in locallucene, first is an MMB based on bestFit or zoom level, then afterwards those results are filtered by your text intersection and finally by a radial filter. The MMB filter, pre-generates the shape or in this case box with all the id's you're interested in and using a TermEnumerator pulls those from the index. As the id's are stored in a sorted fashion it's a very fast retrieval. Without having to manage memory or a data structure outside of lucene. Storing multiple points is possible, doing a radial filter, or sorting on distance (which is what my work depends on) is tricky as I use FieldCache to retrieve actual points quickly. Multiple values in a field cache dont work. But I am looking at the Uninverted Field method of solr facets for that. You will have the same issue no matter what method you use, unless you don't care about distance. If you want to do something more complex like polygon's, you extend the Shape's class, and create either another MMB or convex hull method. Basically my belief is, that it's faster to find something if you know what your looking for. i.e. grid / box id's The bestFit method essentially lets you skip traversing and just get to the level you want. Pre-generate the id's used in a shape, and simply pull them out of the index. hossman wrote: > > > : Patrick (of local lucene fame) thinks it is possible to do extent > queries with > : the cartesian grid method -- essentially you select the "best fit" level > and > : cell, and that should be set for anything within the extent. The > advantage of > : this approach is that it is super-fast and scaleable. The disadvantage > is > : that it is only as accurate as the grid. > > i'm way out of my league on spatial search -- but couldn't you use the > grid method to whittle down the result space, and then do the computation > to determine if a true overlap exists? > > > -Hoss > > > -- View this message in context: http://www.nabble.com/Spatial-search-using-R-tree-for-indexed-bounding-boxes-tp22318859p22462731.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: LocalSolr distributed search
Hi Most of the localsolr / locallucene doc's are a little out of date I'll get to updating them soon the most relevant ones are on http://www.gissearch.com/ To use it in a distributed form, it should already be built into the trunk version Use the standard query component as your primary entry point and add the following parameters shards=host:port/solr_path,host2:port/solr_path,host3... shards.qt=geo //or whatever you've called it. The standard query component will then perform the distributed search, and aggregate the results. HTH Patrick Rajiv2 wrote: > > Hello, > > I'm currently using LocalSolr in my project and coming across some > issues with making the LocalSolrQueryComponent work w/ distributed search. > I'm using version LocalSolr 2.0 and Solr 1.3. Can someone point me in the > right direction on how to modify this component to work with Distributed > Search - there seems to be very little documentation on the local solr > website. > > Thanks, > Rajiv > -- View this message in context: http://www.nabble.com/LocalSolr-distributed-search-tp22091124p22103453.html Sent from the Solr - User mailing list archive at Nabble.com.
