Tags populaires：
Virtualisation sécurité DNS vérification formelle analyse d'atteignabilité erreurs du compilateur conflit de macro extension web framework de développement Graphiques bitmap incohérences d'API Tous les tags

Base de données vieille de 5000 ans : Plus fiable que les bases de données modernes ?

2025-09-06

Une image d'une base de données sumérienne vieille de 5000 ans a poussé l'auteur à réfléchir à la limite supérieure de stockage des dates dans les bases de données. L'image montre une base de données de 3100 avant J.-C. enregistrant des comptes de malt et d'orge, avec une fiabilité bien supérieure à celle des bases de données modernes. Des tests ont révélé que MySQL ne peut pas stocker les dates antérieures à 4713 avant J.-C., tandis que PostgreSQL et SQLite le peuvent. Cela a amené l'auteur à se demander comment stocker des dates encore plus anciennes, comme les registres d'artefacts de musées, suggérant des solutions comme l'utilisation d'horodatages d'époque ou de systèmes personnalisés.

Lire plus
(avi.im)
Développement

Les bases de données peuvent-elles remplacer complètement les caches ?

2025-08-31

Cet article explore la possibilité que les bases de données remplacent complètement les caches. Bien que les bases de données offrent certaines fonctionnalités de cache, telles que les pools de tampons et les réplicas de lecture, les caches excellent dans l'accès aux données à faible latence, en particulier pour les sous-ensembles de données spécifiques et les données précalculées. Pour remplacer les caches, les bases de données doivent relever plusieurs défis : gérer efficacement de nombreuses réplicas de lecture, activer des réplicas de lecture partielles, prioriser des données spécifiques et implémenter un mécanisme efficace de maintenance incrémentale des vues (IVM). L'auteur suggère que la combinaison de l'IVM avec des réplicas de lecture partielles pourrait éventuellement permettre aux bases de données de remplacer partiellement les caches, mais il reste un écart.

Lire plus
(avi.im)
Développement réplicas de lecture

Mode WAL de SQLite : compromis entre durabilité et performance

2025-08-24

Le mode WAL (Write-Ahead Log) de SQLite, souvent utilisé pour un débit d'écriture plus élevé, compromet la durabilité des données par rapport au mode journal par défaut. Le pragma `synchronous` contrôle la fréquence d'appel de fsync ; la valeur par défaut est NORMAL. En mode NORMAL, les fichiers WAL sont synchronisés avant chaque point de contrôle et le fichier de base de données après, mais la plupart des transactions ne comportent pas d'opérations de synchronisation. Pour les applications où la durabilité n'est pas critique, NORMAL est suffisant. Pour une durabilité garantie en cas de panne de courant, `synchronous=FULL` ajoute une synchronisation de fichier WAL après chaque validation de transaction, augmentant la durabilité au détriment de la vitesse d'écriture. Cette explication, motivée par des inquiétudes concernant SurrealDB qui pourrait sacrifier la durabilité pour les performances de référence, clarifie l'approche de SQLite.

Lire plus
(avi.im)
Développement mode WAL durabilité des données

Problème de somme de contrôle en mode WAL de SQLite : perte silencieuse de données

2025-07-25

Cet article explore une faille dans le mécanisme de somme de contrôle de SQLite en mode journalisation anticipée (WAL). Lorsqu’une incohérence de somme de contrôle se produit dans une trame WAL, SQLite supprime silencieusement la trame défectueuse et toutes les trames suivantes, même si elles ne sont pas corrompues. Cette conception, bien qu’intentionnelle, entraîne une perte de données potentielle. L’auteur analyse les raisons sous-jacentes et propose que SQLite génère une erreur lors de la détection de la corruption au lieu de supprimer silencieusement les données, améliorant ainsi l’intégrité des données. La discussion aborde également le contexte d’utilisation de SQLite dans les systèmes embarqués et les appareils mobiles, où la corruption est plus fréquente.

Lire plus
(avi.im)
Développement

SQLite : Une légende incroyable de base de données

2024-12-30

SQLite, la base de données la plus déployée au monde, est maintenue par une équipe de trois personnes, refusant les contributions externes, mais conquérant le monde par ses performances exceptionnelles et sa stabilité. Née sur un navire de guerre américain pour résoudre les problèmes d'indisponibilité du serveur, elle est devenue la pierre angulaire de billions de bases de données. SQLite n'est pas open source, mais plutôt un logiciel du domaine public, avec moins de restrictions que toute licence open source. Son processus de test rigoureux, simulant même des situations extrêmes comme les pannes du système d'exploitation, garantit sa fiabilité extrêmement élevée. Cependant, son modèle économique unique — générer des revenus grâce à un support payant et à des adhésions — est également remarquable. La légende de SQLite réside non seulement dans ses prouesses techniques, mais aussi dans la persévérance et l'innovation qui la sous-tendent.

Lire plus
(avi.im)
Développement légende

Filtres de Bloom : Le secret pour rendre SQLite 10 fois plus rapide

2024-12-22

Des chercheurs ont utilisé intelligemment des filtres de Bloom pour rendre les requêtes analytiques de SQLite 10 fois plus rapides. Ils ont découvert que les jointures en boucle imbriquée de SQLite étaient inefficaces, avec beaucoup de temps consacré aux sondages d'arbres B. En utilisant un filtre de Bloom avant l'opération de jointure pour filtrer rapidement les lignes qui ne correspondent probablement pas, puis en effectuant des sondages d'arbres B uniquement sur les correspondances potentielles, le nombre de sondages a été considérablement réduit. Les filtres de Bloom ont une surcharge mémoire minimale et ont été faciles à intégrer dans le moteur de requête existant de SQLite, ce qui a entraîné une amélioration significative des performances. Cette amélioration a été intégrée à SQLite v3.38.0.

Lire plus
(avi.im)
Développement Filtres de Bloom Optimisation de base de données

Réécriture de SQLite en Rust : Limbo atteint une réduction de 100x de la latence de queue

2024-12-16

Des chercheurs de l'Université d'Helsinki et de Cambridge ont réécrit SQLite en Rust, créant Limbo, un projet utilisant les E/S asynchrones et io_uring pour améliorer considérablement les performances. Grâce aux E/S asynchrones et à la désagrégation du stockage, Limbo réalise une réduction jusqu'à 100x de la latence de queue, particulièrement avantageux dans les environnements serverless multi-locataires. L'amélioration principale provient du remplacement des instructions de bytecode synchrones par leurs équivalents asynchrones, éliminant les blocages et améliorant la concurrence. Les améliorations sont plus marquées aux percentiles élevés, ce qui rend Limbo idéal pour les applications exigeant une haute fiabilité.

Lire plus
(avi.im)
Développement E/S Asynchrone