Hello, Ramo.
There would be 2 reasons why SOLR is slower than PG
1. SOLR is not built from the ground up for spatial queries - eg. it
stores spatial data as WKT strings (although maybe it transforms them to
something more efficient behind the scenes? - I don't know)
2. The transfer of the results from SOLR to Geoserver is probably less
efficient than from PG - but we have chosen a binary format for data
transfer, so that is as good as it can be
Despite the above, we have tested with queries that return tens of
thousands of results, and the system works nicely. Best of course, if SOLR
and Geoserver are situated close together.
Another performance enhancement we have made with the SOLR module, is that
if you are doing a spatial search using polygons/multipolygons in SOLR, you
can choose to return only the centroids of the polygons - of course this
reduces the size of the returned data - and often this is all you want on
the map, particularly if the polygons overlap and make a big mess on the
map.
Another general hint for doing spatial searches in SOLR .. if you have
polygons with hundreds or thousands of vertices, consider SIMPLIFYING the
polygons - ie. reducing the number of vertices, making the shapes coarser -
the search will be much more efficient.
And the answer to your final question - yes - you will only hookup
Geoserver to SOLR if you want to do powerful text-based searches (ie.
google-style searches) on wordy data that is spatially located. For
example, you have a document management system containing thousands of
reports (or more) and each report is assigned a location - then you copy
all the words from the reports and the locations of the reports into SOLR -
then you can search for any word or phrase in any report and using
Geoserver and the SOLR module, see where these reports cluster on a map -
potentially quite powerful.
​Regards,
David​
On Thu, Mar 12, 2015 at 8:09 PM, Tobias Reinicke <ramot...@gmail.com> wrote:
> Hi David,
>
> Many thanks - that's some great info - if I may pry though - why is the
> spatial search of SOLR not as good as PostGIS (as I don't know SOLR much I
> don't know what to expect :) ) - I presume it's along the lines of PG has
> better spatial indexes (indicies?)?
> If so, that pretty much answers my question; that there is very little
> point in trying to replace my PG with a SOLR backend for WMS rendering
> purposes. Would that be a right assumption?
>
> Thanks again,
>
> Ramo
>
> On 11 March 2015 at 22:31, David Collins <david.8.coll...@gmail.com>
> wrote:
>
>> Hello, Ramo.
>>
>> Andre Aime is more expert than me, but I can tell you a few things.
>>
>> Yes, the spatial data does need to be stored in SOLR as a WKT string.
>> SOLR has its own spatial search capability and this capability is utilized
>> by the SOLR module.
>> If you can get your shapes/points into PostGIS, you should be able to
>> create the WKT strings fairly easily -
>> http://postgis.refractions.net/documentation/manual-1.4/ST_AsText.html
>>
>> The performance of the spatial search in SOLR is not as good as in
>> PostGIS - as you probably would expect - but it is still quite good.
>>
>> The main idea of the module is to be able to plot the results of any 'q',
>> 'fq' search in a SOLR store - ie. run very powerful text-based searches -
>> and then plot the results efficiently - particularly important if your
>> search is returning large numbers of results.
>>
>> Regards,
>> David Collins
>> Geological Survey of NSW, Australia.
>>
>>
>> On Wed, Mar 11, 2015 at 8:55 PM, Tobias Reinicke <ramot...@gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I see that there is a SOLR backend community module available to use,
>>> which I find quite interesting and was wondering two things;
>>> How does the performance compare between SOLR and say Postgres/gis?
>>> How do I load GML into SOLR?
>>>
>>> I've been looking at
>>> https://cwiki.apache.org/confluence/display/solr/Spatial+Search and it
>>> says to use WKT - is that really the best way of doing things?
>>>
>>> Any help would be much appreciated.
>>>
>>> Regards,
>>> Ramo
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Geoserver-users mailing list
>>> Geoserver-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>
>>>
>>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
