Discussion :

[LeHibou2]

Bonjour à tous,

J'ai un petit problème de compréhension.


Situation : afficher les valeurs qui reviennent plus de 3 fois.

Je me dis que créer une vue est simple, ne créé pas de valeurs supplémentaires en mémoire disque.

Seulement, sur une table de plusieurs dizaines de gigas, la vue risque de mettre longtemps à s'afficher car elle doit tout recalculer.

A contrario une procédure stockée (ou un trigger si l'envie me venait) pourrait me mettre dans une nouvelle table les valeurs qui reviennent plus de trois fois au fur et à mesure.
Seulement, risque d'overhead à chaque requête. Mais restitution rapide (table dédiée).

Donc vous conseillez quoi comme stratégie globale ?

Est-ce qu'il y a un mal à faire l'un ou l'autre ? Ai-je bien posé les deux variables d'ajustement (espace, temps), bien cerné le problème et ses contraintes ?

Il s'agit ici d'une approche globale de logique avant de mesurer.

Merci à vous,

A bientôt,

LeHibou2

[punkoff]

Bonjour,


Vous avez oubliez une possibilité :
- ne consolider les données qu'une fois par jour (ou 2 ..) grâce à un batch.

[doubleDu]

Bonjour.

Il n'y a pas vraiment de meilleure solution, c'est juste une histoire de contexte et de fraîcheur de données.

Exemple, il te faut le résultat très rapidement, opte pour la solution de calcul en amont via un batch, une procédure stockée, un trigger. Bien que le trigger, est apparemment à proscrire vu la volumétrie de ta table car il ralentirai tes traitement car tu devrais requêter sur ta table afin de trouver des doublons. L’inconvénient de cette solution est la fraicheur des données.

Maintenant, si tu as une contrainte de place, la vue te permet de ne pas stockée les informations attendues et les données seront fraîches (exactement le reflet de tes données)

Mais comme cela, sans connaître réellement le contexte, je te conseillerai d'opter dans un premier temps pour la vue, car elle a également l'avantage d'avoir son plan compilé sur le serveur et donc d'obtenir un léger gain dans l’exécution de la requête.

En espérant avoir été clair.

[LeHibou2]

Merci à vous deux,

Alors oui dans ma question j'avais omis la problématique de la fraîcheur : on est à 1 minute maxi.

D'où l'idée de la procédure stockée initialement.

Le batch me servira certainement (je n'y avais pas pensé) pour les calculs et stats.

Oui les triggers... bof bof.. c'est vrai.

Mais une vue, même compilée, regarde à nouveau dans toute la table. J'ai un peu peur des performances générales.

Parce que la taille augmente de 10 gigas toutes les deux semaines (ouais quand même).
Ca devrait se calmer d'ici quelques mois mais bon..

La vue vous semble toujours adaptée ?

Merci à vous

[doubleDu]

Bonjour.

La vue ne me semble pas une solution a proscrire, surtout si tu dois avoir une fraîcheur des données à moins d'une minute.
Sinon pour cette contrainte de fraîcheur, tu vas devoir implémenter un traitement qui s'exécutera toutes les minutes et qui sollicitera opeut être inutilement ta base de données.

Maintenant, pour rechercher des doublons, il existe une solution relativement simple au niveau SQL.

Ton code sera une auto-jointure (bon ça, jusque là, rien de nouveau au pays du SQL) mais tu y ajoutes non pas un critère de différence mais un critère de supériorité.

C'est surement pas très très clair dis ainsi, donc le mieux c'est un exemple

Code :

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

1
2
3
4
5
6
 
SELECT [mes_colonnes]
FROM ma_table t1
INNER JOIN ma_table t2
 ON [les critères de doublon]
 AND t2.clé_primaire > t1.clé_primaire -- supérieur > et non différent <>

Normalement, cette solution va te lever les doublons de doublon et l'index sur la clé primaire devrait être utilisé.

A tester, bien entendu.

Concernant la procédure stockée, elle va requêter sur ta table, donc tu devrais obtenir les mêmes temps que la vue...

J'espère que cela te donne plus d'éléments pour tes futurs dev et tiens nous informé de tes succés

[aieeeuuuuu]

Bonjour,

Si on résume:

Alors oui dans ma question j'avais omis la problématique de la fraîcheur : on est à 1 minute maxi.

Donc on oublie les solutions asynchrones... tel que batch régulier de recalcul...
Il reste donc :
1 - la requete (dans une vue, un procédure ou adhoc...) ==> lenteur à la lecture
2 - le trigger pour garder des données consolidée valides ==> lenteur à l'écriture

Mais :

Parce que la taille augmente de 10 gigas toutes les deux semaines (ouais quand même).

Soit plus de 700 Mo de données insérées par jour ??? s'il y a un trigger sur la table, mieux vaut qu'il soit bien, TRES bien codé... et encore...
Comment les données sont-elles insérées ?


Personnellement, je partirais sur le plus simple : la vue, avec un index couvrant la requête. Si les temps de réponse deviennent trop importants, vous pourrez alors transformer cette vue en table alimentée par un trigger...... ou passer sur SQL Server

[LeHibou2]

Les index sont en place et j'espère que cela tiendra.

Les données sont insérées par requêtes préparées car on a remarqué que les performances sont meilleures qu'avec des procédures stockées (Mysql ne cache pas la compilation des procédures stockées entre plusieurs connexions, à la différence d'Oracle).

Lien (d'autres existent abondant dans le même sens) :
http://www.joinfu.com/2010/05/mysql-...aint-all-that/


Il ne faut pas que la requête dure plus de 30 secondes quoi. Donc je pense qu'il y a beaucoup de marge.

Vos avis sont éclairants et je vous en remercie. Beaucoup.

A bientôt,

LeHibou2

[SQLpro]

...
Situation : afficher les valeurs qui reviennent plus de 3 fois.
Je me dis que créer une vue est simple, ne créé pas de valeurs supplémentaires en mémoire disque.
Seulement, sur une table de plusieurs dizaines de gigas, la vue risque de mettre longtemps à s'afficher car elle doit tout recalculer.
...
Donc vous conseillez quoi comme stratégie globale ?

Est-ce qu'il y a un mal à faire l'un ou l'autre ? Ai-je bien posé les deux variables d'ajustement (espace, temps), bien cerné le problème et ses contraintes ?

Si vous êtiez sur un vrai SGBD Relationnel comme Oracle ou SQL Server, vous pourriez utiliser les vues matérialisées (Oracle, mais asynchrones) ou les vues indexées (SQL Server, synchrones) qui sont faites pour cela et minimise les calculs car fonctionnant par différence.
Mais hélas, MySQL n'étant qu'un ersatz de SGBD... (a lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux), vous aurez bien du mal à concilier rapidité et fiabilité !

Pour info, sur une table d'un milliard de ligne, une vue similaire portant sur une table de 600 Go, met moins de 10 ms à afficher le cumul par SUM...

A +

A +

[LeHibou2]

Merci beaucoup à tous !

Votre aide était la bienvenue
Je suis à présent rassuré.

Nosql, j'avais déjà lu ton intervention, acide et réaliste sur mysql.

On a fait le tour de différent moteurs dits newsql gen (volti, genie, nuo).

Il y a un nouvel entrant ici : http://newsql.sourceforge.net/

Mais il est probable qu'on se tourne vers Oracle pour une seule raison : procédure stockée bénéficiant d'un cache global (mal dit mais l'idée y est) évitant les compilations à chaque nouvelle connexion de la même procédure.

On arrive à contourner le problème en ne fermant pas la connexion sur les services générés parnos scripts. Mais pour traiter les inputs utilisateurs.. la merde.

Un petit mot là dessus (newsql vs oracle/nosql) ?

A très bientôt,

LeHibou2

[doubleDu]

Si vous êtiez sur un vrai SGBD Relationnel comme Oracle ou SQL Server, vous pourriez utiliser les vues matérialisées (Oracle, mais asynchrones) ou les vues indexées (SQL Server, synchrones) qui sont faites pour cela et minimise les calculs car fonctionnant par différence.
Mais hélas, MySQL n'étant qu'un ersatz de SGBD... (a lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux), vous aurez bien du mal à concilier rapidité et fiabilité !

Pour info, sur une table d'un milliard de ligne, une vue similaire portant sur une table de 600 Go, met moins de 10 ms à afficher le cumul par SUM...

A +

A +

Bonjour.

Vos remarques sont fortes inintéressantes, mais ne tiennent nullement du contexte et ne font pas avancer la problématique.

Le soucis de "LeHibou2" se situe avec MySQL et non Oracle ou autre SGDB-R. Après il faut peut être se poser la question de l'utilité de disposer de machine de guerre pour son projet.

Questions :

• prenez-vous un tank pour aller au boulot tous les matins ?
  
• De la même manière, LeHibou2 a t il l'utilité de disposer d'une machine de guerre pour son application ?
  
• Allez-vous me conseiller d'utiliser Oracle ou SQL Server pour mon application web gérant des contenues ?

Ce commentaire n'est donc pas utile ici, mais somme toute très inintéressante dans un autre contexte; il doit y avoir un topic sur le forum pour ce genre de débat.

Maintenant, si vous trouvez le bon topic, je serais enthousiasmé de débattre avec vous.

Bien à vous

[SQLpro]

Bonjour.

Vos remarques sont fortes inintéressantes, mais ne tiennent nullement du contexte et ne font pas avancer la problématique.

Le soucis de "LeHibou2" se situe avec MySQL et non Oracle ou autre SGDB-R. Après il faut peut être se poser la question de l'utilité de disposer de machine de guerre pour son projet.

C'est justement bien pour éviter des machines de guerres fort couteuse que peut se poser le problème de changer de SGBDR.
Entre une licence à 3 000 € et du hardware à 25 000 € pour compenser les défauts et manques de MySQL, je pense que vous aurez l’honnêteté de reconnaitre qu'une des solutions est nettement moins cher à tout point de vue (hardware, mais aussi cout d'exploitation global... + de hardware = + de pannes...).

Votre raisonnement ne tient donc apparemment pas compte des besoins réel de l'entreprise (une solution qui marche)... Mais se concentre hélas, comme beaucoup d'informaticien, sur le petit bout de la lorgnette, c'est à dire la chapelle MySQL ou la chapelle PostGreSQL, ou la chapelle Linux...

A +

[doubleDu]

Bonjour.

J'ai un petit soucis là...

Mon propos n'était ni de vous attaquez personnellement, ni de vous faire changer d'avis car j'ai lu votre article que je trouve à charge, qui date de 2010, et vous semblez bien ancrer dans vos idées... Mon propos était de vous faire remarquer que Lehibou2 a (avait) un soucis et que votre réponse a été d'investir 28 000 € pour lister des doublons + le coût d'une migration

Je vais également ajouter que, au travers de mon métier, je suis plus enclin à préconiser des solutions SGBD-R de type Oracle ou Sybase ASE (pour les systèmes OLTP, SQL Server ayant été abandonné par nos clients pour des raisons que nous n’aborderons pas ici) et Teradata et Sybase IQ pour du Big Data. Donc j'ai tendance à abonder dans votre sens !

Je voudrais enfin vous dire qu'il ne faut pas être sectaire au point de dénigrer des solutions ou de ne pas admettre que certains outils, mêmes rudimentaires, peuvent être utilisés, cela dépend du contexte. Maintenant, catégoriser les personnes en fonction qu'ils utilisent tel ou tel outil me semble un peu léger.

Toujours revenir au bon sens paysan (ce que l'on devrait apprendre dans cursus de formation), un exemple, je dois me rendre à la boulangerie, qui se trouve à 3 minutes à pied, pour acheter mon pain, je vais mettre mes chaussures même si elle n'ont pas la climatisation mais cela m'est largement suffisant.

Enfin, j'espère que vous ne trouverez aucune attaque personnelle ou une quelconque animosité dans mes propos.

Je vous souhaite une bonne continuation

I have a simple rule of thumb for presentations – the more glamorous, trendy or exciting the title sounds the less likely it is that the presentation will be useful (but that won’t stop me reading the abstract – just in case).
Jonathan Lewis

[alassanediakite]

Salut à vous
Maitre sqlpro, votre position exagérée nuit à votre réputation de fin connaisseur! et est un frein à l'évolution du domaine des bases de données.
Quand on demande un choix de SGBD, votre avis (avec arguments) est souhaité!
Sinon au cas où le choix est déjà fait, votre solution dans le contexte est la bienvenue et une comparaison serait d'une utilité supplémentaire.
Par exemple, croyez-vous avoir apporté une aide ici?
Mes respects les plus sincères.
@+