SIG: PostGIS / PostgreSQL vs MySql vs SQL Server?
EDIT: j'utilise Postgres avec PostGIS depuis quelques mois maintenant, et je suis satisfait.
J'ai besoin d'analyser quelques millions d'enregistrements géocodés, dont chacun aura la latitude et la longitude. Ces enregistrements contiennent des données d'au moins trois types différents, et j'essaierai de voir si chaque ensemble influence l'autre.
Quelle base de données est la meilleure pour le magasin de données sous-jacent pour toutes ces données? Voici mes envies:
- Je connais le SGBD. Je suis le plus faible avec PostgreSQL, mais je suis prêt à savoir si tout le reste est vérifié.
- Cela fonctionne bien avec les requêtes SIG. Les recherches Google suggèrent que PostgreSQL + PostGIS est peut-être le plus puissant? Au moins, beaucoup de produits semblent l'utiliser. Les extensions spatiales de MySql semblent relativement minimes?
- Faible coût. Malgré la limite de 10 Go de base de données dans SQL Server Express 2008 R2, je ne suis pas sûr de vouloir vivre avec cela et d'autres limitations de la version gratuite.
- Pas antagoniste avec Microsoft .NET Framework. Grâce à Connector/Net 6.3.4, MySql fonctionne bien avec les programmes C # et .NET Framework 4. Il prend entièrement en charge Entity Framework de .NET 4. Je ne trouve aucun équivalent PostgreSQL non commercial, bien que je ne sois pas opposé au paiement de 180 $ pour dotConnect de Devart pour PostgreSQL Professional Edition.
- Compatible avec R. Il semble que tous les 3 puissent parler avec R en utilisant ODBC, donc ce n'est peut-être pas un problème.
J'ai déjà fait du développement en utilisant MySql, mais je peux changer si nécessaire.
Si vous êtes intéressé par une comparaison approfondie, je recommande "Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" and/or "Compare SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features " par Boston GIS.
Compte tenu de vos points:
- Je connais bien le SGBD: la configuration d'une base de données PostGIS sous Windows est facile, l'utilisation de la gestion PgAdmin3 est également très simple
- Il fonctionne bien avec les requêtes SIG: PostGIS est certainement le plus fort des trois, seul Oracle Spatial serait comparable mais est disqualifié si vous considérez ses coûts
- Faible coût: +1 pour PostGIS à coup sûr
- Pas antagoniste avec Microsoft .NET Framework: Vous devriez au moins pouvoir vous connecter via ODBC ( voir wiki Postgres )
- Compatible avec R: ne devrait pas être un problème avec l'un des trois
J'ai travaillé avec les trois bases de données et effectué des migrations entre elles, donc j'espère que je pourrai encore ajouter quelque chose à un ancien post. Il y a dix ans, j'ai été chargé de mettre un grand ensemble de données - 450 millions d'objets spatiaux - de GML dans une base de données spatiale. J'ai décidé d'essayer MySQL et Postgis, à l'époque il n'y avait pas d'espace dans SQL Server et nous avions une petite atmosphère de démarrage, donc MySQL semblait un bon choix. Par la suite, j'ai été impliqué dans MySQL, j'ai assisté/parlé à quelques conférences et j'ai été fortement impliqué dans les tests bêta des fonctions plus conformes aux SIG de MySQL qui a finalement été publié avec la version 5.5. J'ai ensuite participé à la migration de nos données spatiales vers Postgis et de nos données d'entreprise (avec des éléments spatiaux) vers SQL Server. Ce sont mes conclusions.
MySQL
1). Problèmes de stabilité. En 5 ans, nous avons eu plusieurs problèmes de corruption de base de données, qui ne pouvaient être résolus qu'en exécutant myismachk sur le fichier d'index, un processus qui peut prendre plus de 24 heures sur une table de 450 millions de lignes.
2). Jusqu'à récemment, seules les tables MyISAM prenaient en charge le type de données spatiales. Cela signifie que si vous souhaitez une assistance transactionnelle, vous n'avez pas de chance. Le type de table InnoDB prend désormais en charge les types spatiaux, mais pas les index sur ceux-ci, ce qui, compte tenu des tailles typiques des ensembles de données spatiales, n'est pas très utile. Voir http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Mon expérience en allant à des conférences était que l'espace était vraiment une réflexion après coup - nous avons implémenté la réplication, le partitionnement, etc., mais cela ne fonctionne pas avec spatial. EDIT: Dans la version 5.7.5 à venir InnoDB prendra enfin en charge les index sur les colonnes spatiales, ce qui signifie que ACID, les clés étrangères et les index spatiaux seront enfin disponibles dans le même moteur.
3). La fonctionnalité spatiale est extrêmement limitée par rapport à la fois à Postgis et à SQL Server spatial. Il n'y a toujours pas de fonction ST_Union qui agit sur un champ de géométrie entier, l'une des requêtes que j'exécute le plus souvent, c'est-à-dire que vous ne pouvez pas écrire:
select attribute, ST_Union(geom) from some_table group by some_attribute
ce qui est très utile dans un contexte SIG. Select ST_Union(geom1, const_geom) from some_table, c'est-à-dire que l'une des géométries est une géométrie constante codée en dur qui est un peu limitative en comparaison.
4). Aucun support pour les rasters. Être capable de faire une analyse combinée vecteur-raster dans une base de données est une fonctionnalité SIG très utile.
5). Pas de prise en charge pour la conversion d'un système de référence spatiale à un autre.
6). Depuis l'acquisition par Oracle, le spatial a vraiment été suspendu.
Dans l'ensemble, pour être juste envers MySQL, il a pris en charge notre site Web, WMS et le traitement spatial général pendant plusieurs années et a été facile à mettre en place. Sur le plan négatif, la corruption des données était un problème, et en étant forcé d'utiliser les tables MyISAM, vous abandonnez beaucoup des avantages d'un SGBDR.
Postgis
Compte tenu des problèmes que nous avons rencontrés avec MySQL, nous nous sommes finalement convertis à Postgis. Les points clés de cette expérience ont été.
1). Stabilité extrême. Aucune corruption de données en 5 ans et nous avons maintenant environ 25 boîtiers Postgres/SIG sur des machines virtuelles centos, sous différents degrés de charge.
2). Un rythme de développement rapide - raster, topologie, support 3D en sont des exemples récents.
3). Communauté très active. La chaîne et la liste de diffusion Postgis irc sont d'excellentes ressources. Le manuel de référence Postgis est également excellent. http://postgis.net/docs/manual-2.0/
4). Joue très bien avec d'autres applications, sous l'égide d'OSGeo, telles que GeoServer et GDAL.
5). Les procédures stockées peuvent être écrites dans de nombreux langages, à l'exception du plpgsql par défaut, tel que Python ou R.
5). Postgres est un SGBDR très conforme aux normes et complet, qui vise à rester proche des normes ANSI.
6). Prise en charge des fonctions de fenêtre et des requêtes récursives - pas dans MySQL, mais dans SQL Server. Cela a rendu l'écriture des requêtes spatiales plus complexes plus propre.
Serveur SQL.
Je n'ai utilisé que la fonctionnalité spatiale de SQL Server 2008, et bon nombre des inconvénients de cette version - le manque de prise en charge des conversions d'un CRS à un autre, la nécessité d'ajouter vos propres paramètres aux index spatiaux - ont maintenant été résolus.
1). Comme les objets spatiaux dans SQL Server sont essentiellement des objets CLR, la syntaxe est à l'envers. Au lieu de ST_Area (geom), vous écrivez geom.STArea () et cela devient encore plus évident lorsque vous enchaînez les fonctions ensemble. La suppression du trait de soulignement dans les noms de fonction n'est qu'une gêne mineure.
2). J'ai eu un certain nombre de polygones non valides qui ont été acceptés par SQL Server, et l'absence d'une fonction ST_MakeValid peut rendre cela un peu douloureux.
3). Windows uniquement. En général, les produits Microsoft (comme ceux d'ESRI) sont conçus pour fonctionner très bien les uns avec les autres, mais n'ont pas toujours la conformité aux normes et l'interopérabilité comme objectifs principaux. Si vous exécutez une boutique Windows uniquement, ce n'est pas un problème.
[~ # ~] mise à jour [~ # ~] : après avoir joué un peu avec SQL Server 2012, je peux dire qu'il a été considérablement amélioré. Il existe maintenant une bonne fonction de validation de la géométrie, il existe un bon support pour le type de données Geography, y compris un objet FULL GLOBE, qui permet de représenter des objets qui occupent plus d'un hémisphère et de prendre en charge Courbes composées et chaînes circulaires ce qui est utile pour des représentations précises et compactes d'arcs (et de cercles) entre autres. La transformation des coordonnées d'un CRS à un autre doit encore être effectuée dans des bibliothèques tierces, bien que ce ne soit pas un arrêt dans la plupart des applications.
Je n'ai pas utilisé SQL Server avec des ensembles de données assez grands pour les comparer un à un avec Postgis/MySQL, mais d'après ce que j'ai vu les fonctions se comporter correctement, et bien que pas aussi complet que Postgis, c'est une énorme amélioration par rapport aux offres de MySQL .
Désolé pour une réponse aussi longue, j'espère qu'une partie de la douleur et de la joie que j'ai subies au fil des ans pourrait aider quelqu'un.
PostGis définitivement. Voici pourquoi.
- Postgres est de loin supérieur à MySQL en termes de performances. Le serveur est plus tolérant aux pannes, dispose d'outils prêts à l'emploi pour l'équilibrage de charge, la mise en cache et l'optimisation.
- PostGIS devient une norme dans les applications SIG.
- C'est gratuit.
PostGIS est le meilleur car il devient de nos jours un standard dans les applications SIG et PostGIS est gratuit. Il est de loin supérieur à MySQL en termes de performances
Juste une note que MySQL a finalement ajouté dans la logique SIG appropriée.
Mais je ne peux pas commenter le coût ou la performance à ce stade