Salut !
 
Cela fait de nombreuses années que je code en perl, bash, et divers, je ne suis donc pas débutant en programmation et maitrise d'ailleurs le perl sur le bout des doigts.
 
Mais au niveau des bases de données, j'ai toujours utilisé des fichiers en tmpfs ou ramfs.
Ca peut sembler bricolage comme ca, mais ca s'avère en réalité extremement rapide.
Le seul problème est qu'on ne fera jamais un google avec cette méthode
 
Donc je débute actuellement en MySQL.
Je visite bon nombre de sites expliquant tout ca très bien, mais certains détails ne sont expliqués nul part...
Le problème est que les gens expliquent comment utiliser, mais pas comment ca fonctionne, ce qui à mon avis, est le plus important ! Maitriser le fonctionnement en profondeur, c'est ca qui permet de coder malin et puissant.
 
.
 
J'ai donc listé plein de petites questions bien spéciales. Merci beaucoup à ceux qui pourraient y répondre, je pense que ca peut aider aussi beaucoup de gens.
 
1- existe-t-il un système d'expiration de table, de row, ou de database ?
google en parle mais personne ne donne de vraie méthode... -> http://www.google.com/search?hl=en [...] +expire%22
 
2- comment le moteur mysql gère le cache pour de très grosses variables ?
par ex, si j'ai un LONGTEXT de 4GB et seulement 2GB de ram, et que cette var est demandée toutes les secondes...
va-t-il mettre en cache que le début de la variable pour avoir le temps d'accéder au disque pendant qu'il renvoie le début... ?
et si j'ai 8GB de ram, va-t-il prendre le risque de mettre les 4GB en cache ?
 
3- peut-on gérer indépendamment la facon de mettre en cache chaque table (ou db) ?
si par ex je veux qu'une certaine table soit forcément chargée au complet en cache dès le lancement de sql, parce que je sais qu'elle est petite et que son temps de réponse doit absolument etre très rapide, quelque soit la fréquence de ses requetes.
 
4- existe-t-il un moyen de mettre des résultats de calcul en cache ?
par ex, si je demande 1000 fois en 1 minute le AVG() d'une colonne qui n'a pas changée, va-t-il faire 1000 fois le calcul ?
 
5- une véritable variable bool ?
BOOL, ou BOOLEAN, n'est en fait qu'une supercherie...
alors enum('Y','N') est-il le meilleur moyen de faire du vrai binaire sans gaspillage ?
 
.
 
MERCI !
 

t'as des besoins précis derrière tes questions ?
 
parce que bon, optimiser avant d'avoir un problème, c'est aller au devant de gros problèmes...
le SGBD gère le cache normalement, et il fera en général du meilleur boulot que toi, sauf optimisation très ciblée liée à un problème précis...
 
pour tes questions 1 et 2, pose toi avant la question de savoir si tes données doivent vraiment être mises dans une base, et si oui, est-ce que t'as pas moyen de les découper ? (parce que bon, 4Gb là comme ça sans exemple concret je sens le truc bizarre)
 
pour 3 et 4 fais des tests avant de vouloir optimiser ça : si ça répond de manière satisfaisante, ne touche à rien
 
la 5 me parait etre de l'enculage de mouches : si tu fais du booleen, prend le type de variable adéquat : ça te servira par la suite partout, parce que tu pourras traiter ton booléen en tant que tel, et pas faire de la bidouille de partout.
 
Si tu lis l'anglais, des citations de dev connus sur le sujet, qui découragent les pseudos optimisations:  
 
 
“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.” - W.A. Wulf
 
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified”[6] - Donald Knuth
 
“Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is.” - Rob Pike
 
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

Salut...
merci pour ta réponse, mais on n'a pas la meme vision de la programmation, ni de la pédagogie.
Pour moi, savoir coder, c'est avant tout comprendre ce qui se passe.
 
Non je n'ai pas de problème ou exemple précis, mes questions ne sont la que pour apprendre à coder intelligemment plutot que d'appliquer betement des règles sans rien comprendre.

Là à mon sens tu cherches pas spécialement à comprendre, mais juste des comportement pour des cas hyper spécifiques (perso je n'ai jamais rencontré aucun d'entre eux).

vous etes sacrément pénibles...
je crois que je vais poster sur un forum US parce que ce comportement est typiquement francais... des fois je me demande pourquoi je traine encore sur des sites francophones...

1/ pas en built in. ( a ma connaissance)

2/ 4Go dans un champ longtext , c'est du suicide. J'ai du mal a voir un use case.
 Si tu y accède toute les secondes, ça veut dire que ton programme consomme donc plus de 4Go de données par seconde. Peu probable sur une machine qui n'aurai que 2Go de ram. Dans tous les cas, le cache ne contiendra que des objet de taille inférieur a une taille limite, définie dans le fichier de conf

3/

4/ oui , mysql_query_cache. Sinon, pour un controle plus fin, utilise plutot un cache du cote du langage de programation utilisé, genre apc,memcache , ...

5/tinyint est ton amis

 
je n'avais pas lu ce message
 
c'est quoi cette attitude ou tu ne donnes pas la moitié des éléments nécessaire a t'aider et a la première question/remise en question, tu fais ta vierge effarouchée ?  
 
Des fois je me demande pourquoi je réponds a des ingrats

 
MDR...
 
pour moi programmer, c'est résoudre des problèmes...et je sais pas toi, mais j'ai pas suffisament de temps pour le gaspiller à résoudre des problèmes hypothétiques qui ne m'arriveront probablement jamais...
 
la vraie raison de ton approche c'est que t'es un bidouilleur, t'as toujours fait du script toute ta vie, tu es à l'aise dans les petites bidouilles que ce genre de langage suppose...
sauf que depuis, on a inventé des façons vachement plus puissantes et expressives pour développer, qu'entre temps la puissance machine est devenue abondante et disponible, et que donc tu perds ton temps à faire des pseudo optimisations dont :  
1/ tu n'es pas certain qu'elles te feront gagner du temps sur le programme final (ben oui, avant d'avoir le problème tu sais pas où il est)
2/ qui peuvent rendre ton programme très chiant à maintenir (hint : 80% du temps et de l'énergie consacrée à un programme l'est pendant sa phase de maintenance)
3/ le compilo fera surement les mêmes, mais en mieux
 
 
c'est vrai qu'aux US le C est encore un langage très répandu, tu trouveras donc plein de gens avec le meme profil que toi ...

Tu cherches à "apprendre à coder intelligemment" mais tu acceptes uniquement les réponses directes à tes questions, et refuses de remettre les questions elles-même en jeu ?

Coder intelligemment, c'est d'abord se poser les bonnes questions

Comment pouvez-vous imaginer une seule seconde que je vais utiliser une variable sql de 4GB ? ...
Bien évidemment que mes question ne sont pas des cas concrets, mais seulement des exemples permettant de comprendre le fonctionnement du serveur.
 
Vouloir comprendre est-il un crime ?
Croyez-vous sincèrement qu'on puisse coder intelligemment sans comprendre comment fonctionne le serveur ? c'est comme ca que vous apprenez quelque chose de nouveau ? sans comprendre ? ...
 
Cela dit ca commence à devenir un vrai troll...

le raisonnement par les extremes est rarement utile  
 
et tu as deja eu des réponses, tu es libre de faire avancer la discussion ou de troller

ben honnêtement c'est pas ça qui va t'aider à comprendre comment marche MySQL

ensuite si tu as des questions aussi précises tu devrais lire la doc, y'a probablement des whitepapers qui parlent de ces choses là..

mais je vois pas en quoi chercher les réponses à des questions tellement hypothétiques qu'elles ne se poseront jamais va t'aider à comprendre

(dasn ta question, y'a 2 réponses possibles : le serveur plante, ou il tient niquel le coup...dans les 2 cas la réponse te sert à rien parce que tu ne t'en serviras jamais)

et sinon oui on peut coder intelligemment sans comprendre comment tout fonctionne à ultra bas niveau...d'abord tu conçois ce que tu dois coder, et pour cela tu restes à un niveau très conceptuel...Et tu descends dans la technique si besoin, sur un cas concret que tu ne peux pas résoudre conceptuellement...
bienvenu en 2010, avec des langages de haut niveau...

si tu veux faire du bas niveau et comprendre tout ce qui se passe, fait de l'ASM...mais même là tu trouveras un florilège de whitepapers expliquant que les micro-optimisations, sauf cas hyper précis, c'est contre productif parce que le compilateur le fait mieux que toi...

l'agacement des gens ici face à des questions du genre que celle que tu poses vient du fait qu'on a tous trop lu de code "optimisé" horriblement chiant à comprendre, et qui au final n'apportaient rien, voire foutaient le bordel...

 
hmm, la je comprends mieux le point de vu

+1, c'est comme comprendre un grille-pain en se demandant "qu'est-ce qu'il se passe si j'y mets la boule", on a vu plus intéressant

 
Knuth a dit : Premature optimization is the root of all evil

C'est difficile de savoir exactement coment un SGBD va réagir dans certains cas extreme, ca reviendra toujours a comment un algorithme de décision secret fonctionne.
Tous les gros SGBD sont optimisés a l'extreme et sont donc ultra compliqué et, dans la majorité des cas, ultra secret.
 
Un des buts d'un SGBD est de pouvoir faire quelque chose d'intelligent et de performant justement sans avoir a savoir comment tout fonctionne derriere, tu dois juste avoir un minimum de connaissances sur les best-practice.

 
secrets bof, sur un SGBD opensource comme MySQL t'as accès à l'implémentation...
 
par contre l'algo peut ne pas etre trivial

Oui c'est sur dans MySQL t'as accès aux source mais il n'est pas en competition avec les gros SGBD payant (du moins pas du point de vue des entreprises).

 
et postgresql ?

J'ai dit gros SGBD...
Donc Oracle, IBM et Msft. A la limite Teradata et Sybase mais c'est bcp moins utilisé.

defini "gros"  
Un  SGBD qui contiendrait toutes les données carto  de l'IGN ( france/europe/monde) et en permettrai l'accès en temps réel sur nu site publique, c'est petit ?  
 
tu es sur de ne pas confondre gros et cher ?

Gros = plus de x% de part de marché mondiale.

Donc Linux, pas ex, n'est pas un "gros" OS pour les serveurs ?
 
Bah oui, quand c'est gratuit, ya pas de parts de marché

Des parts de marché ne sont pas forcement par revenu ou vente, ca peut etre par unité utilisée, il faut juste avoir un moyen de compter et comparer.
On parle bien de parts de marché pour les browsers alors qu'ils sont tous gratuits ...
 
Meme si Linux est gratuit a la base il est generalement vendu en distribution payante, donc Linux a bien un bon gros morceau de part de marché server (qu'on compte par unité ou par revenu d'ailleur)...

mais qu'est ce que la part de marchés d'un SGBD au sein des entreprises qui sont pret a en payer la licence apprte à la discussion ?

D'aillerus si on compte en terme d'usage plutot que de facture on a un tableau très différent

http://www.01net.com/article/302634.html

Ca n'apporte rien, je definisais juste ce que "Gros" signifiait pour moi.

un avis qui n'apporte rien est il utile  ?

CQFD, MySQL est gros.

Mon avis est que c'est difficile d'expliquer le comportement d'un SGBD dans les cas extreme.
Le reste ce n'est que des reponses aux questions posées.

- Les commandes EXPLAIN et ANALYZE TABLE aident à l'optimisation des requêtes, chaque requête sur un BD étant un cas particulier (on peut donc difficilement donner une réponse générale). Le choix des index en fonction des requêtes qu'on fait est très important également.
- Pour certaines grosses requêtes, la formation Mysql à laquelle j'ai assisté durant 1 semaine préconise de créer une table temporaire contenant un résumé des données utiles à la grosse requête. Si le contenu de cette table n'est pas trop gros, on peut utiliser le moteur MEMORY plutôt que MyISAM ou InnoDB
- Tuner mysql : cf ce script : http://www.day32.com/MySQL/
- les perfs sont meilleurs quand la structure d'une table est composées que de colonnes à taille fixe plutôt que variable (donc éviter les blob et varchar)
 
Et avoir un champ text de 4 Go par enregistrement dans un table, à mon avis, y'a un pb d'architecture

 
sur les clés je veux bien (et encore), mais sur les champs qui servent ni aux clés ni aux jointures c'est se limiter pour pas grand chose...

Je sais pas si je dis une bêtise  mais ça doit être plus rapide de se déplacer par blocs égaux *chien de mickey* que de devoir "chercher" la debut du prochain record.
Par contre, ça prend plus de place de remplacer un varchar par un champ de taille fixe.

Faire un while au lieu d'un foreach c'est plus rapide aussi. C'est pas pour ça que c'est pas négligeable.

Dans le même genre, une voiture va plus vite avec l'antenne couchée.

 
T'as pas honte de faire des doubles négations à cette heure là ?    
 

Si, je ferais un benchmark

ok. Tu vas essayer de faire démarrer une voiture en abaissant son antenne ?
 
 
 

Je vais faire comme tous les benchmarks de micro-optimisation : je vais rouler 2 * 400 000 km et conclure que j'ai gagné 2 min antenne couchée

je fais la même chose mais je crois que je vais gagner 2 min antenne debout...

Je crois bien qu'il va falloir trouver un troisième qui va checksummer le double double roulage du déca tour de la terre

 
Le coup de meilleures perfs avec des tables contenant que des colonnes à taille fixe, c'est pas moi qui l'invente, c'est écrit noir sur blanc dans le "Student Guide" édité par Mysql AB (2006) que j'ai eu en formation Mysql.

Faut pas s'emporter comme ça