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
Version imprimable
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
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
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
Je pourrais dire A question creuse, réponse creuse, mais intellectuellement parlant cela serait trop facile. Donc je vais détailler.Citation:
Pour les réponses creuses. J'ai pas besoins d'aide.
Et j'y est répondus par :Citation:
J'ai poser une question.
Et j'aimerais une réponse en rapport.
Mais peut être il faudrait comprendre ce que veux dire Réplication. cf dictionnaire.Code:
2
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.
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.Citation:
Maintenant je comprend que certains est des visions incomplétes et limité, mais avant de parler il est bien plus intelligent de ce documenter.
Peut être que le terme voiturette n'était pas tous a fais approprier, mais c'est une image.
Amicalement.
KrysKool
Merci pour cet éclaircissement. :hola:
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
Pour des insertions en masse je te conseille fortement d'utiliser la fonction COPY au lieu des INSERT, qui donne de meilleur performance.Citation:
Puisqu'il semble que tu connaisses le sujet, je précise que j'ai des besoins d'insertion en masse et quasiement silmutanément.
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)
essaye les quelques options de tunning qui existent, et utilise PG avec plusieur Teraoctet de données, avec des insertions multiple.Citation:
Je ne souhaiter donc pas du tout utiliser mysql pour les traitements mais utiliser au maximum ces performances.
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).Citation:
Donc comme voiturette dans cette explication mysql est une ferrari, et postgresql une rolls.
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.Citation:
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.
J'espère avoir levé quelques ambiguité, et bonne continuation avec PG
Cordialement.
KrysKool
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.