Les bibliothèques libmdbx 0.10.4 (MDBX) ont été publiées avec la mise en œuvre d'une base de données clé-valeur intégrée compacte hautes performances et de la bibliothèque libfpta 0.3.9 (FPTA) associée, qui implémente une représentation tabulaire des données avec des index secondaires et composites. au-dessus de MDBX. Les deux bibliothèques sont distribuées sous des licences approuvées OSI. Tous les systèmes d'exploitation et architectures actuels sont pris en charge, ainsi que le russe Elbrus 2000.
Historiquement, libmdbx est une refonte en profondeur du SGBD LMDB et est supérieur à son ancêtre en termes de fiabilité, de fonctionnalités et de performances. Par rapport à LMDB, libmdbx met l'accent sur la qualité du code, la stabilité de l'API, les tests et les contrôles automatisés. Un utilitaire permettant de vérifier l'intégrité de la structure de la base de données avec certaines capacités de récupération est fourni.
Sur le plan technologique, libmdbx offre ACID, une sérialisation forte des modifications et des lectures non bloquantes avec une mise à l'échelle linéaire sur les cœurs de processeur. La compactification automatique, la gestion automatique de la taille de la base de données et l'estimation des requêtes de plage sont prises en charge. Depuis 2016, des projets sont financés par Positive Technologies et depuis 2017 sont utilisés dans ses produits.
libmdbx propose une API C++, ainsi que des liaisons de langage prises en charge par les passionnés pour Rust, Haskell, Python, NodeJS, Ruby, Go et Nim. Pour libfpta, seule la description de l'API est publiquement disponible sous la forme d'un fichier d'en-tête C/C++.
Innovations majeures, améliorations et corrections ajoutées depuis la précédente news du 9 mai :
- Permet des builds reproductibles.
- Correction d'un bug à cause duquel, dans de très rares circonstances, une boucle/un gel pouvait se produire lors d'une validation de transaction. Le problème a été identifié par les spécialistes de Positive Tecnologies lors de tests internes de leurs propres produits.
- Les tests ont été améliorés et les scénarios de test ont été étendus pour vérifier tous les états non isomorphes accessibles de l'arborescence des pages et du contenu GC à l'intérieur de la base de données.
- Dans l'API C++, un "nosauf" supplémentaire a été corrigé, des surcharges supplémentaires ont été ajoutées pour la méthode "cursor::erase()", l'implémentation des tampons a été épargnée par l'utilisation de "std::string" pour assurer l'alignement (pertinent pour CLANG libstdc++).
- Une régression dans l'algorithme de déversement de pages sales (éjection sélective des pages de base de données modifiées) qui se manifestait par une rare erreur inattendue MDBX_PROBLEM lors de la modification de données dans des transactions volumineuses a été éliminée.
- Un test de phasage a été réalisé avec l'ajout d'un certain nombre de contrôles pour garantir la stabilité en cas de dommages intentionnels à la base de données.
- Correction des avertissements mineurs, des problèmes UndefinedBehaviorSanitizer et Coverity Scan.
- Correction de la vérification de l'indicateur interne « P_DIRTY » obsolète et n'est plus utilisé dans les pages imbriquées à l'intérieur des images de base de données créées par les anciennes versions de la bibliothèque.
- Dans les scripts CMake, la recherche des composants du compilateur requis pour LTO (optimisation du temps de liaison) a été améliorée.
- Le nombre maximum de lecteurs simultanés a été augmenté à 32767.
- Amélioration des performances lors de l'utilisation de Valgrind et AddressSanitizer.
- Sous Windows, l'utilisation récursive du verrouillage SRW lors du travail en mode MDBX_NOTLS (sans utiliser le stockage local des threads) a été éliminée, la génération de bootid a été corrigée si l'heure système a changé, la détection WSL1 et WSL2 a été améliorée et la possibilité de ouvrir une base de données sur Plan 9 monté via DrvFS a été ajouté.
- Au total, plus de 160 modifications ont été apportées à 57 fichiers, environ 5000 2500 lignes ont été ajoutées et environ XNUMX ont été supprimées.
Je tiens particulièrement à remercier l'équipe du projet Erigon (écosystème Ethereum) pour son aide dans les tests dans des scénarios d'utilisation extrêmes. Il est significatif qu'en cinq mois depuis la sortie de libmdbx v0.10.0, avec un volume de base de données de 1 à 2 To dans chaque installation d'Erigon (utilisé sur 7 % des nœuds Ethereum), seuls trois rapports de corruption de base de données ont été reçus, tous qui s'est produit pour des raisons externes, et non des erreurs logicielles : dans deux cas, la cause était des pannes de RAM, dans le troisième, une erreur de réinitialisation des données dans une configuration spécifique du sous-système de stockage utilisant BTRFS.
Source: opennet.ru