La structure :
--------------
Une base de données mySQL n'est rien d'autre qu'un tableau avec des lignes et des colonnnes.
Le nombre de cellules s'obtient en multipliant les nombre de colonnes par le nombre de lignes.
Si vous avez par exemple :
100 lignes
20 colonnes
Ca vous donne tout de suite 2'000 cellules contenant de l'information. Une cellule peut contenir des nombres, des adresses email... mais aussi des textes qui peuvent faire pas mal de pages.
Dans notre base, si on rajoute une ligne, ça va nous faire 101 lignes et toujours 20 colonnes. Soit : 2'020 cellules. Donc à chaque fois qu'on ajoute un enregistrement dans une base de données, on doit le multiplier par le nombre de colones pour obtenir le nombre de cellules. Ceci fait que la croissance de la taille des bases de données n'est pas linéaire.
Prenez les forums par exemple, la bête noire des hébergeurs. A chaque nouveau membre, ou chaque nouveau message, c'est beaucoup de cellules qui viennent s'ajouter à la base.
Ce n'est pas la taille qui compte :
-----------------------------------
Vous pouvez avoir une base de données de 20 Gb sur un serveur, elle ne provoque aucune charge tant qu'elle n'est pas utilisée.
En fait, ce n'est pas la taille, mais la façon dont on va utiliser la base de données qui va faire en sorte que les choses fonctionnent normalement ou plantent. La pire fontion est SELECT ALL, malheureusement utilisée de façon systématique par beaucoup de programmeurs parce qu'elle simplifie leur travail.
Quand vous passez un SELECT ALL (ou SELECT *) vous demandez au serveur de prendre les données de votre table et de les mettre en mémoire (RAM) pour un usage immédiat.
Exemple :
---------
Un client a une base de données avec toute la Bible dedans. La taille de table est de 50 Mb. Jusque là, il n'y rien de mal.
Supposons qu'un visiteur du site vienne faire une recherche pour trouver un mot ou une expression dans la Bible. La première chose que fait le script PHP est de faire un SELECT ALL et d'envoyer tout le contenu de la base dans la mémoire. En suite, on traite ces 50 Mb de données avec un script qui va chercher les mots en question. Chaque fois qu'il trouve un mot, il identifie l'endroit où ils se trouve et renvoit le tout au visiteur.
Si le site reçoit 5 visiteurs qui cherchent en même temps, ça peut faire plusieurs centaines de Mb dans la RAM en même temps. Ajoutez à cela que certains scripts sont mal faits et font plusieurs SELECT ALL à chaque fois qu'ils sont exécutés...
Dans ce cas, il suffit qu'un jour le site soit bien fréquenté et c'est la catastrophe.
Peut-on mieux faire ?
---------------------
Certainement. Il y a des sites énormes (Yahoo) je crois qui tournent sous mySQL sans souci.
Reprenons l'exemple de la Bible de tout à l'heure. Imaginons qu'on divise la Bible sur 25 tables différentes. Ca peut être une division réelle ou une division virtuelle. Dans ce dernier cas, on met tout la Bible dans une seule table, mais on va créer un nouvel identifiant, appellé DIV par exemple et qui va
porter des numéros de 1 à 25 le long de notre table.
Le client vient chercher un mot :
On fait SELECT Where DIV=1 : On va donc sélectionner 4% de la table et faire une recherche. Puis, on incrémente le DIV et on cherche dans la partie 2 et ainsi de suite. L'exécution sera très rapide et la mémoire jamais saturée. On traite à chaque fois une quantité raisonnable de données et on recommence.
Encore mieux ?
--------------
On peut par exemple penser que les visiteurs ont tendance à prévilégier certains thèmes à certaines époques. On peut donc créer une base qu'on appelle cache et qui contiendra les précédentes recherches des visiteurs. On peut même faire en sorte que les recherches les plus fréquentes soient associées à des indices
de priorité les classant en haut de la table cache. Ainsi, on peut facilement limiter les recherches dans toute le Bible et renvoyer au visiteur des résultats à une vitesse étonnante.
Autre exemple :
---------------
Voici un autre exemple tiré d'un article Américain parru en 2001:
> L'autre donne l'exemple d'une entreprise qui rencontre des problèmes avec son serveur de bases de données. Le management est prêt à investir des millions pour changer tout le système. Pourtant le problème vient d'un mauvais usage mySQL. Voici un exemple de code :
CREATE TABLE employee (
employee_number char(10) NOT NULL,
firstname varchar(40),
surname varchar(40),
address text,
tel_no varchar(25),
salary int(11),
overtime_rate int(10) NOT NULL
);
Vous reconnaissez tout un bout de script qui crée une table. Dans cette table, on va mettre des employés. Suppsons maintenant qu'on demande à un script de chercher le salaire de l'employé Fred Jones dont le numéro d'immatriculation dans l'entreprise est : 101832
Typiquement, on va faire :
SELECT salary FROM employee WHERE employee_number = '101832';
mySQL n'a aucune idée sur comment trouver cet employé. Il va chercher les enregistrements les uns après les autres. Si l'employé n'existe pas, toute la base données peut y passer avant que ce résultat ne soit annoncé.
Les Index :
-----------
On doit créer une base donnée dans le but est d'indexer la baser de données principale. Cette petite base de données servira comme la page sommaire d'un gros livre. Toutes les requêtes commencent dans la base Index. On y cherche le nom de l'employé et on aura le numéro d'enregistrement dans la base principale.
Supposons que le dossier de l'employé soit à la ligne 9500. Dans la base Index, qui ne comporte que deux colonnes, on aura le nom de l'employé et en face le chiffre 9500. Le script va donc aller directement dans la base principale chercher ce qui se trouve à la ligne 9500.
Le but du jeu est de ne soliciter la base donnée principale qu'avec des requêtes ultra précises. Si la base est trop grande, on peut la diviser en plusieurs parties et créer plusieurs niveaux d'indexation. Comme dans une biliothèque publique vous avez des secteurs, puis des étagères, puis des rangées, puis des livres... de cette façon, on peut avoir une base de 20 Gb mais des requêtes toutes petites qui permettent d'aller puiser ce qu'on veut dedans. Quand vous cherchez un numéro dans l'annuaire, vous ne lisez pas toutes les pages jusqu'à tomber sur le votre !
Cependant, créer une ou plusieurs tables Index exige plus de travail. Vos scripts doivent mettre à jour les Index à chaque fois qu'ils modifient les données de la base principale.
You are at risk !
-----------------
Vous avez un site internet avec une base de données énorme sans la moindre optimisation. Avec deux trois visiteurs elle tourne tant bien que mal en provoquant des charges énormes sur le serveur. Vous n'avez pas beaucoup de visiteurs et vous vous dites que ça va bien comme ça. Mais comme disait Jacques Brel : le monde est plein de polissons! Supposez qu'une personne ou un groupe de personnes n'aiment pas votre site. Quels moyens leur faut-il pour le mettre down ? Rien du tout ! Votre site est au bord du gouffre, il lui suffit d'un petit coup de pouce et il y va. Avec un seul ordinateur et un script qui lance 20 recherches par seconde et votre site est down en 3 secondes de montre.
La fonction recherche :
-----------------------
C'est la fonction la plus dangereuse de toutes pour les bases non optimisées. C'est elle qui justement provoque des SELECT ALL fatals (ou fataux ?). Certains sites la désactivent, d'autres limitent la recherche à une recherche toutes les 30 secondes par membre, d'autre protègent cette fonction avec un pictogramme...
Conclusion :
------------
Mettre les données en vrac dans une base énorme et l'attaquer directement à chaque fois est une mauvaise pratique de programmation. Quand la base est petite, ceci passe encore, mais à partir de quelques dizaines de mégas, ça commence à devenir trop lourd et pénaliser le fonctionnement du server qui l'héberge. Peu importe que vous soyez en dédié ou en mutualisé. Si votre base de données n'est pas optimisée, vous allez tout le temps avoir des soucis avec.
Notre limite à 50 méga :
------------------------
Parce que tout le monde n'est pas expert mySQL, nous limitons la taille à 50 Méga. 50 Mb c'est presque trop pour une base pas optimisée. Même les portails ou les forums que vous téléchargez gratuitement ne sont pas toujours programmés de façon optimale. Quand ils grandissent, leurs failles se voient au grand jour...
