PostgreSQL vs. MySQL: porównanie funkcji przestrzennych

Jesteśmy w trakcie tworzenia aplikacji internetowej, która zawiera komponent danych przestrzennych. Na początku nasze porównania danych przestrzennych przyjmą dany punkt i zwrócą dopasowane, nakładające się wielokąty przestrzenne.

To powiedziawszy, nasza baza danych zawiera wiele innych komponentów, które obejmują wszystkie typowe rzeczy, które można znaleźć w ogólnej relacyjnej bazie danych.

Jesteśmy w punkcie naszego projektu, w którym musimy wybrać, którego rozwiązania bazy danych użyć.

Wszyscy członkowie projektu są bardziej zaznajomieni z wdrażaniem i administrowaniem MySQL, jednak wszystkie badania sugerują, że PostgreSQL jest lepszym rozwiązaniem - szczególnie w odniesieniu do danych przestrzennych korzystających z PostGIS.

Oczekujemy (mamy nadzieję), że nasza aplikacja doświadczy wielu działań z wieloma współbieżnymi użytkownikami.

Czy ktoś z doświadczeniem w używaniu MySQL jako RDBMS z komponentem danych przestrzennych ma jakieś długoterminowe porady / doświadczenia?

Czy są jakieś wady korzystania z PostGIS, z wyjątkiem znajomości?

Nie mogę mówić o zaletach / wadach w stosunku do MySQL, ale kod PostGIS jest dość powszechnie uważany za jeden z najlepszych (pod względem szybkości / funkcjonalności) i najbardziej dojrzały (pod względem testowania / ekspozycji w świecie rzeczywistym) ) dostępny.

Przykładowo na PGEast 2010 rozmawiali niektórzy ludzie z FAA na temat konwersji bazy danych na lotniskach (wykorzystywanej przez AeroNav i innych do kompilacji map) na Postgres / PostGIS od Oracle.
Strona avationDB jest również zbudowana na Postgresie (8.0).

Jeśli zapytania związane z GIS są w centrum tego, co robisz, sugeruję skorzystanie z Postgres. Z pewnością poradzi sobie również ze wszystkim, co normalnie zrobiłbyś w relacyjnej bazie danych.

Jeśli chodzi o przejście z MySQL, dokumentacja Postgres jest pierwszorzędna, a także część Wiki Oostgres na temat przejścia z MySQL na Postgres .
Początkowa krzywa uczenia się może być nieco stroma i może być konieczne dostosowanie bazy danych i dowolnych procedur przechowywanych (jeśli już je napisałeś dla MySQL), ale nie jest to zadanie nie do pokonania.

Powinieneś być w stanie zebrać wystarczająco dużo, aby dokonać zmiany w ciągu kilku tygodni, a jeśli skonfigurujesz programistyczną bazę danych, prawdopodobnie będziesz w stanie dobrze zapoznać się z rutynowymi zadaniami w ciągu miesiąca i mieć pewność, że wiesz, gdzie szukać w instrukcji dla niezbyt rutynowych.

Mówiąc o kilku bardzo ważnych rzeczach. Oto lista rzeczy, które obsługuje PostGIS, które są całkowicie nieobecne w MySQL i MariaDB.

• SRID w obliczeniach, nadaj swoim punktom inny SRID, a otrzymasz z powrotem różne wartości. To jest propozycja funkcji agregujących: według mojej najlepszej wiedzy MySQL nie oferuje funkcji agregacji przestrzennej

K najbliższy sąsiad: tylko PostGIS obsługuje KNN. Znajdź najbliższy punkt do dowolnego punktu za pomocą tylko indeksu: nie musisz obliczać odległości od wszystkich punktów! Er. MySQL łamie specyfikację i sprawdza tylko, czy dwie wartości mają ten sam SRID. PostGIS jest wyposażony w bazę danych definicji pro4j, aby umożliwić bezproblemową świadomość SRID. Ustawienie SRID i wywołanie ST_Transform( funkcja, której brakuje MySQL ) spowoduje ponowne przesunięcie współrzędnych.

W MySQL wszystkie obliczenia są wykonywane przy założeniu SRID 0, niezależnie od rzeczywistej wartości SRID. SRID 0 reprezentuje nieskończoną płaską płaszczyznę kartezjańską bez jednostek przypisanych do jej osi. W przyszłości obliczenia mogą wykorzystywać określone wartości SRID. Aby zapewnić zachowanie SRID 0, utwórz wartości geometrii za pomocą SRID 0. SRID 0 jest domyślny dla nowych wartości geometrii, jeśli nie określono SRID.

• Rastry : jest tu mnóstwo funkcji, od generacji rastra do ekstrakcji. Możesz generować mapy cieplne i tym podobne.

• Geografia , PostGIS obsługuje nieproszony typ geograficzny, który w ogóle nie korzysta z matematyki kartezjańskiej. Ma całą powolność powiązanych funkcji, które działają na spłaszczonych sferoidach. Z drugiej strony MySQL nie może nawet utworzyć obwiedni w geograficznym SRS z dwóch punktów.

• Topologia , inna niż geometrie wektorowe, topo geomy przechowują węzły i relacje. Przesuń węzeł, krawędź również się przesunie i pojawi się nowa twarz. Wymusza to również ukierunkowanie krawędzi, co czyni je idealnymi do trasowania. Jako podpunkt 100% tego, co robi PgRouting , jest niedostępne dla MySQL - więc po prostu nie można na nim tworzyć Map Google ani podobnych.

• Geokodowanie: w katalogu contrib znajduje się rozszerzenie geokodera, które działa na danych spisu, oraz moduł ładujący do zainstalowania tych danych.

• Standaryzacja adresu: istnieje rozszerzenie, które obsługuje normalizowanie adresów w celu łatwego parsowania, przechowywania i porównywania.

• Funkcje SQL-MM , których po prostu nie znajdzieszCIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVE ani MULTISURFACEw MySQL.

• i przewody: PostGIS może obsługiwać kształty 3dm, 3dz i 4d oraz punkty, których MySQL po prostu nie może

• MySQL obsługuje tylko indeksy r-drzewa. PostGIS obsługuje r-tree (gist / gin) i BRIN (dla dużych tabel geometrii)

• Funkcje agregujące: według mojej najlepszej wiedzy MySQL nie oferuje funkcji agregacji przestrzennej

• K najbliższy sąsiad: tylko PostGIS obsługuje KNN . Znajdź najbliższy punkt do dowolnego punktu za pomocą tylko indeksu: nie musisz obliczać odległości od wszystkich punktów!

• Indeksowanie PostgreSQL pozwala przechowywać dowolne dane w indeksie przestrzennym (który jest indeksem gist / gin). Na przykład możesz przechowywać year(lub inne dane nieprzestrzenne) i geomten sam indeks. Zobacz btree_ginibtree_gist więcej informacji, jak to zrobić.

Są też prawdopodobnie PostGIS obsługuje 200 dodatkowych funkcji .

Krótko mówiąc, MySQL nie trzyma się PostGIS i wie o tym. PostGIS to bestia. Chciałem tylko wyjaśnić niektóre z tych rzeczy.

Całkowicie zgadzam się ze wszystkimi stwierdzeniami pierwszej odpowiedzi, ale dzieląc się własnym doświadczeniem - zrobiłem to na Krajowej Administracji Dróg w moim kraju: krytyk produkcji, strona o dużym natężeniu ruchu. Sugeruję, aby aplikacja internetowa była zasilana zarówno przez MySQL, jak i PostgreSQL / PostGIS.

W przypadku wszystkich „typowych” rzeczy aplikacja internetowa działa bezbłędnie z systemem CMS opartym na MySQL. W przypadku wszystkich zadań przestrzennych ta sama aplikacja internetowa działa również bezbłędnie;) z niestandardowym programowaniem opartym na PostgreSQL / PostGIS. Pierwszy komponent został opracowany i jest obsługiwany bez wysiłku przy normalnych umiejętnościach MySQL. Drugi komponent wymagał nieco więcej wysiłku badawczego na początku.

Nie musisz wymuszać kosztownej całej implementacji typowych rzeczy w mało znanym PostgreSQL / PostGIS i nie musisz wymuszać suboptymalnej implementacji danych geoprzestrzennych w MySQL. Niech każdy gracz gra tam, gdzie może trafić.