Manual:External storage/fr

This page is a translated version of the page Manual:External storage and the translation is 97% complete.
Outdated translations are marked like this.

Le stockage externe est une abstraction pour stocker le contenu du wiki (c'est-à-dire ce qui entrerait normalement dans la table text ) en dehors de la base de données standard, éventuellement en appliquant un type de compression donné. Certaines extensions (comme StructuredDiscussions ) peuvent utiliser le stockage externe directement pour stocker d'autres types de données.

Le contenu du stockage externe est adressé avec une URL de la forme <protocole>://<emplacement>/<nom de l'objet>, où le protocole détermine le type de stockage à utiliser. Avant la version 1.32 ces URLs étaient stockées dans le champ old_text de la table text avec old_flags initialisé à external. Depuis la version 1.32 elles sont stockées dans le champ content_address de la table content .

Avantages

La taille de la table text est généralement celle de la plus grande de toutes les tables. Sur les wikis avec des millions de modifications, la table text peut occuper plusieurs gigaoctets.

Étant donné que le contenu de la table text n'est pas modifiable (les modifications apportées aux pages créent de nouvelles révisions et de nouvelles entrées dans la table text, mais les anciennes entrées ne peuvent pas être modifiées), le stockage du contenu dans une base de données différente offre les avantages suivants :

  • séparer les besoins de stockage - Au lieu d’une grande base de données monolithique, le stockage externe peut s’étendre sur plusieurs serveurs, ce qui facilite la migration et l’allocation des disques.
  • performances de la base de données - Le serveur de base de données pour le stockage externe a des besoins en mémoire et en CPU très faibles, car il ne s'agit que d'un magasin et il n'a pas besoin de trop de mise en cache et n'a pas besoin d'effectuer des requêtes complexes. Cela permet au serveur principal de la base de données d'utiliser toute la mémoire disponible pour le cache des autres tables qui peuvent ainsi en bénéficier.
  • sauvegardes - Les sauvegardes de grandes bases de données prennent du temps. Les sauvegardes de la base de données de stockage externe peuvent être effectuées de manière incrémentielle, car les anciennes entrées ne sont pas modifiables. Lorsqu'une base de données de stockage externe s'est suffisamment développée, une nouvelle base de données peut être créée pour un nouveau stockage externe, et l'ancienne base de données peut être mise en lecture seule et supprimée des sauvegardes de routine (elle doit cependant toujours être accessible pour MediaWiki).

Code

ExternalStore est la classe principale pour interagir avec le stockage externe. Vous pouvez utiliser insert ou (plus généralement) insertToDefault pour stocker une donnée et recevoir l'URL à laquelle elle a été stockée ; cette URL peut être utilisée avec fetchFromURL pour récupérer les données.

En interne, ExternalStore interagit avec la sous-classe ExternalStoreMedium correspondant au protocole. ExternalStoreDB, qui est celui couramment utilisé, diffère des autres en ce qu'il offre un traitement spécial lorsque les données stockées sont une sous-classe sérialisée de HistoryBlob ; ces objets peuvent être récupérés avec <protocol>://<location>/<object name>/<item id>, auquel cas le magasin désérialisera l'objet et obtiendra l'élément approprié (en appelant getItem dessus).

En pratique, vous devriez éviter d'utiliser ExternalStorage directement la plupart du temps et utiliser SqlBlobStore (ou une abstraction de niveau encore plus élevé telle que RevisionStore) à la place.

Configuration

Exemple d'initialisation de LocalSettings.php :

$wgExternalStores = [ 'DB' ];
$wgExternalServers = [ 'demoCluster' => [
  [ 'host' => 'primary.example.org', 'user' => 'userM',  'password' =>'pwdM',  'dbname' => 'dbM',  'type' => "mysql", 'load' => 1 ],
  [ 'host' => 'replica1.example.org', 'user' => 'userS1', 'password' =>'pwdS1', 'dbname' => 'dbS1', 'type' => "mysql", 'load' => 1 ],
  [ 'host' => 'replica2.example.org', 'user' => 'userS2', 'password' =>'pwdS2', 'dbname' => 'dbS2', 'type' => "mysql", 'load' => 1 ],
] ];
$wgDefaultExternalStore = [ 'DB://demoCluster' ];
  • la ligne $wgExternalStores indique qu'un dépôt externe DB peut être utilisé. (La partie DB n'est pas un nom arbitraire qui peut être adapté. Doit être DB.) Ceci correspond à la sous-classe ExternalStoreMedium utilisée et au protocole de l'adresse du blob.
  • la ligne $wgExternalServers donne toutes les grappes (clusters) utilisables avec les nœuds utilisables sur chacun d'eux. Les clés du tableau de niveau supérieur identifient le nom d'une grappe (l'exemple ci-dessus n'en définit qu'une seule. Il a pour nom demoCluster). Les valeurs pour ces clés sont encore des tableaux. Elles contiennent les spécifications des nœuds individuels. Le premier nœud est considéré comme primaire. Toutes les écritures dans la base de données sont effectuées via ce nœud primaire. Aucun nœud ou plusieurs nœuds peuvent suivre. (Dans l'exemple ci-dessus, nous voyons deux nœuds répliqués). Chaque noeud possède ses propres host, user, password, dbname et type comme montré dans l'exemple. Le paramètre load permet de spécifier la quantité de charge acceptée par ce nœud.
  • la ligne $wgDefaultExternalStore donne tous les dépôts externes qui peuvent être utilisés pour stocker le nouveau texte. Si vous omettez cette ligne, le stockage externe sera accessible uniquement en lecture et les nouveaux textes iront dans la base de données par défaut (c'est à dire la même base de données contenant la page de stockage, la révision, les données d'image mais pas la grappe).

Pour la configuration d'une ferme de wikis multi-primaires (anciennement appelée multi-maîtres) comme Wikimedia, envisagez d'utiliser LBFactory_Multi à la place.

Configuration de la base de données

Pour l'exemple de configuration ci-dessus, vous devrez :

  1. Créer la base de données dbM sur l'hôte primary.example.org
  2. Exécuter le script SQL maintenance/storage/blobs.sql sur la base de données dbM de l'hôte primary.example.org. N'utilisez pas maintenance/sql.php pour cette tâche, car cela ajoutera les tables requises à votre base de données par défaut (c'est-à-dire : la page contenant la base de données, la révision, les données d'image) et pas à dbM. Si vous n'êtes pas certains de la manière d'exécuter le script SQL sur la base de données dbM et l'hôte primary.example.org, veuillez consulter la documentation de votre base de données.
  3. Configurez la réplication (consultez la documentation de votre base de données pour savoir comment configurer la réplication) vers dbS1 sur l'hôte replica1.example.org, et
  4. Configurer la réplication vers dbS2 sur l'hôte replica2.example.org.

Scripts de maintenance

Plusieurs scripts de maintenance existent pour déplacer le contenu vers le dépôt externe :

Voir aussi