Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Considérations sur l’importation de données pour MariaDB

Le contenu suivant présente des informations techniques sur le chargement de données dans MariaDB. Ce contenu est destiné aux utilisateurs qui connaissent bien l’architecture de serveur MariaDB.

Journalisation binaire

L’activation de la journalisation binaire réduit les performances de chargement des données et nécessite jusqu’à quatre fois plus d’espace disque que la journalisation désactivée. La taille des transactions utilisées pour charger les données influe directement sur les performances du système et les besoins en espace disque. Les transactions plus importantes nécessitent davantage de ressources.

Taille de la transaction

La taille des transactions influence les aspects suivants du chargement de données MariaDB :

Cette section décrit comment la taille de la transaction influe sur la journalisation binaire. En outre, elle plaide en faveur de la désactivation de cette même journalisation lors de chargements de données volumineux. Vous pouvez activer et désactiver la journalisation binaire en définissant la période de rétention des sauvegardes automatiques Amazon RDS. Les valeurs différentes de zéro activent la journalisation binaire, tandis que la valeur zéro la désactive. Pour plus d’informations, consultez Période de rétention des sauvegardes.

Cette section décrit également l’impact des transactions volumineuses sur InnoDB et pourquoi il est important que les transactions conservent une petite taille.

Petites transactions

Pour les petites transactions, la journalisation binaire multiplie par deux le nombre d'écritures sur disque requises pour charger les données. Elle peut ainsi affecter gravement les performances des autres sessions de base de données et accroître le temps requis pour charger les données. La dégradation subie dépend en partie des facteurs suivants :

Les journaux binaires consomment aussi un espace disque approximativement égal à la quantité de données chargées jusqu’à ce que les journaux soient sauvegardés et supprimés. Amazon RDS réduit cette consommation en sauvegardant et en supprimant fréquemment les journaux binaires.

Transactions volumineuses

Pour les transactions importantes, la journalisation binaire triple les IOPS et l’utilisation du disque pour les raisons suivantes :

Ce processus crée trois copies des données :

Chaque opération d’écriture entraîne des E/S supplémentaires, ce qui a un impact supplémentaire sur les performances.

De ce fait, la journalisation binaire nécessite trois fois plus d’espace disque que la journalisation désactivée. Par exemple, le chargement de 10 GiB de données en une seule transaction crée trois copies :

L’espace disque temporaire total requis est de 30 GiB.

Considérations importantes relatives à l’espace disque :

Si vous utilisez LOAD DATA LOCAL INFILE pour charger les données, la récupération des données crée une quatrième copie au cas où la base de données devrait être récupérée à partir d’une sauvegarde exécutée avant le chargement. Pendant la récupération, MariaDB extrait les données du journal binaire dans un fichier plat. MariaDB exécute ensuite LOAD DATA LOCAL INFILE. Sur la base de l’exemple précédent, cette récupération nécessite un espace disque temporaire total de 40 GiB, soit 10 Gib chacun pour la table, le cache, le journal et le fichier local. Si l’espace disque disponible est inférieur à 40 GiB, la restauration échoue.

Optimisation des charges de données importantes

Pour les chargements de données volumineux, désactivez la journalisation binaire afin de réduire la surcharge et les contraintes d’espace disque. Vous pouvez désactiver la journalisation binaire en définissant la période de rétention des sauvegardes sur 0. Une fois le chargement terminé, restaurez la période de rétention des sauvegardes sur la valeur appropriée différente de zéro. Pour plus d’informations, consultez Modification d'une instance de base de données Amazon RDS et la Période de rétention des sauvegardes dans la table des paramètres.

Avant de charger les données, nous vous recommandons de créer un instantané de base de données. Pour plus d’informations, consultez Gestion des sauvegardes manuelles.

InnoDB

Les informations suivantes sur les options de journalisation des annulations et de récupération permettent de limiter la taille des transactions InnoDB afin d’optimiser les performances de la base de données.

Compréhension de la journalisation des annulations par InnoDB

L’annulation est un mécanisme de journalisation qui permet l’annulation des transactions et prend en charge le contrôle de simultanéité multiversion (MVCC, Multi-Version Concurrency Control).

Pour les versions 10.11 et antérieures de MariaDB, les journaux d’annulation sont stockés dans le tablespace système InnoDB (généralement ibdata1) et conservés jusqu’à ce que le thread de purge les supprime. Ainsi, les transactions de chargements de données volumineux peuvent entraîner un agrandissement conséquent du tablespace système et utiliser de l’espace disque que vous ne pouvez pas revendiquer sans recréer la base de données.

Pour toutes les versions de MariaDB, le thread de purge doit attendre que la plus ancienne transaction active soit validée ou annulée pour supprimer les journaux d’annulation. Si la base de données traite d’autres transactions pendant le chargement, leurs journaux d’annulation s’accumulent également et ne peuvent pas être supprimés, même si les transactions sont validées et qu’aucune transaction ne nécessite les journaux d’annulation pour MVCC. Dans ce cas, toutes les transactions, y compris celles en lecture seule, ralentissent. Ce ralentissement se produit parce que toutes les transactions accèdent à toutes les lignes modifiées par toutes les transactions, et pas seulement par les transactions de chargement. En effet, les transactions doivent parcourir les journaux d’annulation dont les transactions de chargement de longue durée ont empêché la purge lors du nettoyage du journal d’annulation. Cela affecte les performances de toute opération accédant aux lignes modifiées.

Options de récupération de transactions InnoDB

Bien qu’InnoDB optimise les opérations de validation, les annulations de transactions importantes sont lentes. Pour accélérer la restauration, effectuez une point-in-time restauration ou restaurez un instantané de base de données. Pour plus d’informations, consultez Point-in-time rétablissement et Restauration d’une instance de base de données.

formats d’importation de données

MariaDB prend en charge deux formats d’importation de données : fichiers plats et SQL. Passez en revue les informations relatives à chaque format afin de déterminer l’option la mieux adaptée à vos besoins.

Fichiers plats

Pour les petites transactions, chargez des fichiers plats avec LOAD DATA LOCAL INFILE. Ce format d’importation de données offre les avantages suivants par rapport à l’utilisation de SQL :

LOAD DATA LOCAL INFILE charge la totalité du fichier plat comme une seule transaction. Maintenez une taille réduite pour chaque fichier afin de bénéficier des avantages suivants :

Les transactions importantes réduisent les avantages liés à l’utilisation de LOAD DATA LOCAL INFILE pour importer des données. Lorsque vous ne pouvez pas diviser une grande quantité de données en fichiers plus petits, pensez à utiliser SQL.

SQL

SQL possède un avantage principal sur les fichiers plats : vous pouvez facilement conserver une taille réduite pour les transactions. Cependant, le chargement avec SQL peut prendre beaucoup plus de temps que les fichiers plats. De plus, après un échec, il peut être difficile de définir à quel endroit reprendre : vous ne pouvez pas redémarrer les fichiers mariadb-dump. Si une défaillance se produit lors du chargement d’un fichier mariadb-dump, vous devez modifier ou remplacer le fichier avant que le chargement puisse reprendre. Sinon, après avoir corrigé la cause de la défaillance, vous pouvez restaurer à un instant dans le passé avant le chargement et renvoyer le fichier. Pour plus d’informations, consultez Point-in-time rétablissement.

Utilisation d’instantanés de base de données Amazon RDS pour les points de contrôle de base de données

Si vous chargez des données sur de longues durées, par exemple des heures ou des jours, sans journalisation binaire, utilisez des instantanés de base de données pour fournir des points de contrôle périodiques en matière de sécurité des données. Chaque instantané de base de données crée une copie cohérente de votre instance de base de données, qui sert de point de récupération lors de défaillances du système ou d’événements de corruption de données. Les instantanés de base de données étant rapides, les points de contrôle fréquents ont un impact minimal sur les performances de chargement. Vous pouvez supprimer des instantanés de base de données précédents sans affecter la durabilité ou les capacités de récupération de la base de données. Pour plus d’informations sur les instantanés de base de données, consultez Gestion des sauvegardes manuelles.

Réduction des temps de chargement des bases de données

Voici des conseils supplémentaires pour réduire les temps de chargement :