Vue vs procédure stockée ?

Version imprimable

31/05/2013, 10h16
LeHibou2

Vue vs procédure stockée ?

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
03/06/2013, 09h17
punkoff

Bonjour,

Vous avez oubliez une possibilité :
- ne consolider les données qu'une fois par jour (ou 2 ..) grâce à un batch.
03/06/2013, 14h38
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.
04/06/2013, 20h44
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
05/06/2013, 09h07
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:

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 ;)
05/06/2013, 09h57
SQLpro

Citation:

Envoyé par LeHibou2

...
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 +
05/06/2013, 10h25
LeHibou2

Merci beaucoup à tous !

Votre aide était la bienvenue :D
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
05/06/2013, 10h48
doubleDu
Citation:

Envoyé par SQLpro

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
05/06/2013, 13h25
SQLpro

Citation:

Envoyé par doubleDu

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 +
05/06/2013, 14h33
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

Citation:

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
05/06/2013, 15h14
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.
@+
05/06/2013, 15h37
SQLpro

Citation:

Envoyé par alassanediakite

Par exemple, croyez-vous avoir apporté une aide ici?

Oui, j'ai apporté une solution. Elle peut vous plaire ou pas. C'est votre problème. En avez vous apporté une autre ?
Bref au lieu de critiquer les solutions proposées, apportez en d'autres et si possible de meilleures....

A +
05/06/2013, 17h00
aieeeuuuuu

Bonjour,

Si on résume:

Citation:

Envoyé par LeHibou2

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 :

Citation:

Envoyé par LeHibou2

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:aie:
05/06/2013, 21h57
LeHibou2

:P

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
09/06/2013, 00h04
tse_jc

Bonjour,

A toujours vouloir tout faire rentrer dans MySQL il arrive parfois que cela en devient indécent. Et quand un SGBDR ne réponds pas ou ne peut répondre de près ou de loin à un cahier des charges d'entreprise, choisir une telle solution, s'est engager l'entreprise dans un gouffre financier à moyen voire court terme, (sans parler d'un redeveloppement à la clé) et au lieu de critiquer SQL pro vous feriez mieux d'essayer de comprendre au moins le pourquoi de sa réponse en tant que professionnel que vous êtes censés être, au lieu de mettre cela sur le compte d'un parti pris comme le ferait au premier abord n'importe quel non initié dans le domaine.

La première règle à appliquer avec MySQL, c'est de ne l'utiliser que si on n'a pas besoin d'utiliser de vues. Je vous laisse méditer la dessus.
Ensuite pour un tel volume de données, avez vous pensé au partitionnement comme solution rustine à votre problème?

Cordialement,

Jc.