Discussion :

[livingdead]

Voila tout est dans le sujet ?

Est ce que cela existe?

Ou y a t'il des solutions performantes, qui aurait le meme résultat?

cordialement

[kryskool]

Peu tu m'expliquer comment tu vas faire pour mettre un moteur de porsche dans un voiturette, si tu veux faire de la réplication fais plutot

PostgreSQL Master -> PostgreSQL Slave (tu peux avoir plusieurs slave)

c'est beaucoup plus logique, et pour cela tu peut utiliser Slony 1.

KrysKool

[livingdead]

Pour les réponses creuses. J'ai pas besoins d'aide.

J'ai poser une question.

Et j'aimerais une réponse en rapport.

Maintenant je comprend que certains est des visions incomplétes et limité, mais avant de parler il est bien plus intelligent de ce documenter.

cordialement

Livingdead

[kryskool]

Pour les réponses creuses. J'ai pas besoins d'aide.

Je pourrais dire A question creuse, réponse creuse, mais intellectuellement parlant cela serait trop facile. Donc je vais détailler.

J'ai poser une question.
Et j'aimerais une réponse en rapport.

Et j'y est répondus par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PostgreSQL Master -> PostgreSQL Slave (tu peux avoir plusieurs slave)
c'est beaucoup plus logique, et pour cela tu peut utiliser Slony 1.

Mais peut être il faudrait comprendre ce que veux dire Réplication. cf dictionnaire.

Donc non la réplication PostgreSQL->MySQL n'est pas possible.
Tu peut via un script recopier les tables et leur contenus, c'est tous ce qu'il est possible de faire.

Maintenant je comprend que certains est des visions incomplétes et limité, mais avant de parler il est bien plus intelligent de ce documenter.

J'ai travaillé longtemp avec MySQL et en parallèle avec PostgreSQL, J'ai laissé tomber MySQL car pas de procédure stockée et de trigger, Je connait par consequent, assez bien les 2 produits, je connais également le sens du mot réplication.

Peut être que le terme voiturette n'était pas tous a fais approprier, mais c'est une image.

Amicalement.

KrysKool

[livingdead]

Merci pour cet éclaircissement.

Puisqu'il semble que tu connaisses le sujet, je précise que j'ai des besoins d'insertion en masse et quasiement silmutanément.

Il est vrai que postgres est beaucoup plus avancé, c pour cela que c la solution en Master que j'ai choisi.

Parcontre en temps d'execution d'insertion, il y a environ 5 ms de différence sur les bench entre mysql et postgres, et ceci en utilisant les tables MyIsam de mysql. Autant dire que dans ma solution je souhaitais utiliser des tables HEAP memory. Ce qui devrait permettre de record en temps d'insertion.

Je ne souhaiter donc pas du tout utiliser mysql pour les traitements mais utiliser au maximum ces performances.

Donc comme voiturette dans cette explication mysql est une ferrari, et postgresql une rolls.

Je n'ai malheureusement pas les moyens de me payer un Oracle, ni meme peut etre les compétences qui vont avec pour l'optimiser et avoir les memes ordres de résultats.

J'ai effectivement pensée a un cron pour faire la synchronisation manuellement, mais une solution sécurisé de synchronisation avancé m'aurais bien pplus.

En plus j'ai un vague souvenir d'avoir vu dans une discussion un solution pour faire cela. Mais je ne la retrouve plus cela faisait plusieurs mois.

Amicalement

Livingdead

[kryskool]

Puisqu'il semble que tu connaisses le sujet, je précise que j'ai des besoins d'insertion en masse et quasiement silmutanément.

Pour des insertions en masse je te conseille fortement d'utiliser la fonction COPY au lieu des INSERT, qui donne de meilleur performance.

Maintenant avec l'utilisation des tablespaces, si tu es en version 8.0.x tu peut crée un tablespace sur un disque dédié, et y mettre la table qui a fais des insertions multiple dessus; (c'est une des options possibles de tuning)

Je ne souhaiter donc pas du tout utiliser mysql pour les traitements mais utiliser au maximum ces performances.

essaye les quelques options de tunning qui existent, et utilise PG avec plusieur Teraoctet de données, avec des insertions multiple.

Donc comme voiturette dans cette explication mysql est une ferrari, et postgresql une rolls.

Oui c'est peut être une ferrari, mais plus on va vite et plus la distance parcouru est courte (capacité réservoir), Je ne sais pas combien tu as de tuples tu as dans ta base, mais j'aimerais bien que tu nous donne en retour des tests lorsques tu en as 100 a 10 000 Fois plus, Je pense qu'il n'y aura pas la même réactivité au fur à mesure du remplissage. Bien sur dans ce test, je ne veux pas voir que les résultat de MySQL, mais également ceux de PG (Pour comparaison).

J'ai effectivement pensée a un cron pour faire la synchronisation manuellement, mais une solution sécurisé de synchronisation avancé m'aurais bien pplus.

Si après le tuning du serveur PG tu as de bonne performance, il ne te reste qu'a utiliser la réplication avec Slony 1 par exemple.


J'espère avoir levé quelques ambiguité, et bonne continuation avec PG

Cordialement.

KrysKool

[livingdead]

Effectivement je pense que ta remarque a propos du temps de reaction de mysql en fonction de son volume est exacte.

Mais c pour cela que je parlais de l'utilisation de table HEAP. Les tables HEAP ne garde aucune donnée, ce sont des tables mémoires, qui ce vide lorsque le serveur est éteint par exemple.

Le but du jeu étant de faire un tampon avec mysql vraiment rien que pour loguer en faite les informations de tracking (tracking visé a 6 mois 1 000 000 track par jour). Et de les vider tout les x time.

et je pense que toute solution incluant de l'écriture IO aura du mal a suivre, sauf peut etre avec des disques SCSC 160.

En tout cas je te remercie pour les références que je vais aller consulter de ce pas.