As bibliotecas libmdbx 0.10.4 (MDBX) lanzáronse coa implementación dunha base de datos de valores clave integrada compacta de alto rendemento e a biblioteca asociada libfpta 0.3.9 (FPTA), que implementa unha representación tabular de datos con índices secundarios e compostos. encima de MDBX. Ambas bibliotecas distribúense baixo licenzas aprobadas por OSI. Todos os sistemas operativos e arquitecturas actuais son compatibles, así como o Russian Elbrus 2000.
Historicamente, libmdbx é unha profunda reelaboración do DBMS LMDB e supera o seu antepasado en fiabilidade, conxunto de funcións e rendemento. En comparación con LMDB, libmdbx fai moita énfase na calidade do código, a estabilidade da API, as probas e as comprobacións automatizadas. Ofrécese unha utilidade para comprobar a integridade da estrutura da base de datos con algunhas capacidades de recuperación.
En canto á tecnoloxía, libmdbx ofrece ACID, serialización de cambios fortes e lecturas sen bloqueo con escalado lineal nos núcleos da CPU. Admítense a compactación automática, a xestión automática do tamaño da base de datos e a estimación de consulta de intervalos. Desde 2016, os proxectos están financiados por Positive Technologies e desde 2017 utilízanse nos seus produtos.
libmdbx ofrece unha API de C++, así como ligazóns de linguaxe compatibles con entusiastas para Rust, Haskell, Python, NodeJS, Ruby, Go e Nim. Para libfpta, só a descrición da API está dispoñible publicamente en forma de ficheiro de cabeceira C/C++.
Principais novidades, melloras e correccións engadidas desde a noticia anterior do 9 de maio:
- Permite compilacións reproducibles.
- Corrixiuse un erro debido ao cal, en circunstancias moi raras, se podía producir un bucle/conxelación durante a commit dunha transacción. O problema foi identificado polos especialistas de Positive Tecnologies durante as probas internas dos seus propios produtos.
- Melloráronse as probas e ampliáronse os escenarios de proba para comprobar todos os estados non isomórficos alcanzables da árbore da páxina e do contido do GC dentro da base de datos.
- Na API de C++, solucionouse un "noexcept" adicional, engadíronse sobrecargas adicionais para o método "cursor::erase()", a implementación de búfers aforrouse do uso de "std::string" para garantir o aliñamento. (relevante para CLANG libstdc++).
- Eliminouse unha regresión no algoritmo de derrame de páxinas sucias (expulsión selectiva de páxinas de base de datos modificadas) que se manifestou por un erro inesperado MDBX_PROBLEM ao cambiar datos en grandes transaccións.
- Realizouse unha proba de fase coa adición dunha serie de comprobacións para garantir a estabilidade en caso de danos intencionados na base de datos.
- Corrixíronse os problemas de advertencias menores UndefinedBehaviorSanitizer e Coverity Scan.
- Solucionouse a comprobación da marca interna desactualizada e xa non usada "P_DIRTY" nas páxinas aniñadas dentro das imaxes da base de datos creadas por versións antigas da biblioteca.
- Nos scripts CMake, mellorouse a busca de compoñentes do compilador necesarios para LTO (optimización do tempo de ligazón).
- O número máximo de lectores simultáneos aumentou a 32767.
- Rendemento mellorado ao usar Valgrind e AddressSanitizer.
- En Windows, eliminouse o uso recursivo do bloqueo SRW cando se traballa no modo MDBX_NOTLS (sen utilizar o almacenamento local de subprocesos), solucionouse a xeración de bootid se cambiou a hora do sistema, mellorouse a detección de WSL1 e WSL2 e a capacidade de Abriuse unha base de datos no Plan 9 montada mediante DrvFS.
- En total, realizáronse máis de 160 cambios en 57 ficheiros, engadíronse ~5000 liñas e elimináronse ~2500.
Gustaríame agradecer especialmente ao equipo do proxecto Erigon (ecosistema Ethereum) a súa asistencia nas probas en escenarios de uso extremo. É significativo que en cinco meses desde o lanzamento de libmdbx v0.10.0, cun volume de base de datos de 1-2 TB en cada instalación de Erigon (utilizado no 7% dos nodos de Ethereum), só se recibiron tres informes de corrupción da base de datos, todos que se produciu por motivos externos, e non por erros de software: en dous casos a causa foron fallos na memoria RAM, no terceiro un erro ao restablecer os datos nunha configuración específica do subsistema de almacenamento mediante BTRFS.
Fonte: opennet.ru