Manual:Database access/fr

Cet article donne un aperçu de l'accès aux bases de données et des problèmes généraux liés à ces bases dans MediaWiki.

Lorsque vous codez dans MediaWiki, vous accèdez normalement à la base de données uniquement par des fonctions dédiées de MediaWiki.

Schéma des bases de données
Pour les informations concernant le schéma de la base de données MediaWiki, telles que la description des tables et leur contenu, voir. Historiquement dans MediaWiki, ceci était aussi documenté dans, néanmoins à partir de MediaWiki 1.35, cela sera déplacé progressivement dans   comme partie de l'initiative du schéma abstrait (Abstract Schema initiative). Cela signifie que  est transformé en   par un, ce qui le rend plus facile à générer les fichiers du schéma pour prendre en charge différents moteurs de base de données.

Utiliser sql.php
MediaWiki fournit un script de maintenance pour accéder à la base de données. Exécutez depuis le répertoire de maintenance :

Vous pouvez ensuite émettre des requêtes vers la base de données. Vous pouvez aussi fournir un nom de fichier que MediaWiki exécutera, en substituant les variables spéciales de MediaWiki selon le cas. Pour plus d'informations, voir.

Cela fonctionne avec tout serveur de base de données. Néanmoins l'invite n'a pas toutes les fonctionnalités du client de commandes en mode ligne fourni avec votre base de données.

Utiliser le client de commande en ligne mysql
Votre nom d'utilisateur et mot de passe MySQL se trouvent dans le fichier LocalSettings.php, par exemple :

Avec SSH, connectez-vous ainsi :

en remplaçant  et   par l'information contenue dans le fichier. On vous demandera ensuite votre mot de passe  avant d'afficher l'invite.

Niveau d'abstraction de la base de données
MediaWiki fournit un niveau d'abstraction de la base de données. Sauf si vous travaillez sur le niveau d'abstraction, vous n'avez en aucun cas à appeler directement les fonctions PHP de la base de données (telles que  ou  .)

Le niveau d'abstraction est accessible via la classe. Une instance de cette classe peut être obtenue en appelant  (de préférence) ou   sur un   injecté. La fonction  est en fin de vie et ne doit pas être utilisée dans le nouveau code. Une autre possibilité est typiquement d'être appelé avec un seul paramètre, qui est la constante  (pour les demandes de lecture) ou   (pour les demandes d'écriture et les lectures qui ont besoin absolument de l'information la plus récente). La distinction entre master et réplicat est importante dans un environnement multi-database, tel que Wikimedia. Voir la section des fonctions conteneur ci-après pour connaître les possibilités d'utilisation de l'objet  qui est renvoyé.

Les conteneurs du résultat des requêtes select sont des tableaux dont les clés sont des entiers qui commencent à 1. Pour faire une demande de lecture, le code suivant suffit habituellement :

""

Pour une requête d'écriture, utiliser un code similaire à :

""

Nous utilisons la convention pour la lecture et  pour l'écriture afin de vous aider à suivre le cas où l'objet base de données est un réplicat (lecture seule) ou un master (lecture/écriture). Si vous écrivez dans un replica, le monde explosera. Ou pour être précis, une requête suivante d'écriture qui a réussi sur le master peut échouer lors de la duplication sur le réplicat parce que la clé est encore définie. La duplication sur le réplicat va s'arrêter et la réparation de la base de données peut prendre des heures avant de revenir en ligne. En initialisant read_only dans my.cnf pour le réplicat, vous éviterez ce scenario, mais étant donné les conséquences désastreuses, nous préférons avoir autant de contrôles que possible.

Fonctions conteneur
Nous fournissons une fonction query pour le SQL brut, mais les fonctions conteneur telles que select et insert sont habituellement plus pratiques. Elles peuvent prendre en compte des éléments tels que les préfixes de tables et l'échappement des caractères dans certaines situations. Si vous devez réaliser votre propre SQL, veuillez lire la documentation concernant tableName et addQuotes. Les deux vous seront nécessaires. Gardez à l'esprit que le fait de ne pas utiliser ''addQuotes correctement peut entraîner des failles importantes dans la sécurité de votre wiki.

Une autre raison importante pour utiliser les méthodes de haut niveau plutôt que de construire vos propres requêtes est pour vous assurer que votre code s'exécutera correctement indépendamment du type de base de données. Actuellement MySQL et MariaDB sont les mieux prises en charge. SQLite bénéficie également d'un bon support mais il est beaucoup plus lent que MySQL et MariaDB. Le support de PostgreSQL existe également mais il n'est pas aussi stable que pour MySQL.

Dans la suite, nous listons les fonctions conteneur disponibles. Pour une description détaillée des paramètres des fonctions conteneur, voir les documents concernant la classe. Voir en particulier  pour l'explication des paramètres suivants, utilisés dans les autres fonctions conteneur : ,  ,  ,  ,  , et.

Fonction conteneur : select
La fonction select fournit l'interface MediaWiki pour une instruction SELECT. Les composants de l'instruction SELECT sont codés comme les paramètres de la fonction select. Exemple :

Cet exemple correspond à la requête :

Les JOINs sont également possibles; par exemple :

Cet exemple correspond à la requête :

fournit un exemple sur la manière d'utiliser les alias de tables dans les requêtes.

Les arguments sont soit des valeurs uniques (comme 'category' ou 'cat_pages > 0'), soit des tableaux si plus d'une valeur est fournie pour une position d'argument (tel que ['cat_pages > 0', $myNextCond]). If you pass in strings to the third or fifth argument, you must manually use Database::addQuotes on your values as you construct the string, as the wrapper will not do this for you. The values for table names (1st argument) or field names (2nd argument) must not be user controlled. The array construction for $conds is somewhat limited; it can only do equality and  relationships (i.e. WHERE key = 'value').

Vous pouvez accéder séparément à chaque ligne du résultat en utilisant une boucle foreach. Une fois l'objet ligne obtenu, vous pouvez utiliser l'opérateur  pour accéder à un champ particulier. Un exemple complet serait :

Which will put an alphabetical list of categories with how many entries each category has in the variable $output. If you are outputting as HTML, ensure to escape values from the database with

Fonctions pratiques
Pour être compatible avec PostgreSQL, les IDs d'insertion sont obtenus en utilisant nextSequenceValue et insertId. The parameter for nextSequenceValue can be obtained from the  statement in   and always follows the format of x_y_seq, with x being the table name (e.g. page) and y being the primary key (e.g. page_id), e.g. page_page_id_seq. Par exemple :

For some other useful functions, e.g. affectedRows, numRows, etc., see Manual:Database.php.

Optimisation de la requête de base
MediaWiki developers who need to write DB queries should have some understanding of databases and the performance issues associated with them. Les correctifs contenant des fonctions particulièrement lentes ne seront pas acceptés. Unindexed queries are generally not welcome in MediaWiki, except in special pages derived from QueryPage. It's a common pitfall for new developers to submit code containing SQL queries which examine huge numbers of rows. Pensez que COUNT(*) vaut O(N); compter le nombre de lignes dans une table c'est comme compter des grains dans un seau.

Compatibilité arrère
Often, due to design changes to the DB, different DB accesses are necessary to ensure backward compatibility. Ceci peut être réalisé par exemple à l'aide des variables globales et.

Réplication
Large installations of MediaWiki such as Wikipedia, use a large set of replica MySQL servers replicating writes made to a master MySQL server. Il est important de comprendre les problèmes liés à ce paramètre si vous souhaitez écrire du code pour Wikipedia.

C'est souvent le cas où le meilleur algorithme à utiliser pour une tâche donnée dépend du fait que la réplication est utilisée ou pas. Due to our unabashed Wikipedia-centrism, we often just use the replication-friendly version, but if you like, you can use  to check to see if replication is in use.

Latence
La latence apparaît principalement lorsqu'un grand nombre d'écritures est envoyé au master. Les écritures sur le master sont exécutées en parallèle mais sont faites en série quand elles sont dupliquées sur les réplicats. Le master enregistre la reqête dans le journal (binlog) quand la transacton est validée (commit). Les réplcas scrutent le binlog et démarrent l'exécution de la requête dès qu'elle apparaît. Ils peuvent répondre aux demandes de lecture en même temps qu'ils traitent une requête d'écriture mais ils ne lisent plus rien dans le binlog et ne traitent donc pas d'autres écritures. Cela signifie que si la demande d'écriture a besoin de temps pour s'exécuter, les réplicats vont attendre le master, le temps qu'il termine sa demande d'écriture.

La latence peut s'allonger quand la charge due aux lectures trop nombreuses augmente. Le partage de charge dans MediaWiki arrête d'envoyer les lectures au réplicat lorsque ce décalage dépasse 30 secondes. Si les seuils de charge sont mal positionnés, ou s'il y a trop de charge habituellement, cela peut faire qu'un réplicat soit toujours décalé d'environ 30 secondes.

Si tous les réplicats sont décalés de plus de 30 secondes (selon la valeur de ), MediaWiki arrête d'écrire dans la base de données. Toutes les modifications et autres opérations d'écriture sont refusées et une erreur est renvoyée à l'utilisateur. Ceci laisse aux réplicats une chance de se mettre à jour. Avant que nous ayons ce mécanisme, les réplicats étaient régulièrement à la traîne de quelques minutes, ce qui rendait difficile la relecture des modifications récentes.

In addition to this, MediaWiki attempts to ensure that the user sees events occurring on the wiki in chronological order. A few seconds of lag can be tolerated, as long as the user sees a consistent picture from subsequent requests. This is done by saving the master binlog position in the session, and then at the start of each request, waiting for the replica to catch up to that position before doing any reads from it. Si ce délai expire, les lectures sont autorisées mais la requête est considérée être en mode réplicat différé. Le mode réplicat différé peut être vérifié en appelant. La seule conséquence pratique actuellement est l'affichage d'un avertissement au bas de la page.

Shell users can check replication lag with ; the other users with the API.

Databases often have their own monitoring systems in place as well, see for instance MariaDB (Wikimedia) and wikitech:Help:Toolforge/Database (Wikimedia Cloud VPS).

Pour éviter la latence
To avoid excessive lag, queries that write large numbers of rows should be split up, generally to write one row at a time. Multi-row INSERT ... SELECT queries are the worst offenders and should be avoided altogether. Au lieu de cela, faites d'abord le select puis l'insert.

Even small writes can cause lag if they are done at a very high speed and replication is unable to keep up. Cela arrive le plus souvent dans les scripts de maintenance. Pour empêcher cela vous devez appeler  régulièrement après quelques centaines d'écritures. Most scripts make the exact number configurable:

Travailler avec la latence
Despite our best efforts, it's not practical to guarantee a low-lag environment. Replication lag will usually be less than one second, but may occasionally be up to 30 seconds. For scalability, it's very important to keep load on the master low, so simply sending all your queries to the master is not the answer. So when you have a genuine need for up-to-date data, the following approach is advised:


 * 1) Do a quick query to the master for a sequence number or timestamp
 * 2) Run the full query on the replica and check if it matches the data you got from the master
 * 3) If it doesn't, run the full query on the master

To avoid swamping the master every time the replicas lag, use of this approach should be kept to a minimum. Dans la plupart des cas, lisez simplement sur le réplicat et laissez l'utilisateur gérer le retard.

Etreinte fatale
Due to the high write rate on Wikipedia (and some other wikis), MediaWiki developers need to be very careful to structure their writes to avoid long-lasting locks. By default, MediaWiki opens a transaction at the first query, and commits it before the output is sent. Les verrous seront maintenus à partir du moment où la requête est faite et jusqu'à la validation (commit). Par conséquent vous pouvez réduire le temps de blocage en réalisant le maximum de traitement possible avant de lancer les requêtes d'écriture. Les opérations de mise à jour qui n'ont pas besoin de la base de données peuvent être repoussées jusqu'après le commit en ajoutant un objet à.

Often this approach is not good enough, and it becomes necessary to enclose small groups of queries in their own transaction. Utilisez la syntaxe suivante :

Use of locking reads (e.g. the FOR UPDATE clause) is not advised. They are poorly implemented in InnoDB and will cause regular deadlock errors. It's also surprisingly easy to cripple the wiki with lock contention.

Instead of locking reads, combine your existence checks into your write queries, by using an appropriate condition in the WHERE clause of an UPDATE, or by using unique indexes in combination with INSERT IGNORE. Then use the affected row count to see if the query succeeded.

Schéma de la base de données
Don't forget about indexes when designing databases, things may work smoothly on your test wiki with a dozen of pages, but will bring a real wiki to a halt. Voir ci-dessus pour les détails.

For naming conventions, see Manual:Coding conventions/Database.

Compatibilité SQLite
When writing MySQL table definitions or upgrade patches, it is important to remember that SQLite shares MySQL's schema, but that works only if definitions are written in a specific way:


 * Primary keys must be declared within main table declaration, but normal keys should be added separately with CREATE INDEX:

However, primary keys spanning over more than one field should be included in the main table definition:


 * Don't add more than one column per statement:


 * Set explicit defaults when adding NOT NULL columns:

You can run basic compatibility checks with:



Or, if you need to test an update patch, both:


 * (avec le nouveau tables.sql)
 * Since DB patches update the tables.sql file as well, for this one you should pass in the pre-commit version of tables.sql (the file with the full DB definition). Otherwise, you can get an error if you e.g. drop an index (since it already doesn't exist in tables.sql because you just removed it).
 * Since DB patches update the tables.sql file as well, for this one you should pass in the pre-commit version of tables.sql (the file with the full DB definition). Otherwise, you can get an error if you e.g. drop an index (since it already doesn't exist in tables.sql because you just removed it).

Ce qui précède suppose que vous êtes dans $IP/maintenance/, sinon passez le chemin complet du ficher. Pour les correctifs des extensions, utiliser l'équivalent de ces fichiers pour les extensions.

Voir aussi

 * &mdash; If an extension requires changes to the database when MediaWiki is updated, that can be done with this hook. Users can then update their wiki by running.