As bibliotecas libmdbx 0.10.4 (MDBX) foram lançadas com a implementação de um banco de dados de valores-chave incorporado compacto de alto desempenho e a biblioteca associada libfpta 0.3.9 (FPTA), que implementa uma representação tabular de dados com índices secundários e compostos em cima do MDBX. Ambas as bibliotecas são distribuídas sob licenças aprovadas pela OSI. Todos os sistemas operacionais e arquiteturas atuais são suportados, assim como o russo Elbrus 2000.
Historicamente, libmdbx é uma reformulação profunda do SGBD LMDB e é superior ao seu ancestral em confiabilidade, conjunto de recursos e desempenho. Comparado ao LMDB, o libmdbx dá muita ênfase à qualidade do código, estabilidade da API, testes e verificações automatizadas. É fornecido um utilitário para verificar a integridade da estrutura do banco de dados com alguns recursos de recuperação.
Em termos de tecnologia, libmdbx oferece ACID, forte serialização de alterações e leituras sem bloqueio com escala linear entre núcleos de CPU. Há suporte para compactação automática, gerenciamento automático de tamanho de banco de dados e estimativa de consulta de intervalo. Desde 2016, os projetos são financiados pela Positive Technologies e desde 2017 são utilizados em seus produtos.
libmdbx oferece uma API C++, bem como ligações de linguagem suportadas por entusiastas para Rust, Haskell, Python, NodeJS, Ruby, Go e Nim. Para libfpta, apenas a descrição da API está disponível publicamente na forma de um arquivo de cabeçalho C/C++.
Principais inovações, melhorias e correções adicionadas desde a notícia anterior de 9 de maio:
- Permite compilações reproduzíveis.
- Corrigido um bug devido ao qual, em circunstâncias muito raras, um loop/congelamento poderia ocorrer durante uma confirmação de transação. O problema foi identificado por especialistas da Positive Technologies durante testes internos de seus próprios produtos.
- Os testes foram aprimorados e os cenários de teste foram expandidos para verificar todos os estados não isomórficos acessíveis da árvore de páginas e do conteúdo do GC dentro do banco de dados.
- Na API C++, um “noexcept” extra foi corrigido, sobrecargas adicionais foram adicionadas para o método “cursor::erase()”, a implementação de buffers foi poupada do uso de “std::string” para garantir o alinhamento (relevante para CLANG libstdc++).
- Foi eliminada uma regressão no algoritmo de derramamento de páginas sujas (ejeção seletiva de páginas alteradas do banco de dados) que se manifestava por um erro raro e inesperado MDBX_PROBLEM ao alterar dados em grandes transações.
- Foi realizado um teste de fases com a adição de uma série de verificações para garantir a estabilidade em caso de dano intencional ao banco de dados.
- Corrigidos pequenos avisos de problemas de UndefinedBehaviorSanitizer e Coverity Scan.
- Corrigida a verificação do sinalizador interno “P_DIRTY” desatualizado e não mais usado em páginas aninhadas dentro de imagens de banco de dados criadas por versões mais antigas da biblioteca.
- Nos scripts CMake, a busca por componentes do compilador necessários para LTO (otimização de tempo de link) foi aprimorada.
- O número máximo de leitores simultâneos foi aumentado para 32767.
- Desempenho aprimorado ao usar Valgrind e AddressSanitizer.
- No Windows, o uso recursivo de bloqueio SRW ao trabalhar no modo MDBX_NOTLS (sem usar armazenamento local de thread) foi eliminado, a geração de bootid foi corrigida se a hora do sistema mudou, a detecção de WSL1 e WSL2 foi melhorada e a capacidade de foi adicionado abrir um banco de dados no Plano 9 montado via DrvFS.
- No total, mais de 160 alterações foram feitas em 57 arquivos, ~5000 linhas foram adicionadas, ~2500 foram excluídas.
Gostaria de agradecer especialmente à equipe do projeto Erigon (ecossistema Ethereum) pela assistência nos testes em cenários de uso extremo. É significativo que em 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 Erigon (usado em 7% dos nós Ethereum), apenas três relatórios de corrupção de banco de dados foram recebidos, todos que ocorreu por motivos externos, e não por erros de software: em dois casos a causa foram falhas de RAM, no terceiro um erro na redefinição de dados em uma configuração específica do subsistema de armazenamento usando BTRFS.
Fonte: opennet.ru