Foi lançado o libmdbx 0.10.4 (MDBX) com a implementação de um banco de dados compacto e de alto desempenho do tipo chave-valor, e a biblioteca associada libfpta 0.3.9 (FPTA), que implementa uma representação tabular de dados sobre o MDBX com índices secundários e compostos. Ambas as bibliotecas são distribuídas sob licenças aprovadas pela OSI. Todas as principais plataformas e arquiteturas estão suportadas, incluindo o Elbrus 2000 da Rússia.
Historicamente, o libmdbx é uma revisão profunda do SGBD LMDB e supera seu predecessor em confiabilidade, recursos e desempenho. Em comparação com o LMDB, o libmdbx dá grande atenção à qualidade do código, ao funcionamento estável da API, aos testes e às verificações automáticas. Uma ferramenta de verificação de integridade da estrutura do banco de dados é fornecida, com algumas capacidades de recuperação.
Tecnologicamente, o libmdbx oferece ACID, serialização rigorosa de mudanças e leitura não bloqueante com escalabilidade linear em núcleos de CPU. A auto-compactação, o gerenciamento automático do tamanho do banco de dados e a estimativa de volume de consultas em intervalos (range query estimation) são suportadas. Desde 2016, o projeto é financiado pela Positive Technologies e, desde 2017, é utilizado em seus produtos.
Para o libmdbx, uma API C++ é oferecida, bem como ligações a linguagens suportadas por entusiastas, como Rust, Haskell, Python, NodeJS, Ruby, Go e Nim. Para o libfpta, apenas a descrição da API está publicamente disponível na forma de um arquivo de cabeçalho C/C++.
As principais inovações, melhorias e correções adicionadas desde a última notícia de 9 de maio:
- Foi garantida a possibilidade de builds reproduzíveis.
- Um erro foi corrigido, que em condições muito raras durante a confirmação de uma transação poderia causar um loop/pendência. O problema foi identificado pelos especialistas da Positive Technologies durante testes internos de seus produtos.
- Os testes foram aprimorados e os cenários de teste foram expandidos para verificar todos os estados não isomórficos alcançáveis da árvore de páginas e o conteúdo do GC dentro do banco de dados.
- Na API C++, o excesso de "noexcept" foi corrigido e sobrecargas adicionais foram adicionadas ao método “cursor::erase()”, eliminando o uso de “std::string” para garantir o alinhamento (relevante para o CLANG libstdc++).
- Foi resolvido um regresso no algoritmo de spooling de páginas sujas (substituição seletiva de páginas do banco de dados alteradas) que se manifestava por um erro raro e inesperado MDBX_PROBLEM durante a alteração de dados em grandes transações.
- Foi realizada uma verificação com phase testing, adicionando uma série de verificações para garantir a estabilidade ao danificar intencionalmente o banco de dados.
- Foram corrigidos avisos menores de UndefinedBehaviorSanitizer e problemas do Coverity Scan.
- Foi corrigida a verificação de uma flag interna obsoleta e já não utilizada 'P_DIRTY' em páginas aninhadas dentro de imagens do banco de dados criadas por versões antigas da biblioteca.
- Nos scripts CMake, foi aprimorada a busca por componentes do compilador necessários para LTO (otimização em tempo de link).
- O número máximo de leitores simultâneos foi aumentado para 32767.
- O desempenho foi acelerado ao usar Valgrind e AddressSanitizer.
- No Windows, foi resolvido o uso recursivo do SRW-lock ao operar no modo MDBX_NOTLS (sem usar armazenamento local de threads), a geração de bootid foi corrigida em caso de alteração do tempo do sistema, a detecção do WSL1 e WSL2 foi aprimorada, e adicionada a capacidade de abrir o banco de dados em Plan 9 montado através do DrvFS.
- No total, foram feitas mais de 160 alterações em 57 arquivos, adicionando cerca de 5000 linhas e removendo cerca de 2500.
Gostaria de agradecer à equipe do projeto Erigon (ecossistema Ethereum) pela ajuda nos testes em cenários de uso extremos. É digno de nota que nos cinco meses desde o lançamento do libmdbx v0.10.0, com um volume de banco de dados de 1-2 TB em cada instalação do Erigon (usado em 7% dos nós Ethereum), apenas três relatos de corrupção de banco de dados foram recebidos, todos ocorrendo devido a causas externas e não erros de software: em dois casos, as falhas foram causadas por problemas de RAM, e no terceiro, um erro de reinicialização de dados em uma configuração específica do subsistema de armazenamento usando BTRFS.
Fonte: opennet.ru
