[SQL] Jusqu'où peut on lui faire confiance ?

yo! les geeks,

Retour de mes périnigrations dans SQL (MySQL plus précisément)… Prenons un cas concret : une belle base de données (largement de plus de 100 000 entrées) qui est largement consultée (SELECT) et qui subit entre 50 et 100 INSERT/UPDATE par jour…

Ma question est : la construction des index ? Pour autant que je sache, le fait de mettre un index sur certaines colonnes de certaines tables implique qu’avec des INSERT il y a reconstruction des index… Quelles sont les conséquences ?

Jusqu’ici je n’avais en vue que des bases de données assez limitées avec un process d’insertion/update totalement contrôlé par moi. A présent je dois considérer le cas d’une base beaucoup plus imposante et dont je ne surveille pas l’évolution (du moins, pas de près).

Dans le même ordre d’idée, j’ai déjà entendu parler de “maintenance” de bases de données, et de tarifs assez conséquents qui vont avec… Ca signifie quoi exactement ?
Qu’est ce qui peut faire qu’une base de donnée peut “s’abimer” ? (en dehors des requêtes concurrentes/paradoxales… je reste dans un schéma assez simple : SELECT / INSERT).

Merci pour les infos.
Antoine

“administrer” un base c’est un boulot Les index bien choisits sont indispensables pour des raisons de performance principalement. Apres pour ce qui est de l’integrite des donnees, Mysql ne gerant ni les transactions, ni les foreign keys tu peux TRES facilement te retrouver avec une base de donnes pleine d’informations qui n’ont aucun sens. Avec plus de quelque milliers d’entrees c’est pas “quand?” c’est “combien de mes donnees sont inutilisables parceque partielles?”. Avec plusieurs milliers de lecture par jour, les strategie de locking de tables deviennent aussi importantes parceque si tu essaye de lire en pleine ecriture, tu peux te retrouver avec des donnees bizzares… important ou pas selon les tables c’est a toi de decider, mais encore faut il avoir le controle. Enfin, sous des charges poussees mysql a tendance a peter un cable et a corrompre la DB (lecture/ecriture impossible, recuperation de backup obligatoire) comme c’est arrive avec cafzone a la bonne epoque.

Pour illustrer ce que dit Glop: “Les petits papiers de SQLpro, techniques des SGBDR”: Ce qu’on doit attendre impérativement d’un vrai SGBDR.

Il ne faut pas se faire une mauvaise impression de cet article à partir de l’introduction un peu polémique (MySql est pris à partie car non transactionnel). Les articles sont très bien documentés et écrits, il montre qu’en environnement de saisie multi-utilisateurs, on ne peut quasiment pas se passer de transactions (ce manque n’est pas un problème lorsque il n’y a pas de saisie ce qui n’est pas ton cas).

Autrement dit, contrairement aux SGBDR transactionnels, tu risques d’avoir du pain sur la planche pour que l’intégrité et la cohérence des données demeurent dans le temps. C’est très bien illustré avec des exemples sur des reservations d’avions.

Tout ça c’est la partie applicative. Mais pour tout ce qui est maintenance technique non applicative (archivage, sauvegardre, index, volumétrie de la base, etc…) c’est alors plus le rôle du DBA. Autrement dit il y a 2 métiers pour gérer une base données. D’ailleurs souvent les DBA sont très techniques et ne s’interessent souvent pas à la partie applicative et fonctionnelle, et les administrateurs applicatifs (et les développeurs) ne veulent pas rentrer trop dans le système.

Ce message a été édité par phili_b le 04/04/2004

[quote]Tout ça c’est la partie applicative. Mais pour tout ce qui est maintenance technique non applicative (archivage, sauvegardre, index, volumétrie de la base, etc…) c’est alors plus le rôle du DBA. Autrement dit il y a 2 métiers pour gérer une base données. D’ailleurs souvent les DBA sont très techniques et ne s’interessent souvent pas à la partie applicative et fonctionnelle, et les administrateurs applicatifs (et les développeurs) ne veulent pas rentrer trop dans le système.[/quote]Entierement d’accord. Je ne sais pas d’ailleurs si c’est un defaut ou non. Et la frontiere entre les 2 mondes fluctuent souvent au gres des charges de travail. Est-ce à nous de dire quelles index il faut mettre a cause de nouvelles colonnes dans les tables, ou bien est ce au DBA de nous dire où l’on pourrait optimiser la BD grace à ses outils de diagnostics. J’aimerais bien un point de vue de quelqu’un sur ca car on a de gros soucis de perfs sur certaines requetes de 3 / 4 pages (merci les select imbriqués pour relire derriere…). Et je sens que je vais devoir me plonger dessus cette semaine : declaration de FK, redefinition de certaines pour les nouvelles colonnes, index…

En ce qui concerne MySQL, au taf on a un projet de migrer une application Oracle sur une base MySQL, notamment pour pouvoir faire payer moins cher. Bah on a de serieux problemes de cohérence de tables. On est obligé de mettre des tests supplémentaires et de modifier l’archi du soft. Avant, on interceptait les erreurs Oracle et on les gérait (une contrainte de levée ? nom de la contrainte et type de la contrainte ? -> traitement particulier si nescessaire). Impossible de faire la meme chose avec MySQL, surtout au niveau des FK. Beaucoup de choses dans notre archi sont basées sur ces FK, ca permet de garder une bonne integrité referentielle au fil du temps. Avec MySQL, en 2 semaines de tests, on avait deja créer des betises dans la base. C’est un gros changement pour l’appli et franchement je trouve ca largement moins propre que de gerer des exceptions (pas au sens strict du terme hein ). Hélas, les contraintes economiques et financieres sont plus fortes que les peregrinations de notre cher admin DBA ou de l’equipe de dev (on avait deja assez de projets à gerer en simultané…)
Ce message a été édité par Donjohn le 04/04/2004

Y a des fois, y a des gens, je sais pas ce qu’ils font dans l’informatique. Je te mets pas en cause avec cette affirmation Don, je ne pense pas que tu sois a l’origine de la decision d’utiliser MySQL.
Je rappelle donc que MySQL n’est pas gratuit pour une utilisation commerciale. C’est fou ca.

Si vous voulez faire du “qui se rapproche le plus d’oracle a pas cher”, un seul choix: PostGreSQL. C’est un tres bon SGBDR meme s’il n’a pas la rapidite de MySQL en regle general, il reste tres constant en terme de performance meme sous forte charge (ce qui n’etait pas le cas avec MySQL 3.XX, je sais pas si la 4 a corrige le tir).

Enfin tout ca pour dire que remplacer Oracle par MySQL… Putain, je comprend pas.

LoneWolf
Les mysteres insondables des decideurs presses.

[quote]Y a des fois, y a des gens, je sais pas ce qu’ils font dans l’informatique. Je te mets pas en cause avec cette affirmation Don, je ne pense pas que tu sois a l’origine de la decision d’utiliser MySQL.
Je rappelle donc que MySQL n’est pas gratuit pour une utilisation commerciale. C’est fou ca.

Si vous voulez faire du “qui se rapproche le plus d’oracle a pas cher”, un seul choix: PostGreSQL. C’est un tres bon SGBDR meme s’il n’a pas la rapidite de MySQL en regle general, il reste tres constant en terme de performance meme sous forte charge (ce qui n’etait pas le cas avec MySQL 3.XX, je sais pas si la 4 a corrige le tir).

Enfin tout ca pour dire que remplacer Oracle par MySQL… Putain, je comprend pas.

LoneWolf
Les mysteres insondables des decideurs presses.[/quote]Ouais je te raconterais pas en détail tout ca… J’ai malheureusement suivi de loin le debut du projet, car j’étais full sur un autre truc. Mais là je suis bien deg car ca vient se foutre en plein final du mien (l’extase, tu stabilises une version et 2 jours avant de livrer un projet vient modifier toutes les requetes). Et puis revenir en arriere desormais ca va etre chaud à leur faire comprendre vu qu’ils ont sacrement bossé sur ca deja. Par contre, ils paient bien la licence chez moi (j’ai pas dit qu’ils l’utiliseraient gratuitement hein ). Je vais tentez de voir pour postgresql vu que j’ai un repis dans mon projet du à des problemes qui ne sont pas de mon ressort (lignes adsl tout ca).

Edit : pas la peine de savoir quelle aurait été le meilleur SGBD à la place de Oracle, le projet sur MySQL ne supportera pas DU TOUT la meme charge (du simple à 100). Donc l’idee à la base est pas mauvaise : trouver un SGBD pas cher et super leger. Meme SQL Server est trop cher et trop gros pour la charge de ce projet (version Supra Light d’un soft de chez nous en gros)

Edit2 : donc pour revenir au thread principal : tu voudrais pas tester autre chose que MySQL ? car le lien de phili_b est assez exemplaire… et l’exemple de mon taf pourrait aussi te convaincre des defauts de ce SBGDR
Ce message a été édité par Donjohn le 04/04/2004

Ah ouais ok, c’est vrai que j’ai pas l’habitude des boites qui payent leur licence, mais du coup, je comprend pas pourquoi on utilise MySQL, payant, plutot que PostGreSQL, gratuit, alors que ce dernier est plus proche d’Oracle en terme de fonctionnalites.

Ils ont vraiment cherche des solutions, les mecs, la? (ceci dit, c’est vrai que y a un an, PGSQL etait galere a installer sous windows)

LoneWolf
Enfin ca me depasse quand meme, tout ca.

[quote]Ah ouais ok, c’est vrai que j’ai pas l’habitude des boites qui payent leur licence, mais du coup, je comprend pas pourquoi on utilise MySQL, payant, plutot que PostGreSQL, gratuit, alors que ce dernier est plus proche d’Oracle en terme de fonctionnalites.

Ils ont vraiment cherche des solutions, les mecs, la? (ceci dit, c’est vrai que y a un an, PGSQL etait galere a installer sous windows)

LoneWolf
Enfin ca me depasse quand meme, tout ca.[/quote]Tu sais, si un des mecs qui a fait l’etude (ahem…) ne connait que MySQL de reputation et pas les autres systems car il a toujours travaillé sur des gros systemes à 1000 bases Oracles en simultané, la suite des decisions est logique… Et on peut pas toujours foutre son nez partout meme si ca nous retombe dessus apres.

Edit : et je crois qu’en plus il y avait un soucis d’accés natif à la SGBD dans le sujet, je ne sais pas si Windev gére l’acces natif à PostGreSQL… Alors que MySQL et Oracle oui (avec un licence pour une dll Oracle en plus). On pourrait passer par ODBC mais les perfs s’en ressentiraient et il y aurait aussi un impact sur le dev, car les requetes sont faites pour Oracle (select imbriqués et gestion des n° d’erreurs Oracle - d’ailleurs merci PCSoft d’avoir modifier les numeros de retour entre la version 5.5b et 7.5). Celà dit je pourrais voir si ca pas été amelioré depuis le temps ou j’avais fait des tests (Windev 5.5b alors qu’on bosse en 7.5 voir 8 pour certains trucs)
Ce message a été édité par Donjohn le 04/04/2004

Effectivement, y a pas beaucoup d’API pour PGSQL sous windows, et c’est bien dommage, tiens. Par contre, les select imbriques, va falloir les refaire…

Eh glop, t’es encore la? t’as pas un lien magique avec les consequences (en terme de perfs) de l’utilisation d’ODBC par rapport a une API native? Genre acces a SQL server en ODBC puis en natif.

LoneWolf
Ph34R Da API SpiRIt

[quote]Est-ce à nous de dire quelles index il faut mettre a cause de nouvelles colonnes dans les tables, ou bien est ce au DBA de nous dire où l’on pourrait optimiser la BD grace à ses outils de diagnostics. J’aimerais bien un point de vue de quelqu’un sur ca car on a de gros soucis de perfs sur certaines requetes de 3 / 4 pages (merci les select imbriqués pour relire derriere…).[/quote]hé hé bonne question. Moi je me suis pris méchamment la tête avec un client qui ne voulait pas comprendre cela.

Autrement dit j’avais reçu une requête de la mort très mal écrite. Pour moi on ne passe les explains (que je ne connais pas d’ailleurs  étant plus adm applicatif que DBA) qu’une fois que les requêtes sont bien écrites. ça sert à rien de faire des optimisations techniques si déjà la requête est bancale.

Donc pour moi il faut bien spécifier ce que l’on veut, puis trouver le bon algorithme ensembliste et enfin bien écrire la requête en tenant compte des régles de bases pour faire bien fonctionner les indexes par exemple.

Le DBA il intervient en amont pour conseiller l’emplacement des indexes, régler la volumétrie des indexes et des tables. Il intervient ensuite en aval pour optimiser une requête bien écrite à l’aide d’explain entre autre. Il intervient aussi pour plein d’optimisations qui sont transparents aux développeurs et adms applicatif. Mais ce n’est certainement pas lui qui va réécrire une requête tout simplement car il ne connait pas le fonctionnel.

C’est pour cela que c’est à l’adm applicatif de bien contrôler les requêtes et les faire réécrire aux développeurs.

Pour revenir à mon exemple j’avais refusé d’étudier la requête car elle avait été faite par un requêteur. Je n’ai rien contre les requêteurs mais contre la façon dont avait été construit les éléments servants à la construction des requêtes.

Ce message a été édité par phili_b le 04/04/2004

Tout d’abord, merci pour vos réponses… Ensuite : “Oulalala, mon dieu, chuis à l’ouest moi !”

Clairement, je suis ptet un naif, mais pour moi un SGBD doit se gérer tout seul, du moins dans un certain cadre. Je vais vous définir le mien, et j’espère que vous pourrez me dire si je prends des risques.
J’ai donc deux site. Le premier contient une base de données d’articles, de catégories, de groupes, etc, etc. (cf. d’autres posts de moi pour les détails). MySQL m’indique actuellement 13621 enregistrements pour un poids total de 728 Ko. Mes projections me font dire que ça devrait tripler une fois que la DB sera totalement construite. J’estime que c’est une petite BD, j’estime bien ?
Cette BD est mise à jour toute les semaines, 90% avec des INSERT et à hauteur d’environ 30 enregistrements par semaine. Quelques UPDATE par-ci par-là mais pas grand chose. Là où la BD va être vraiment utilisée, ça sera en matière de consultation à partir d’un site web. Le nombre de requêtes sera limité parce que je les pense (j’espère) bien écrites (merci phili_b ).
Pour ce que je crois, cette DB n’a pas spécialement à être “maintenue”… Le peu d’enregistrements ajoutés chaque semaine ne devrait pas influer sur l’ensemble, et notamment, pas sur la consultation. Surtout si l’on considère la taille de la DB. Suis-je un doux rêveur, ou bien vois-je juste ? A quoi devrais-je faire attention ?
Ca c’était pour le premier site.
Maintenant considérons une base de données beaucoup plus conséquente, mais qui fonctionne sur le même principe : beaucoup de consultations, mise à jour par INSERT tous les jours à hauteur de 100 enregistrements par jour. Attention, je précise bien que dans aucun des deux sites je ne suis confronté à un problème de concurrence des requêtes. J’ai pas le problème que peuvent avoir les compagnies aériennes avec leurs réservations qui tombent en même temps… Et j’en suis fort aise
Concernant la taille de cette seconde DB j’ai un peu plus de mal à l’évaluer… On va viser large et annoncer plus de 100 000 enregistrements et plus d’1 Go en poids. Quelles sont alors les conséquences ?

L’idéal pour moi, vous vous en doutez, c’est que ça tourne tout seul. Je n’ai pas la prétention de jongler avec des DB monumentales où les INSERT/UPDATE tombent toutes les trois millisecondes. C’est pour cela que je voudrais m’assurer que mes choix (MySQL/PHP) sont bons.

Thx
Antoine

Edit : Comme vous l’aurez surement compris, je suis un “petit” par rapport à vous en matière de connaissances sur les SGBD. Mais d’un autre côté, ce que j’ai à gérer est relativement simple (enfin, je crois) : de l’insert et de la consultation uniquement. Mais dans l’ensemble, n’hésitez pas à me parler en termes “simples”. Il y a plein de notions que je ne connais pas (foreign key, entre autres…) mais j’apprends, encore et encore…

Edit 2 : trouvé sur un site comme étant dans la doc de MySQL : MySQL Server was designed from the start to work with medium size databases (10-100 million rows, or about 100 MB per table) on small computer systems.Combien même les développeurs de MySQL sont prétentieux avec ces chiffres, ils me rassurent grandement… Même dans le cas du 2e site, je doute fortement d’atteindre ne serait-ce qu’un million d’enregistrements

Ce message a été édité par AntoineViau le 04/04/2004
Ce message a été édité par AntoineViau le 04/04/2004

Dites moi si je me trompe:
Dans la mesure ou MySQL est payant pour l’utilisation dans un projet commercial, la solution la moins chere que je voit est MSDE2000, (avec les limitations que cela comprends, encore qu’elles ne soit pas si limitatives) puisque son utilisation et distribution est gratuite (meme s’il y a quelques contrats a respecter)

Et quand on compare MySQL et MSDE2000 (qui est quant meme le moteur de SQL Server 2000), … en fait ya pas de comparaison!

Je me trompe?

Suite à notre discution hier sur IRC et dnas ce thread, j’ai demandé des precisions sur MySQL à celui qui est en charge de ce projet. Et voilà le lien qui me rassure quand à la suite des developpement et du maintien de la base : http://www.mysql.com/doc/en/InnoDB_foreign…onstraints.html

MySQL gere donc les FK… OUF ! De plus la version 4.0.1 (meme si certaines parties comme les Select imbriqués sont en beta) gère parfaitement ces FK. Bon, faut qu’on voit comment on peut gerer les retours d’erreurs (allez, je parie à 10 contre 1 que les retours d’erreurs sont differents entre les differrentes bases malgré l’API de Windev…)

Donc, il faut bien les declarer pour être sur qu’il n’y ait pas d’informations non valides qui s’inscrivent dans la base. Il est preferable d’avoir une erreur lorsqu’on risque de violer l’integrité d’une base que de laisser un systeme permissif chiant à maintenir et au final générant des bugs imcomprehensibles (comment voulez vous comprendre/corriger un bug quand les données le générant sont fausses ?).

LoneWolf si me lis, c’est entre autre pour toi

Effectivement, je connais pas trop la 4.XX, mais je pensais pas que les FK etaient deja dans la 3.XX. Dingue. D’un autre cote, pour avoir essayer innoDB, ca va etre galere, prend la 4.01 plutot

Enfin ca remet pas en cause ce que j’ai dit sur MySQL, ca reste un “access like linux” avec les performances (sous faible charge) en plus (ouais parce que access, c’est pourri meme avec un seul user). Tant que les select imbrique seront limite et qu’il n’y aura pas de trigger, et pas vraiment de transactions, bah euh… voila quoi.

LoneWolf
PGSQL rulez.