Temat: GeoServer i SQL Server - problemy z wydajnością

Mam dane zgromadzone w SQL Server. Geometria jako geometry, nieco danych opisowych.
Dane z SQL Servera są źródłem dla geoservera, który ma służyć jako wms.
Niestety wydajność tego połączenia jest tragiczna. Dane ciągnięte z shp to przy moim źródle danych błyskawica. Jeszcze bardziej zaskakujące jest to, że mam obecnie jakieś 8k poligonów w testowej tablicy i mimo to dostaję 'timeouty' z geoservera.

Wyczytałem gdzieś (posty sprzed roku), że źródło danych MS SQL Server dla geoservera jest mało wydajne i nie wykorzystuje metod spatial sql oferowanych przez sql server do wyciągania danych po AOI.

Stąd pytanie - czy ktoś z Was miał już podobną zagwozdkę i czy udało się problem rozsądnie rozwiązać.

Temat: GeoServer i SQL Server - problemy z wydajnością

Zauważyłem podobną sytuację w Mapserwerze. Geoservera niestety nie udało mi się skonfigurować tak by czytał dane z SQL Server 2008. Na stronie:

http://www.bostongis.com/?content_name=sql2008_tut01#181

znalazłem taką informację
WARNING: One of our friends noted that the SharpGIS Loader comes up with a very suboptimal spatial grid index that will throw of queries relying on a spatial index. This is particularly an issue for data loaded into the geometry planar data type. As a result, SQL Server queries may be unusually slow and you may get a bad impression of SQL Server's performance. This wil be fixed in a later version of the loader.

Nie wiem jak wczytywałeś dane do SQLServera. Ja użyłem właśnie SharpGIS Loader
i będe musiał sprawdzić czy to był problem.

Może jest ktoś komu działa SQL-Server wydajnie jako datasource.

Mam zamiar jeszcze przetestować MapGuide Opensource który korzysta z FDO.
Może tam sytuacja będzie lepsza.

Temat: GeoServer i SQL Server - problemy z wydajnością

Spatial index można zawsze przebudować. Też na początku myślałem, że to główny winowajca, ale zasadniczo dane z bazy powinny być pobierane dużo szybciej niż z plików typu shp. Nie udało mi się osiągnąć nawet połowy wydajności sql servera w porównaniu ze źródłem danych w postaci shp.

Od razu w kwestii wyjaśnienia - wina nie leży po stronie SQL Servera, ale nie leży też po stronie Geoservera...

A gdzie leży? Ano właśnie... Optymalizacji wymaga plugin geoserverowy do odczytu danych z SQL Servera. W chwili obecnej geoserver ciągnie dane geometryczne w postaci WKT. Różnica w czasie pobrania z servera geometrii binarnej, a geometrii przetworzonej do WKT jest kolosalna - ja zanotowałem w testach przyrost czasu rzędu 1000 - 2000% przy genrowaniu wkt względem wkb. To oczywiście zależy od ilości danych i stopnia ich komplikacji. Jeżeli pracujesz z wyższą wersją niż express odpal sobie profilera i zobacz o co pyta geoserver sql servera i zobacz jakie są różnice w czasie wykonania zapytania względem tego samego, ale bez przetwarzania geometrii do wkt.

A to dopiero pierwszy etap przetwarzania danych na linii sql server -> geoserver. W kolejnym geoserver musi przeparsować WKT do czegoś zrozumiałego dla siebie (niewykluczone, że geometrii w zapisie binarnym) i dopiero potem może przystąpić do renderowania (nie jestem pewien, czy robi najbierw batchowy odczyt geometrii, a potem renderowanie, czy może sekwencyjnie oczyt, renderowanie, odczyt, etc., ale filozofia działania jest pewnie mniej więcej taka)

Jeżeli nie masz profilera, to dla jakiegoś obszaru odpal sobie zapytanie najpierw w postaci mniej więcej takiej: DECLARE @bbox geometry; SET @bbox = STGeomFrom...; SELECT [geom] FROM [myTable] WHERE [geom].Filter(@bbox) = 1;
a potem SELECT [geom].ToString() i zobacz, jakie są różnice w czasie wykonania zapytania.

Przynajmniej pluging używa dużo szybszego Filter, zamiast STIntersetcs, jednak jak na tablicę nie jest założony index przestrzenny, to zamiast Filter wykonywany jest STIntersects. Różnica w wykorzystaniu Filter jest taka, że sprawdzenie odbywa się po spatial index, więc istnieje prawdopodobieństwo wybrania większej ilości rekordów niż powinno ich być - tzw. false positives, ale do celów takich jak wyrenderowanie kafelka przez wms to nie ma znaczenia.

Dla porównania obadaj sobie jakie opcje oferuje źródło danych PostGIS - tam możesz ciągnąć geometrię binarnie, albo jako wkt, jednak sugerowane jest pobieranie geometrii w postaci wkb, ponieważ jest szybsze.
Jeżeli możesz więc pozwolić sobie na zmianę bazy, to postaw postgisa. Albo podłub w pluginie ;-)

Temat: GeoServer i SQL Server - problemy z wydajnością

Co prawda nie rozumiem połowy z tego, co napisał przedmówca Dominik ;) ale natknąłem się w necie na takie testy wydajnościowe porównujące trzy źródełka, z których geoserver może ssać przestrzeń:

http://j2ee.pl/2011/06/22/geoserver-%E2%80%93-dane-prz...