• [^] # Re: question bête

    Posté par . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 6. Dernière modification le 13 mars 2012 à 23:52.

    Pour avoir utilisé un SQL Server, Oracle, MySQL et PostgreSQL en entreprise (principalement pour de l'archivage—qui pourrait maintenant être fait avec du NoSQL), PostgreSQL domine largement dans les fonctionnalités pour le développeur, l'installation, la facilité de paramétrage, et l'absence de trop mauvaises surprises. Oracle domine pour la complexité, et l'impression de "savoir tout faire".

    il y a cependant quelque (gros) couacs dès que la volumétrie de la base augmente :

    • les backups complets sont bien mais on arrive vite à des problèmes de taille de la sauvegarde
    • difficulté de mettre en place des backups incrémentaux -> pas le même principe que le backup avec pgdump
    • pas de possibilité facile de sharding (le partitionnement des tables est faisable mais c'est purement manuel et ça fait un peu bricolage)
    • même avec auto-vacuum, on a des problèmes de bloat :
      • le niveau de "bloat" des tables nécessite (dans notre cas) une commande CLUSTER de temps en temps
      • le niveau de "bloat" des index nécessite (dans notre cas) une commande REINDEX de temps en temps
    • avec beaucoup de transactions par seconde (quelques milliers d'insertions par seconde dans mon cas) on tombe vite sur le problème du "transaction wraparound"
    • Il n'y a pas de CLUSTERED INDEX comme Oracle ou SQL Server (si on sauve principalement des données de type CLEF/CLEF/VALEUR, l'index prend presque autant d'espace que la table)

    Bref c'est bien mais il manque des trucs… mais grosso modo ça va dans la bonne direction.

    Un petit doc intéressant (nb: même si je ne sais pas comment elle fait pour avoir 400000 tables !)
    http://www.pgcon.org/2011/schedule/events/366.en.html