Pracowałem ze wszystkimi trzema bazami danych i przeprowadzałem migracje między nimi, więc mam nadzieję, że nadal będę mógł coś dodać do starego posta. Dziesięć lat temu otrzymałem zadanie umieszczenia obszernego -- 450 milionów obiektów przestrzennych -- zestawu danych z GML do przestrzennej bazy danych. Zdecydowałem się wypróbować MySQL i Postgis, w tamtym czasie w SQL Server nie było przestrzeni i mieliśmy małą atmosferę startową, więc MySQL wydawał się dobrze pasować. Później byłem zaangażowany w MySQL, uczestniczyłem/przemawiałem na kilku konferencjach i byłem mocno zaangażowany w beta-testy bardziej zgodnych z GIS funkcji w MySQL, które zostały ostatecznie wydane w wersji 5.5. Później byłem zaangażowany w migrację naszych danych przestrzennych do Postgis i naszych danych korporacyjnych (z elementami przestrzennymi) do SQL Server. To są moje ustalenia.
MySQL
1). Problemy ze stabilnością. W ciągu 5 lat mieliśmy kilka problemów z uszkodzeniem bazy danych, które można było naprawić tylko poprzez uruchomienie myismachk na pliku indeksu, procesu, który może zająć znacznie ponad 24 godziny w przypadku tabeli zawierającej 450 milionów wierszy.
2). Do niedawna tylko tabele MyISAM obsługiwały typ danych przestrzennych. Oznacza to, że jeśli chcesz wsparcia transakcji, nie masz szczęścia. Typ tabeli InnoDB obsługuje teraz typy przestrzenne, ale nie indeksy na nich, co biorąc pod uwagę typowe rozmiary zestawów danych przestrzennych, nie jest zbyt przydatne. Zobacz http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Moje doświadczenie z chodzenia na konferencje było takie, że przestrzenność była w dużej mierze przemyślana — zaimplementowaliśmy replikację, partycjonowanie itp. ale nie działa z przestrzennym.EDIT:W nadchodzącym wydaniu 5.7.5 InnoDB w końcu będzie obsługiwał indeksy w kolumnach przestrzennych, co oznacza, że ACID, klucze obce i indeksy przestrzenne będą wreszcie dostępne w tym samym silniku.
3). Funkcjonalność przestrzenna jest bardzo ograniczona w porównaniu z przestrzennymi Postgis i SQL Server. Nadal nie ma funkcji ST_Union, która działa na całe pole geometrii, jedno z najczęściej uruchamianych przeze mnie zapytań, tzn. nie można napisać:
select attribute, ST_Union(geom) from some_table group by some_attribute
co jest bardzo przydatne w kontekście GIS. Select ST_Union(geom1, const_geom) from some_table , tzn. jedna z geometrii jest zakodowaną na stałe geometrią, która w porównaniu z tym jest nieco ograniczająca.
4). Brak obsługi rastrów. Możliwość wykonywania połączonej analizy wektorowo-rastrowej w obrębie bazy danych jest bardzo przydatną funkcjonalnością GIS.
5). Brak obsługi konwersji z jednego przestrzennego układu odniesienia na inny.
6). Od czasu przejęcia przez Oracle, technologia przestrzenna została naprawdę wstrzymana.
Ogólnie rzecz biorąc, aby być uczciwym wobec MySQL, wspierał on naszą stronę internetową, WMS i ogólne przetwarzanie przestrzenne przez kilka lat i był łatwy w konfiguracji. Z drugiej strony, uszkodzenie danych było problemem, a zmuszając się do korzystania z tabel MyISAM, rezygnujesz z wielu korzyści płynących z RDBMS.
Postgi
Biorąc pod uwagę problemy, jakie mieliśmy z MySQL, ostatecznie przeszliśmy na Postgis. Kluczowymi punktami tego doświadczenia były.
1). Ekstremalna stabilność. Brak uszkodzeń danych od 5 lat, a teraz mamy około 25 skrzynek Postgres/GIS na maszynach wirtualnych centos, przy różnym stopniu obciążenia.
2). Szybkie tempo rozwoju – raster, topologia, obsługa 3D to ostatnie przykłady tego.
3). Bardzo aktywna społeczność. Kanał irc Postgis i lista mailingowa to doskonałe zasoby. Podręcznik referencyjny Postgis jest również doskonały. http://postgis.net/docs/manual-2.0/
4). Bardzo dobrze współpracuje z innymi aplikacjami pod parasolem OSGeo, takimi jak GeoServer i GDAL.
5). Procedury składowane mogą być napisane w wielu językach, z wyjątkiem domyślnego plpgsql, takiego jak Python czy R.
5). Postgres jest bardzo zgodnym ze standardami, w pełni funkcjonalnym RDBMS, który ma na celu pozostać blisko standardów ANSI.
6). Obsługa funkcji okien i zapytań rekurencyjnych — nie w MySQL, ale w SQL Server. Dzięki temu pisanie bardziej złożonych zapytań przestrzennych stało się czystsze.
Serwer SQL.
Korzystałem tylko z funkcji przestrzennej SQL Server 2008 i wiele niedogodności tej wersji – brak obsługi konwersji z jednego CRS na inny, konieczność dodawania własnych parametrów do indeksów przestrzennych – zostało już rozwiązanych.
1). Ponieważ obiekty przestrzenne w SQL Server są w zasadzie obiektami CLR, składnia wydaje się odwrotna. Zamiast ST_Area(geom) piszesz geom.STArea() i staje się to jeszcze bardziej oczywiste, gdy łączysz ze sobą funkcje. Upuszczenie podkreślenia w nazwach funkcji jest jedynie niewielką irytacją.
2). Miałem wiele nieprawidłowych wielokątów, które zostały zaakceptowane przez SQL Server, a brak funkcji ST_MakeValid może sprawić, że będzie to trochę bolesne.
3). Tylko Windows. Ogólnie rzecz biorąc, produkty firmy Microsoft (takie jak produkty ESRI) są zaprojektowane tak, aby bardzo dobrze ze sobą współpracowały, ale nie zawsze ich głównym celem jest zgodność ze standardami i interoperacyjność. Jeśli prowadzisz sklep tylko z oknami, nie stanowi to problemu.
AKTUALIZUJ :bawiąc się trochę z SQL Server 2012, mogę powiedzieć, że został znacznie ulepszony. Dostępna jest teraz dobra funkcja walidacji geometrii, istnieje dobre wsparcie dla typu danych Geography, w tym obiekt FULL GLOBE, który umożliwia reprezentowanie obiektów zajmujących więcej niż jedną półkulę oraz obsługę złożonych krzywych i Circular Strings, co jest przydatne do dokładnego i zwartego reprezentacje między innymi łuków (i okręgów). Przekształcanie współrzędnych z jednego CRS na inny nadal musi być wykonywane w bibliotekach innych firm, chociaż w większości aplikacji nie jest to przeszkodą w działaniu.
Nie używałem SQL Server z wystarczająco dużymi zestawami danych, aby porównać jeden do jednego z Postgis/MySQL, ale z tego, co widziałem, funkcje zachowują się poprawnie i chociaż nie są tak w pełni funkcjonalne jak Postgis, jest to ogromne ulepszenie oferty MySQL .
Przepraszam za tak długą odpowiedź, mam nadzieję, że część bólu i radości, których doświadczyłem przez lata, może komuś pomóc.
