Vous n'êtes pas identifié(e).
Bonjour,
Il ne me semble pas avoir trouvé de discussion sur ce sujet.
J'ai une problématique simple sur une application :
- Une DB "mère" dans laquelle se retrouve des infos "globales"
- Une DB par client. Chaque DB client est identique.Ma question est donc simple. D'un point de vue performance vaut-il mieux une DB avec un schema public par client, ou une seule DB avec un schema par client ?
D'un point de vue montée en charge des données sur un schema, quel serait l'impact sur les autres schema puisqu'ils seraient dans la même DB ?Après plusieurs recherches sur internet, ça reste assez vague... Une idée globale semble sortir tout de même, la méthode multiple DB est "ancienne", alors que la multiple schema est "moderne".
Mais rarement de discussion sur les performances.
Merci par avance,
Vous n'avez pas bien cherché : Une seule base de données ou plusieurs ?
De plus PostGreSQL n'est pas multibase dans le sens ou il n'est pas possible de faire des requêtes (SELECT, INSERT, UPDATE, DELETE) facilement entre différentes bases (il faut passer par des db_link) et encore moins des transactions entre différentes bases...
Enfin la catastrophe arrive si vous considérez le point de vue des sauvegardes/restauration. En effet rien ne permet der synchroniser la sauvegardes des différentes bases, ce qui fait qu'à la restauration vous pouvez avoir des factures sans client, des lignes de commande sans commande.....
A +
Pouvez vous récrire votre requête en isolant les parties agrégées/clef des données non clef et en rajoutant les données non clef en liant avec la clef en final ?
Si vous ne me comprenez pas, donnez le DDL de vos tables / vues et on vous la récrira.
A +
en tout cas, de ce que je comprends de votre explication, vos clés secondaires n'ont aucune existence du côté du SGBD. C'est juste une clé unique, qui est proche d'une clé primaire mais pas identique.
Oui c'est bien ça ! Dans un ouvrage que j'ai lu il déclarer les clés secondaire à l'aide du mot clé "UNIQUE" mais je ne sais pas si cette même notion est repris dans PostgreSql. Certains SGBDR y dépose un index non nécessairement unique ce qui reviens à ce que vous avez compris.
La notion de clef secondaire n'existe pas; On parle de :
clef primaire (NOT NULL et UNIQUE)
clef alternative ou subrogée (UNIQUE et NULLable)
A +
De mémoire, la vitesse de correction des bugs de MS est de moins de 3 mois. Le faible nombre de bugs, comme la rapidité de correction est le fait du Microsoft's Secure Development Lifecycle, une méthodologie destinée à aider les développeurs de MS à construire des systèmes plus résilients et naturellement plus fiables. À l'époque de 2005, l'équipe de test était constitué d'une quinzaine de personne, mais surtout de plus de 160 machines de tests et le système tournait toutes les nuits pour rendre le résultat le matin aux équipes...
Le pire bugs en durée de correction avait été des télescopages de clef auto-incrémentées lorsque le nombre de requête d'insertion simultanées dans la même table dépassait le nombre de cœurs pour des machines de plus de 64 cœurs et lorsque la requête est parallélisée.... pas le genre de bugs que l'on risque de trouver sur PG qui ne sait pas faire des requête parallélisées !
Je trouve le site de publication/correction des bugs de MS (connect), nettement mieux fait et plus pratique que ce que propose PG avec sa liste... ! La preuve, c'est que je m'y suis trompé et on me l'a reproché !!!
L'étude de Coverity m'avait beaucoup fait rire, car c'est un spécialiste de l'open source (slogan : "Coverity Scan: free code analysis service for open source developers"), n'ayant visiblement aucune compétence, dans le code MS ou autre (IBM par exemple)... Et qui trouve bon ce qu'il sait auditer et pas le reste !!! vraiment de quoi se marrer !!!!
Mais pourquoi parle-t-on toujours de bug ? Le problème de base est lié à une limitation
NON ! Quelque chose qui renvoie une erreur alors qu'il n'y a pas lieu c'est un bug.
A +
Bonsoir,
Ce n'est pas comme s'il n'y avait pas de bug sous SQL Server.
Voici un topic qui détaille un problème majeur que j'ai rencontré avec SQL Server 2005 :
http://www.developpez.net/forums/d11183 … -bug-like/Il ne s'agit même pas d'un FULL JOIN, mais du pauvre opérateur LIKE...
Je préfère de loin avoir un SGBDR gratuit qui m'avertit ne pas gérer une fonctionnalité, qu'un SGBDR payant qui me sort des conneries.
En ce qui concerne la bug list de SQL Server, on peut lire sur internet :
Microsoft doesn't really keep a public list of open bugs. The ones that are the most important (e.g. anything involving security) are kept private for obvious reasons - they actually aren't published until they are fixed (and even then they often remain private).
Source : http://dba.stackexchange.com/questions/ … er-sp4-cu4
Le nombre de bug de SQL Server est bien moindre, tous moteurs confondus (SQL Server contient un ETL de nom SSIS, un moteur de stockage décisionnel en plus du relationnel, des outils de data mining et de formation de datamart SSAS, des outils de reporting SSRS et de très nombreux outils de maintenance, audit et admin......etc.) que ceux de PG... SQL Server compte à peu près 30 fois plus de code que PG, pour juste 20 fois moins de bug... Lisez les métriques du NIST par exemple sur les vulnérabilités... N'avez vous pas eu récemment une vulnérabilité importante sur PG récemment ? Depuis 2010, 26 vulnérabilités ont été recensées dans PG (http://www.postgresql.org/support/security/) contre 5 dans SQL Server (source NIST)... Comparez au volume de code, cela fait donc 150 fois plus de problème relativement dans PG que dans SQL Server... une toute petite paille !
A +
Comme vos données ne sont pas calées sur un pas de temps spécifique, le mieux est de créer une table de chronodatation avec le ou les pas demandés la mettre en PK et faire une jointure dessus en RIGHT OUTER JOIN. Ensuite c'est du SUM / GROUP BY.
A +
Oh, soit. Vous n'étiez pas obligé de savoir que pgsql-bugs est une liste de diffusion...
Ceci dit, notez que Tom Lane vous a répondu avec cette liste en copie et non en privé:
je tenais aussi à signaler que lorsque j'ai posté le bug dans la liste celui-ci n'a pas été publié... Peut être une modération à priori.. Ok, mais par exemple dans Microsoft Connect, il n'y a pas de modération (PostGreSQL aurait-il il des choses à cacher ???). Certes, il faut se faire reconnaître préalablement chhez MS, mais cela ne prends que quelques secondes...
Raisons pour laquelle j'ai ignoré la liste :
1) par le fait que le mail m'ait été adressé personnellement
2) parce que celui ci n'étais pas diffusé sur la liste au moment ou je suis aller y regardé.
3) mon client de messagerie, ne propose par par défaut l'option inclus donc le mail dans la liste de diffusion... (c'est d'ailleurs un outil Free : Mozilla !!!!! va falloir que je change pour OutLook...)
Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ?
Ce midi, oui, et je fais le même constat que lui....
Comme je n'ais pas d'autres commentaires et que je gâche du temps à répondre à vos inepties...
Disons que face à votre non contribution, je me posais bien des questions. Maintenant, je comprends que vous ne suivez simplement pas la liste de discussion, et donc la discussion à propos de votre bug.
je n'ai tout simplement pas eu le temps... Je ne consacre pas tout mon temps à PG... Je travaille aussi !
Quand à ma "non contribution" je considère qu'il s'agit de votre part d'une insukte. En effet une contribution pour éradiquer un bug qu'il ne vous plait pas de voir exposer est une insulte intellectuelles, à peu près équivalentes à celles des totalitarismes, qui ne supportent pas de voir exposer des défaillances dans leurs systèmes et préfèrent couper la tête à ceux qui les exposent !
Vous auriez pu proposer les deux représentations par soucis du détail. Ceci dit, ça ne fait pas de vous un crétin, peut-être en faite vous un peu trop non ?
MAIS C 'EST EXACTEMENT CE QUE J'AI FAIT !!!! J'AI ENVOYÉ LES DEUX À TOM LANE (ET MÊME 3 VERSION PAR SÉCURITÉ : TEXTE, XML et GRAPHIQUE !). DE PLUS JE VOUS L'AI DIT DANS MON PRÉCÉDENT POST MAIS VISIBLEMENT VOUS AVEZ UN PROBLÈME DE VUE !!!!
A +
Bonjour,
Je réalise actuellement un POC sur les traitements de masse à l'aide de Spring Batch et lors de la mise en place du multi-threading j'ai remarquer un problème de performance.
Lors de mes test avec 12 threads mes perfs ne sont pas du tout à la hauteur, suites a plusieurs tests je me suis rendu compte que quelque soit le nombre de threads (de 2 à 16) mes perfs batch sont les même. J'ai identifier que le problème provient de mon SGBD postgresql.L'insertion massive dans mon SGBD par plusieurs thread créer de la concurrence qui augmente très significativement les temps de chaque insert.
Je suis dans un contexte où je ne peux pas utiliser de mécanisme de masse de postgres (COPY) et je ne peux que faire des action unitaire (insert), élément par élément.Je vous présente mon cas de test que j'ai réalisé pour mettre en évidence mon problème :
Mon processus principal se charge de créer un nombre variable de threads, il se charge de répartir 1 million d'insert parmis les threads et va attendre la fin de chaque thread.
Chaque thread fait le nombre d'insert qu'il à reçu du processus principal, chaque requête insert est la même pour simplifier le test.Lest résultat de mes test :
Pour 2 threads, les 1 million d'insert se font en 2 minutes
Pour 12 threads, les 1 million d'insert se font en 1 minuteOr, l'ensemble des inserts sont indépendant, mon test se place dans un cas des plus standard : 1 seule table, uniquement un insert, pas d'index, pas de contrainte autre que la clé primaire.
Ma config est des plus puissante pour le SGBD : 6 CPU Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz , le reste étant du même niveau.
J'ai exploré le problème dans tous les sens, j'ai passé plusieurs jours avec mes DataBase Administrator pour essayer de trouver la cause de mon problème mais rien n'y fait, c'est pourquoi je me tourne vers vous.
Les cause classique ont pour la plupart était écarter par les DBA.le problème est clair : Lors d'un insert unitaire de masse multithreadé, il y a concurrence sans explication ...
Infos diverses :
Chaque thread se connecte une fois et effectue tous les inserts, aucun commit entre les insert.
SGBD en configuration standard, JBoss configuré pour pouvoir gérer les multiples connexion au SGBD.
La requête d'insert est classique "INSERT INTO declarant.entreprise ( dt_creation, dt_maj, version, cd_cat_juridique, cd_motif_siren_annule, cd_naf, dt_cessation_activ_economique, dt_cessation_juridique, dt_creation_entreprise, dt_derniere_maj_emetteur, nb_etablissements_actifs, raison_sociale, sigle, siren ) VALUES ( '2014-04-07 15:54:04.451', '2014-04-07 15:54:04.451', '0', '1000', NULL, '1111Z', '2009-06-01', NULL, '1993-07-28', '2010-09-02', '0', 'RAISON SOCIALE', NULL, '333222111' );"
Au niveau applicatif tout est bien gérer le problème ne peux pas provenir de cette partie.
Analyse pgBadger du test
Total duration Times executed Min duration Max duration Avg duration
Pour 12 Threads
51.333s 254,332 0.000s 0.029s 0.000sPour 2 Threads
14.866s 254,332 0.000s 0.011s 0.000sJe suis de prêt ce post, si vous avez besoin de toute autre information je vous les donnerais.
J'espère que quelqu'un pourra m'aider à trouver la raison ^^
D'avance, merci !
Le frein est très certainement le JT; En effet, l'écriture dans le JT est un point de contention, car il n'est pas possible de paralléliser les écritures dans le journal de PG...
A +
Vos questions sont puériles, mais je vais vous répondre !
...pourquoi ne pas avoir répondu à sa demande de plan des autres moteurs publiquement ?
Ayant reçu un mail privé, j'ai répondu à ce mail. Est-ce mal ? Suis-je stupide ?
Avez-vous vu sa réponse à propos du plan de SQL Serveur que vous lui avez fourni en privé ?
Je n'ais pas eu de réponse en retour de mon mail envoyé en privé !
Avez vous une réponse à lui apporter ?
N'ayant pas eu son retour je ne voit pas quelle réponse à apporter à aucune question en retour...
Ouvrez vous un bug pour être constructif ou pour d'autres raisons ?
Et vous, avec ce post, pensez-vous réellement constructifs ? Moi je pense que vous maîtrisez l'art d'enculer les mouches...
D'autre part, il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server....
je suis revenu à 21h chez moi et j'avoue que je n'avais plus le temps de me consacrer àn PG...
Peut être êtes vous un fonctionnaire effectuant 32 h par semaine avec 8 semaines de congés payé.. pas moi, j'ai une boite à faire fonctionner et des cours à donner à des ingénieurs...
Ps: Pourquoi dieu est-il nécessaire de faire un screenshot pour récupérer un plan sous SQL Serveur ?!
Vous simplifiez de manière parfaitement stupide l'envoi que j'ai fait; J'espère que c'est par ignorance... Car si c'était pas volonté, cela prouverait votre niveau de mauvaise foi...
Donc pour faire simple :
les plans de requête détaillés sont fournit par SQL Server sous forme XML dont voici un exemple :
<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.1" Build="10.50.4000.0" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
<BatchSequence>
<Batch>
<Statements>
<StmtSimple StatementCompId="1" StatementEstRows="4" StatementId="1" StatementOptmLevel="FULL" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" StatementSubTreeCost="0.0133358" StatementText="SELECT *
FROM T_CLIENT_CLI AS C
 FULL OUTER JOIN T_PROSPECT_PSP AS P
 ON C.CLI_SIREN = P.PSP_SIREN
 OR C.CLI_ENSEIGNE = P.PSP_ENSEIGNE" StatementType="SELECT" QueryHash="0x9365EE9F42E3675B" QueryPlanHash="0xBC472FE59224297A">
<StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
<QueryPlan CachedPlanSize="24" CompileTime="5" CompileCPU="5" CompileMemory="280">
<RelOp AvgRowSize="57" EstimateCPU="0.00581814" EstimateIO="0.000939" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Full Outer Join" NodeId="0" Parallel="false" PhysicalOp="Merge Join" EstimatedTotalSubtreeCost="0.0133358">
<OutputList>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
</OutputList>
<Merge ManyToMany="true">
<InnerSideJoinColumns />
<OuterSideJoinColumns />
<Residual>
<ScalarOperator ScalarString="[tempdb].[dbo].[T_CLIENT_CLI].[CLI_SIREN] as [C].[CLI_SIREN]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_SIREN] as [P].[PSP_SIREN] OR [tempdb].[dbo].[T_CLIENT_CLI].[CLI_ENSEIGNE] as [C].[CLI_ENSEIGNE]=[tempdb].[dbo].[T_PROSPECT_PSP].[PSP_ENSEIGNE] as [P].[PSP_ENSEIGNE]">
<Logical Operation="OR">
<ScalarOperator>
<Compare CompareOp="EQ">
<ScalarOperator>
<Identifier>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
</Identifier>
</ScalarOperator>
<ScalarOperator>
<Identifier>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
</Identifier>
</ScalarOperator>
</Compare>
</ScalarOperator>
<ScalarOperator>
<Compare CompareOp="EQ">
<ScalarOperator>
<Identifier>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
</Identifier>
</ScalarOperator>
<ScalarOperator>
<Identifier>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
</Identifier>
</ScalarOperator>
</Compare>
</ScalarOperator>
</Logical>
</ScalarOperator>
</Residual>
<RelOp AvgRowSize="33" EstimateCPU="0.0001603" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="3" LogicalOp="Clustered Index Scan" NodeId="1" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032853" TableCardinality="3">
<OutputList>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
</OutputList>
<IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
<DefinedValues>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ID" />
</DefinedValue>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_ENSEIGNE" />
</DefinedValue>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Alias="[C]" Column="CLI_SIREN" />
</DefinedValue>
</DefinedValues>
<Object Database="[tempdb]" Schema="[dbo]" Table="[T_CLIENT_CLI]" Index="[PK__T_CLIENT__D0BA12001DE57479]" Alias="[C]" IndexKind="Clustered" />
</IndexScan>
</RelOp>
<RelOp AvgRowSize="33" EstimateCPU="0.0001614" EstimateIO="0.003125" EstimateRebinds="0" EstimateRewinds="0" EstimateRows="4" LogicalOp="Clustered Index Scan" NodeId="2" Parallel="false" PhysicalOp="Clustered Index Scan" EstimatedTotalSubtreeCost="0.0032864" TableCardinality="4">
<OutputList>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
</OutputList>
<IndexScan Ordered="false" ForcedIndex="false" ForceScan="false" NoExpandHint="false">
<DefinedValues>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ID" />
</DefinedValue>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_ENSEIGNE" />
</DefinedValue>
<DefinedValue>
<ColumnReference Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Alias="[P]" Column="PSP_SIREN" />
</DefinedValue>
</DefinedValues>
<Object Database="[tempdb]" Schema="[dbo]" Table="[T_PROSPECT_PSP]" Index="[PK__T_PROSPE__3FA9CAA424927208]" Alias="[P]" IndexKind="Clustered" />
</IndexScan>
</RelOp>
</Merge>
</RelOp>
</QueryPlan>
</StmtSimple>
</Statements>
</Batch>
</BatchSequence>
</ShowPlanXML>Trouvez vous cela plus facile que la représentation graphique ?
Bien entendu, c'est ce XML qui est interprété graphiquement. mais n'étant pas sur que Tom lane dispose de l'outil de lecture des plans, j'ai envoyé les deux par sécurité...
Ais-je bien fait ou suis-je à vos yeux un crétin ?
Ahahah
Avec tant d'humour, vos cours en école d'ingé doivent être tellement amusants !
Effectivement, vous en avez tellement !!!
Mais ce qui est pire dans votre comportement, c'est que vous ne me donnez pas du tout envie de continuer à traiter ce sujet et donc votre mail aura l'effet inverse de celui escompté : j'abandonne la partie ! Ayant dû consacré 1h pour répondre à vos attaques infantiles, c'est 1h de perdu pour répondre à Tom lane...
A +
Pas un bug !!!!
Là franchement je rigole....
Ne pas pouvoir fournir un résultat sur une requête triviale c'est quand même un peu gros... D'autant que Oracle et SQL Server le font sans problème !
Si c'était une limitation, ce serait précisé dans les manuels de PG...
regardez vous même : http://www.postgresql.org/docs/9.3/stat … sions.html
ça n'y est pas....
Quand à Tom Lane, il m'a bien amusé en disant, "c'est pas bien grave, personne ne s'en sert..." !
Peut être sous PG, les gens hésitent à faire des jointures de peur de casser le moteur... 
Pour ma part je l'enseigne dans différentes écoles d'ingé et je l'utilise quotidiennement dans le cadre de la gestion de la qualité des données pour effectuer des rapprochements "flous"...
A +
En l'occurence, ce n'est pas un bug mais une limitation (comme le dit le titre de votre article). À mon avis, c'est la réponse qu'ils vous donneront. Et ensuite, je pense qu'ils vous diront que si vous pouviez proposer un patch implémentant ça, ce serait d'une grande aide. Et je les joins tout à fait sur ces deux remarques
Oui, enfin, ça me fait penser aux temps anciens ou MS traitait ses bugs de "fonctionnalité particulière..." 
Appelons un chat un chat. C'est un bug lié à une limitation du moteur SQL.
Je poste dans la bug liste en testant sur la dernière version 9.3.4.
A +
Bonjour,
j'ai mis cela dans les publications, car il s'agit à l'évidence d'un bug majeur mais j'ai écrit un article là dessus :
Une étrange limitation de PostGreSQL
En effet, PostgreSQL sort une erreur lorsque l'on fait une jointure externe bilatérale et que le prédicat de jointure n'est pas "cherchable".
Pouvez-vous m'indiquer qui/ou contacter le staff de PG pour faire une demande de correction ?
D'avance merci
PS : je cherche une solution temporaire et rajouterais une entrée à ce blog dès que j'ai trouvé une voie de contournement...
À mon avis vous avez un problème de modélisation....
En effet si on lit bien vos métrique, la table errolb montre qu'il faut 10 Ko pour stoker une seule ligne, en moyenne dans cette table !
D’où les question suivantes :
1) Quelle sont les tables ayant plus de 20 colonnes ?
2) Pour ces tables, et si elles font plus de 10 Go, quelle est la structure ?
A mon avis vous avez confondu tableur est bases de données....
A +
...(mais ça ne change pas mon opinion sur le reste: les parlementaires débiles, ça reste une spécialité bien de chez nous ;-p )
Là je suis d'accord avec vous... Sans doute pas tous, mais les récentes élections on tendance à prouver cela !
A +
Ce n'est pas suffisant! Je vois avec le moniteur de perf que c'est une session postgresql, mais je voudrais avoir également le process ID..
Vous l'avez dans le gestionnaire de tâches. Onglet Processus, ajoutez la colonne PID à l'ide du menu "affichage/ Sélectionner des colonnes".
A +
.
Problématique des coupures entre SVR & PDV: étant donné qu'un parlementaire débile (pléonasme local) a fait passer une loi interdisant la recopie de données d'une base commerciale dans une autre, comment gérer de telles coupures?
.
Je serais très intéressé d'avoir la référence de cette Loi.... En effet à ma connaissance elle n'existe pas. Seul existe la fait qu'une entreprise X ne peut pas donner des informations personnelles (pas seulement de BD informatique...) à une autre entreprise, sans le consentement préalable des clients.... Mais si votre entreprise à différents PDV c'est une consolidation. Si c'est une franchise, cela doit être prévu par contrat....
A +
Il vaut mieux utiliser PGAgent, qui, comme tous les planificateurs intégrés aux SGBDR se cale sur le "timeticks" interne à PG ce qui évite de l'interrompre à un moment inopportun en sus de mieux contrôler la sécurité des travaux planifiés.
A +
utilisez le moniteur de performance.
A +
En ce qui concerne le « boîtier externe ». J'en déduis que SQLPro voulait stocker des clé de chiffrement/déchiffrement. Cela est inutile et dérisoire dans ce cadre car l'admin sys peut avoir accès aux mots de passe en clair... Pourquoi rajouter plus de complications pour autant de dangers...
Ceci est totalement faux.... Visiblement vous n'avez jamais eu à utiliser ce genre de boitier. Une fois générée la clef ne peut être ni ouverte ni détruite par un admin système tant qu'il ne connais pas le mot de passe ou ne détient pas le certificat.
De même d'ailleurs pour les clefs générées dans le SGBDR et qui sont stockées dans les bases.
Encore une fois ce n'est pas parce que PostGreSQL fonctionne d'une manière absurde en matière de sécurité qu'il faut affirmez que les autres SGBDR comme Oracle ou SQL Server fonctionne de la même façon !
Ce qui est triste, c'est que ça fait peur de lire dans votre "CV" de ce forum que vous travaillez au "Laboratoire de Sûreté des Logiciels, CEA LIST" à Saclay... Encore heureux que vous ne soyez qu'un stagiaire... Bref, vous avez encore de nombreuses choses à apprendre !
A +
Je reviens sur cette discussion parce que j'en ais un peu marre de voir la confusion qu'il y a entre hachage et cryptographie...
Donc j'ai écrit un article à ce sujet qui montre la différence entre les deux et montre les solutions de chiffrement avec comparaison entre PG et SQL Server.
Hachage n’est pas cryptage ! De la sécurité des données chiffrées dans les SGBDR
A +
Bonjour,
gleu a écrit :Oui enfin, faut quand même savoir qu'il me semble que "le bon coin" est en train de migrer son SGBDR pour quitter PG
Une preuve de ce que vous avancez ou c'est juste une info digne d'un pilier de bar ?
Juste pour eviter les fausses rumeurs je vais clarifier ce point.
Je vais me presenter rapidement : je suis responsable de l'infrastructure du site leboncoin.fr, et donc en particulier responsable de l'utilisation et du bon fonctionnement des serveurs PG chez leboncoin.fr
Pour faire court : il n'est pas question de quitter PG. Nous allons meme upgrader la version pour profiter des dernieres evolutions de PG.
Si vous avez des questions particulieres sur son utilisation chez leboncoin (cela a pas mal evolué depuis le temoignage de Christophe Legendre), n'hesitez pas.
N'avez vous pas déchargée la base PG de certaines tâche et de certaines données au profits d'autres systèmes depuis quelques temps ?
A +
COPY avec plusieurs threads en // ou un bon ETL qui parallélise les lectures/écritures (malheureusement pas dans le libre, la version "free" de TALEND étant verrouille à ce niveau....)
En sus pensez à tester en faisant le scénario suivant :
1) supprimez les contraintes FK des tables de destination
2) supprimez les index non sémantiques des tables de destination
3) insérez en parallèle dans toutes les tables à la fois
4) recréez les index préalablement supprimés
5) rajoutez les contraintes FK préalablement supprimées
Si vous avez d'autres contraintes de validation (CHECK par exemple) ou des déclencheurs, et que vous êtes sûr de votre coup, pensez aussi à les désactiver...
A +
Votre demande est logiquement incohérente. En effet, si vous avez le jeu de données suivant, quelle réponse voulez-vous obtenir ?
agence | commune | nb_forage | type_reservoir | nb_reservoir
------------+------------------+---------------+--------------------+----------------
1 | 86001 | 2 | 01 | 1
1 | 86002 | 3 | 01 | 1
1 | 86002 | 3 | 02 | 2
2 | 86003 | 1 | 01 | 3
2 | 86003 | 2 | 01 | 3
2 | 86003 | 1 | 01 | 3
2 | 86004 | 0 | 02 | 3A +
Bonjour,
je voudrais savoir s'il est possible d'utiliser nextval('ma_sequence') dans un esprit GROUP BY, c'est à dire ramener dans un select un compteur qui se réinitialise à chauque nouvelle valeur d'un autre champ.
Les séquences ne le permettent pas. La solution à base de ROW_NUMBER() peut devenir incohérente s'il y à des suppressions de lignes.
De plus son temps de réponse va devenir de plus en plus lent au fur et à mesure de la montée en charge et vous avez toutes les chances d'avoir des télescopages de clef du fait de la concurrence des accès en lecture.
La seule façon correcte d'assurer ce mécansime est de se doter d'une table de clef et d'une procédure adéquate.
Votre table de clef pourrait avoir la forme suivante :
CREATE TABLE T_SEQUENCE_PARTITION_SQP
(SQP_ID SERIAL PRIMARY KEY,
SQP_TABLE_SCHEMA NVARCHAR(128) NOT NULL,
SQP_TABLE_NAME NVARCHAR(128) NOT NULL,
SQP_PARTITION NVARCHAR(64) NOT NULL,
SQP_CLEF BIGINT NOT NULL);
INSERT INTO T_SEQUENCE_PARTITION_SQP
(SQP_TABLE_SCHEMA, SQP_TABLE_NAME, SQP_PARTITION,SQP_CLEF)
SELECT 'public', 'noeud', origine, MAX(compteur)
FROM public.noeud
GROUP BY origine;Puis de réaliser une fonction au plus haut niveau d'isolation, ayant comme signature les éléments suivants :
CREATE FUNCTION F_GET_NEXT_KEY
in TABLE_SCHEMA
in TABLE_NAME
in PARTITION
out KEYqui assurera la combinaison d'ordre SQL suivanrt :
1) lire la valeur actuelle de la clef pour la table considérée (SELECT) et placer cette valeur + 1 dans la variable KEY
2) mettre à jour la valeur de cette même clef (UPDATE) pour la table considérée avec la valeur KEY + 1
Pour plus de détails, lire l'article que j'ai écrit à ce sujet...
A +
Pour ce qui est du développement Web , lisez le témoignage de Christophe Legendre, DBA de "leboncoin.fr".
Oui enfin, faut quand même savoir qu'il me semble que "le bon coin" est en train de migrer son SGBDR pour quitter PG car PostGreSQL n'est toujours pas capable de faire de la maintenance à chaud sans avoir soit des blocages ou des performances en chute dramatique ce qui lui a valu quelques pannes mémorables :
leboncoin de marche pas...
De plus la fiabilité de haute dispo (genre réplication a chaud) est assez hasardeuse....
Ce qui fait que la base est hors service la nuit pour assurer les tâches de maintenance, et par là même, les clients potentiels du Canada, des Antilles ou de la nouvelle Calédonie doivent poster leurs annonces à des horaires impossibles...
Mais de toute façon, ça reste beaucoup plus fiable que du MySQL dont l'incapacité de faire des sauvegardes à chaud cohérentes pose problème depuis belle lurette !
PG est plus fiable et aussi beaucoup plus rapide lorsque l'on tient compte :
1) des fonctionnalités SQL intégrées à PG qui n'existe pas dans MySQL, voir mon article à ce sujet...
2) de la concurrence (MySQL commence à plonger dès que l'on commence à atteindre 10 requêtes simultanée, alors que PG reste à l'aise même avec des dizaines de requêtes simultanées (à condition d'avoir la machine qui va avec et les bon réglages...)
Conclusion, dans le libre, y'a pas d'autre solution aussi fiable et performantes....
Quand aux bugs de MySQL, là c'est la rigolade assurée tant il y en a... Alors que c'est assez rare sur PG dont la communauté assez réactive, teste en permanence les nouveautés...
A +