Migration de MySQL vers PostGreSQL

Salut à tous,

Poussé par le manque de Trigger sous MySQL 5.0 (ca tourne sur la béta 5.1) j'ai voulu passer en PostGreSQL... seulement je rencotre un problème de taille...

Deux mots clé ne sont pas géré par PostGreSQL :

• AUTO_INCREMENT
• UNSIGNED

Ca me pose un très gros problème car toutes mes tables ont un id qui est un int ou bigint non signé et en auto incrémentation ...

Je ne sais pas si quelqu'un a une solution ...

Y a pas de autoincrement, on utilise des sequences, qui sont en fait des compteurs (séparés des tables pour pouvoir être utilisés à plusieurs endroits si besoin).

Tu les utilises implicitement avec les types serial et bigserial (int et bigint respectivement). Dans ce cas, à la création de la table, pgsql va créer une séquence et mettre comme default value "SELECT NEXTVAL(lenomdelasequence)" au champ de type serial/bigserial.

Soit explicitement, en créant toi même ta sequence (CREATE SEQUENCE) et en mettant la bonne default value.


Edit: un peu plus complet.

Incrementation :

Serial types


Positif :

Ainsi à l'ensemble de ces types on peut associer le mot clé ZEROFILL pour compléter le nombre par des zeros jusqu'a avoir un affichage sur N chiffres où N est le nombre de chiffre du plus grand nombre positif du type sélectionné. Et on peut également fixer cette valeur de N en l'indiquant entre parenthèse.

Cliquez pour agrandir...

Source

Tu pourrais faire des benchs entre ton appli mysql et ton appli pgsql au passage ?

Il n'y a pas de solution logicielle qui permet de faire le passage ?

grosnours a dit:

Tu pourrais faire des benchs entre ton appli mysql et ton appli pgsql au passage ?

Cliquez pour agrandir...

L'appli en question n'est pas encore en production ... :-D
Actuellement j'ai 21 tables ... et l'analyse n'est pas encore finie ...

Je sens que les vues vont servir

=> Migrations vers postgresql : http://www.postgresql.org/docs/techdocs.3

Article intéressant : http://en.wikibooks.org/w/index.php?title=Programming:Converting_MySQL_to_PostgreSQL

Oui je suis aussi intéressé par les benchs.
On va migrer tout notre serveur webd de Mysql 4.1 à PostgreSQL 8.2 (le support des fonctions spatiales de PostGIS est indispensable).
Pour info, j'ai déjà migré toute la structure de la DB sans aucun problème. Je pense avoir utilisé un script en perl trouvé quelque part sur le web.
Ca ne marchait pas directement, mais après quelques retouches manuelles c'était nickel.

Edit : après vérif c'est le script mysql2pgsql sur la page envoyée par guslinux que j'ai utilisé.

J'ai tenté la chose, mais ca n'as pas l'air simple.
De plus j'utilise DBDesigner pour créer mes tables etc, et en plus de faire une nouvelle BD je devrais faire l'export vers PostGreSQL ...

De plus j'ai vu que MySQL 5.1 gérait les trigger... ce que je cherchais :-D

Mais je vais quand meme tenté la chose ... maintenant que j'ai un horaire plus light (TFE oblige ) je vais avoir du temps ... j'ai déjà la machine installée et configurée :-D

En tout cas, moi qui utilisait MySQL de manière passive depuis des années ... je commence à lui en demander de plus en plus :-D

Quel intéret de passer sur PostGreSQL ? plus de fonctions SQL gérée, plus proche du standard SQL ?

PostGreSQL me semble plus complexe à gerer par rapport à MySQL ...

guslinux a dit:

Quel intéret de passer sur PostGreSQL ? plus de fonctions SQL gérée, plus proche du standard SQL ?

PostGreSQL me semble plus complexe à gerer par rapport à MySQL ...

Cliquez pour agrandir...

Je crois que la simplicité de mysql n'est dûe qu'à l'habitude.
Au début PostgreSQL m'a un peu rebuté, mais pgAdmin (l'interface quasi-officielle de PosgreSQL) est très bien fait.

Ce qui me fait vraiment préférer PostgreSQL c'est la possibilité de choisir son langage procédural (Perl, Python, Java, PHP, ...).
Les types définis par l'utilisateur c'est vraiment bien aussi, mais ça existe peut-être dans MySQL, je sais pas.

En gros, PostgreSQL est vraiment plus puissant que MySQL car tout est presque configurable sur le serveur (même les opérateurs sont modifiables par l'utilisateur).

Bingo a dit:

Je crois que la simplicité de mysql n'est dûe qu'à l'habitude.
Au début PostgreSQL m'a un peu rebuté, mais pgAdmin (l'interface quasi-officielle de PosgreSQL) est très bien fait.

Ce qui me fait vraiment préférer PostgreSQL c'est la possibilité de choisir son langage procédural (Perl, Python, Java, PHP, ...).
Les types définis par l'utilisateur c'est vraiment bien aussi, mais ça existe peut-être dans MySQL, je sais pas.

En gros, PostgreSQL est vraiment plus puissant que MySQL car tout est presque configurable sur le serveur (même les opérateurs sont modifiables par l'utilisateur).

Cliquez pour agrandir...

En effet, au niveau MySQL on se cantonne souvent à des requetes SQL assé simples. Malgré une volonté de vouloir augmenter les fonctionnalités de la part de MySQL AB...

Je vais regarder à ca

J'utilise MySQL pour tout ce qui est assez simple (quelques tables, insert/select massifs, peu/pas d'update/delete, pas de fk, pas de vues, pas de transactions, pas trop grave si quelques données sont paumées) et PostgreSQL pour le reste.

J'ai jamais trop cherché à rendre MySQL plus "safe" (qu'il respecte les pk, qu'il tronque pas la valeur d'un champ sans m'en avertir, etc).
Par contre, je cherche comme accélérer PostgreSQL parce que jusqu'à présent, une requête sur une table de >100000 rows rame méchamment en pgsql.

Il existe des script/soft pour convertir des dumps normalement : ))

Au niveau des bench, je me suis un peu renseigné il y a qques temps. Pour une même requete, en général MySQL sera plus rapide. La reflexion à faire est de savoir si on va utiliser les fonctions spécifiques à PostgreSQL ou non. Dans des opérations complexes ou MySQL devra passer par plusieurs intermédiaires, PostgreSQL fera p-e tout d'une traite. PostgreSQL est beaucoup plus développé comme on l'a dit plus haut, je pense notament à l'héritage, les contraintes en tout genre, tout ce qui est script, les schémas, etc. Le modele relationnel peut changer d'un moteur à l'autre, grace a des fonctions comme l'héritage qui peuvent parfois bien aider. En résumé, d'apres ce que j'ai pu lire, si on n'utilise pas les fonctions de PostgreSQL, on y perd. Je pense qu'il ne faut pas avoir peur, que du contraire, de prendre le temps de bien faire le tour de ce qu'il est possible de faire avant de commencer un modèle.

grosnours a dit:

une requête sur une table de >100000 rows rame méchamment en pgsql.

Cliquez pour agrandir...

C'est quoi comme genre de requête ?
Je fais des requêtes spatiale sur des tables de plusieurs millions de lignes sans problème !

Un bête SELECT brol,SUM(truc),AVERAGE(bidule),COUNT(chose). Mais bon, avec le postgresql.conf par défaut, ça va jamais bien

grosnours a dit:

Un bête SELECT brol,SUM(truc),AVERAGE(bidule),COUNT(chose). Mais bon, avec le postgresql.conf par défaut, ça va jamais bien

Cliquez pour agrandir...

Ouep, il faut souvent paramètrer un peu plus finement.
Il faut aussi bien concevoir ses index, et surtout surtout ne pas oublier defaire un VACUUM ANALYZE sur la table, et d'en refaire de temps en temps si sont contenu change beaucoup !

Vui, le VACUUM FULL ANALYZE est quodienne, juste après le seul DELETE de la journée.
Les index sont créés à partir de l'output de EXPLAIN ANALYZE.
Les SELECT sont faits sur des tables fraiches (CREATE TABLE AS).

Les mêmes requêtes sur un mysql sont *beaucoup* plus rapides (10 à 50x plus rapides), malgré l'inexistence d'index et aucun "defrag" (optimize).

Restent deux causes possibles:
- postgresql n'est pas fait pour être rapide
- faut prendre le temps de configurer postgresql

Vous penchez tous comme moi pour la deuxième possibilité ?

grosnours a dit:

Vui, le VACUUM FULL ANALYZE est quodienne, juste après le seul DELETE de la journée.
Les index sont créés à partir de l'output de EXPLAIN ANALYZE.
Les SELECT sont faits sur des tables fraiches (CREATE TABLE AS).

Les mêmes requêtes sur un mysql sont *beaucoup* plus rapides (10 à 50x plus rapides), malgré l'inexistence d'index et aucun "defrag" (optimize).

Restent deux causes possibles:
- postgresql n'est pas fait pour être rapide
- faut prendre le temps de configurer postgresql

Vous penchez tous comme moi pour la deuxième possibilité ?

Cliquez pour agrandir...

Encore faut-il savoir que configurer ...
Ce que j'aimais bien avec MySQL c'est que en 1h grand max mon serveur était pret à fonctionner ...

Encore une fois, c'est une question habitude ... ca fais bientot 5ans que je joue avec MySQL, donc j'ai mes habitudes avec ce serveur :-D

Le tout est maintenant de prendre le meme genre d'habitude mais avec PostGreSQL ... l'étape ultime sera Oracle :-9

Je n'ai pas encore eu beaucoup d'occasion de tester (exams..). Mais 10 à 50x, c'est quand même beaucoup

Perso la première étape sera de me familiariser avec pgadmin ... car je suis totalement perdu dans ce soft ... MySQL Query Browser était plus simple

Shrekju a dit:

Je n'ai pas encore eu beaucoup d'occasion de tester (exams..). Mais 10 à 50x, c'est quand même beaucoup

Cliquez pour agrandir...

Beh oui, c'est même énorme quand tu vois la même requête, faite sur le même ensemble de données, prendre moins d'1sec en mysql et plus de 50 en postgres

D'où mon préférence pour mysql pour des trucs simples (des logs par exemple), où il n'y a quasi que des insert/select.