SQLite : mode Wal2

 (sqlite.org)
10 points par GN⁺ 2024-01-16 | 1 commentaires | Partager sur WhatsApp

Activation/désactivation du mode Wal2

  • Le mode "Wal2" de SQLite est très similaire au mode "wal (Write-Ahead Logging)".
  • Pour basculer une base de données en mode wal2, utilisez la commande PRAGMA journal_mode = wal2;.
  • Il n’est pas possible de passer directement du mode "wal" au mode "wal2" ; il faut d’abord revenir au mode rollback.
  • Pour convertir une base de données en mode wal vers le mode wal2, utilisez PRAGMA journal_mode = delete; puis PRAGMA journal_mode = wal2;.
  • Une base de données en mode wal2 n’est accessible qu’avec une version de SQLite compilée à partir de cette branche.
  • Si vous essayez d’utiliser une autre version de SQLite, l’erreur SQLITE_NOTADB se produit.
  • Pour repasser une base de données en mode wal2 au mode rollback afin qu’elle soit accessible depuis toutes les versions de SQLite, utilisez la commande PRAGMA journal_mode = delete;.

Avantages du mode Wal2

  • Dans le mode wal existant, lorsqu’un writer écrit des données dans la base, il ne modifie pas directement le fichier de base de données mais ajoute les nouvelles données au fichier "-wal".
  • Les lectures récupèrent les données à la fois dans le fichier de base d’origine et dans le fichier "-wal".
  • À un certain moment, les données sont copiées du fichier "-wal" vers le fichier de base ; cela s’appelle un "checkpoint".
  • Le checkpoint peut être exécuté explicitement via PRAGMA wal_checkpoint ou sqlite3_wal_checkpoint_v2(), ou automatiquement en configurant PRAGMA wal_autocheckpoint (comportement par défaut).
  • Le checkpointer ne bloque pas le writer, et le writer ne bloque pas non plus le checkpointer.
  • Mais si le writer écrit dans la base pendant un checkpoint, les nouvelles données sont ajoutées à la fin du fichier wal, ce qui peut faire grossir continuellement le fichier wal.
  • En mode wal2, même si le checkpointer n’a pas l’occasion de terminer sans être perturbé, il n’y a pas de problème de croissance illimitée du fichier wal.
  • Le mode wal2 utilise deux fichiers wal au lieu d’un seul ("-wal" et "-wal2").
  • Lorsque des données sont écrites, le writer commence à ajouter les nouvelles données dans le premier fichier wal.
  • Quand le premier fichier wal devient suffisamment gros, le writer commence à ajouter les données dans le second fichier wal.
  • Le premier fichier wal peut alors être checkpointé, puis lorsque le second fichier wal devient suffisamment gros et que le premier a été checkpointé, l’écriture revient au premier fichier.

Programmation applicative

  • Du point de vue de l’utilisateur, la principale différence entre les modes wal et wal2 concerne le checkpoint.
  • En mode wal, on peut tenter un checkpoint à tout moment, mais en mode wal2, le checkpoint n’est possible qu’après que le writer a basculé vers l’"autre" fichier wal.
  • En mode wal, après la validation d’une transaction, le wal-hook (callback) est appelé avec comme argument le nombre total de pages du fichier wal.
  • En mode wal2, le wal-hook est appelé avec comme argument le nombre total de pages non checkpointées dans les deux fichiers wal, ou avec 0 si l’"autre" fichier wal est vide ou déjà checkpointé.
  • Il est recommandé aux clients d’utiliser pour une base de données en mode wal2 la même stratégie de checkpoint qu’en mode wal.
  • Le wal-hook est appelé après que la transaction a été commit sur disque et que le verrou de la base a été libéré, mais cela se produit à l’intérieur de l’appel sqlite3_step().
  • Dans le système BEGIN CONCURRENT, au lieu d’exécuter un checkpoint dans le wal-hook, on peut utiliser un thread qui diffère cette opération jusqu’à ce que le mutex de l’application soit libéré.

Avis de GN⁺

  • Le mode wal2 de SQLite introduit une nouvelle méthode de journalisation qui améliore la concurrence et l’efficacité de la base de données.
  • Résoudre le problème de croissance infinie du fichier wal est important pour améliorer la stabilité et les performances du système.
  • Avec l’introduction du mode wal2, les développeurs doivent repenser leur stratégie de checkpoint de base de données et implémenter une logique de checkpoint adaptée pour une meilleure concurrence.

À lire aussi

1 commentaires

 
GN⁺ 2024-01-16
Commentaires sur Hacker News

  • En mode WAL2, deux fichiers WAL sont utilisés au lieu d’un. Les fichiers sont nommés "<base de données>-wal" et "<base de données>-wal2". Lorsque des données sont écrites dans la base, les opérations d’écriture commencent par ajouter les nouvelles données au premier fichier WAL. Quand le premier fichier WAL devient suffisamment gros, les écritures basculent vers l’ajout de données dans le second fichier WAL. À ce moment-là, le premier fichier WAL peut être checkpointé (puis réécrit ensuite), et lorsque le second fichier WAL devient à son tour suffisamment gros et que le premier a été checkpointé, les écritures reviennent au premier fichier WAL. Ce processus continue ainsi.

    • Cette approche paraît tellement logique qu’il est difficile de comprendre pourquoi le mode WAL n’a pas été implémenté ainsi dès le départ. C’était peut-être considéré comme une optimisation prématurée.
    • J’espère que ce mode deviendra largement disponible.

  • Bedrock

    • Bedrock est une branche plus intéressante.
    • Elle inclut les fonctionnalités WAL2 + CONCURRENT.
    • C’est la branche qu’Expensify utilise pour monter jusqu’à 4M QPS sur un nœud unique (il y a 6 ans).

  • Lien vers le primitive left-right, une technique similaire au mode WAL2.

    • Cette technique est antérieure à l’implémentation liée, mais a été redécouverte indépendamment, et a notamment été écrite pour prendre en charge une autre base de données SQL haute performance appelée Noria.

  • En mode WAL2, deux fichiers WAL sont utilisés au lieu d’un. Les fichiers sont nommés "<base de données>-wal" et "<base de données>-wal2".

    • Je me demande combien de personnes vont supprimer le fichier wal, en pensant qu’il est résiduel puisqu’on est passé à wal2.

  • Microsoft SQL Server utilise une architecture similaire, mais alloue des Virtual Log Files (VLF) à l’intérieur du fichier journal physique (sur disque) plutôt que d’utiliser des fichiers journaux séparés. Les VLF sont alloués dans un ring buffer et peuvent se compter par milliers.

  • On voit bien que cette fonctionnalité n’est pas encore sortie.

  • J’ai toujours été inquiet du fait que le WAL existe pour préserver l’intégrité des données et aider à la récupération après crash. Pourtant, le fichier lui-même est écrit par lots (et validé de manière fiable sur disque), et non après chaque modification de la base, afin de gagner en performances. Est-ce que cela ne va pas à l’encontre de son objectif ? Je n’ai jamais trouvé de réponse à ce sujet, de manière générale et pas seulement spécifique aux bases de données.

  • Je me demande quel impact cela aura sur les nouveaux systèmes SQLite distribués comme Litestream.

  • Donc, en gros, c’est du double buffering pour une base de données ? Ça se tient.

  • Le mode WAL2 a été inclus dans les benchmarks de la recherche sur le backend HC-tree.