La biblioteca libmdbx 0.10.4 (MDBX) se lanzó con la implementación de una base de datos clave-valor integrada compacta de alto rendimiento y la biblioteca asociada libfpta 0.3.9 (FPTA), que implementa una representación tabular de datos con índices secundarios y compuestos. encima de MDBX. Ambas bibliotecas se distribuyen bajo licencias aprobadas por OSI. Se admiten todos los sistemas operativos y arquitecturas actuales, así como el ruso Elbrus 2000.
Históricamente, libmdbx es una profunda reelaboración del DBMS LMDB y es superior a su antecesor en confiabilidad, conjunto de características y rendimiento. En comparación con LMDB, libmdbx pone mucho énfasis en la calidad del código, la estabilidad de la API, las pruebas y las comprobaciones automatizadas. Se proporciona una utilidad para comprobar la integridad de la estructura de la base de datos con algunas capacidades de recuperación.
En cuanto a la tecnología, libmdbx ofrece ACID, fuerte serialización de cambios y lecturas sin bloqueo con escalado lineal en todos los núcleos de la CPU. Se admiten la compactación automática, la gestión automática del tamaño de la base de datos y la estimación de consultas de rango. Desde 2016, los proyectos han sido financiados por Positive Technologies y desde 2017 se utilizan en sus productos.
libmdbx ofrece una API de C++, así como enlaces de lenguajes compatibles con entusiastas para Rust, Haskell, Python, NodeJS, Ruby, Go y Nim. Para libfpta, solo la descripción de la API está disponible públicamente en forma de archivo de encabezado C/C++.
Principales innovaciones, mejoras y correcciones añadidas desde la noticia anterior del 9 de mayo:
- Permite compilaciones reproducibles.
- Se corrigió un error por el cual, en circunstancias muy raras, podía ocurrir un bucle/congelación durante la confirmación de una transacción. El problema fue identificado por los especialistas de Positive Tecnology durante las pruebas internas de sus propios productos.
- Se mejoraron las pruebas y se ampliaron los escenarios de prueba para verificar todos los estados no isomórficos alcanzables del árbol de páginas y el contenido del GC dentro de la base de datos.
- En la API de C++, se ha corregido un “noexcept” adicional, se han agregado sobrecargas adicionales para el método “cursor::erase()”, la implementación de buffers se ha ahorrado el uso de “std::string” para asegurar la alineación (relevante para CLANG libstdc++).
- Se ha eliminado una regresión en el algoritmo de derrame de páginas sucias (expulsión selectiva de páginas de bases de datos modificadas) que se manifestaba por un raro error inesperado MDBX_PROBLEM al cambiar datos en transacciones grandes.
- Se llevó a cabo una prueba por fases con la adición de una serie de comprobaciones para garantizar la estabilidad en caso de daño intencional a la base de datos.
- Se corrigieron advertencias menores sobre problemas de UndefinedBehaviorSanitizer y Coverity Scan.
- Se corrigió la verificación del indicador interno “P_DIRTY” obsoleto y que ya no se usa en páginas anidadas dentro de imágenes de bases de datos creadas por versiones anteriores de la biblioteca.
- En los scripts de CMake, se ha mejorado la búsqueda de componentes del compilador necesarios para LTO (optimización del tiempo de enlace).
- El número máximo de lectores simultáneos se ha incrementado a 32767.
- Rendimiento mejorado al usar Valgrind y AddressSanitizer.
- En Windows, se eliminó el uso recursivo de SRW-lock cuando se trabaja en modo MDBX_NOTLS (sin usar el almacenamiento local de subprocesos), se corrigió la generación de bootid si la hora del sistema cambiaba, se mejoró la detección de WSL1 y WSL2 y se mejoró la capacidad de Se ha agregado abrir una base de datos en Plan 9 montada a través de DrvFS.
- En total, se realizaron más de 160 cambios en 57 archivos, se agregaron ~5000 líneas y se eliminaron ~2500.
Me gustaría agradecer especialmente al equipo del proyecto Erigon (ecosistema Ethereum) por su ayuda en las pruebas en escenarios de uso extremos. Es significativo que en cinco meses desde el lanzamiento de libmdbx v0.10.0, con un volumen de base de datos de 1-2 TB en cada instalación de Erigon (utilizado en el 7% de los nodos de Ethereum), solo se recibieron tres informes de corrupción de bases de datos, todos que ocurrió por razones externas, y no por errores de software: en dos casos la causa fueron fallas en la RAM, en el tercero un error al restablecer datos en una configuración específica del subsistema de almacenamiento usando BTRFS.
Fuente: opennet.ru