Rilis DBMS tertanam berkinerja tinggi libmdbx 0.10.4 dan libfpta 0.3.9

Pustaka libmdbx 0.10.4 (MDBX) dirilis dengan implementasi database nilai kunci tertanam kompak berkinerja tinggi, dan pustaka libfpta 0.3.9 (FPTA) terkait, yang mengimplementasikan representasi tabel data dengan indeks sekunder dan komposit di atas MDBX. Kedua perpustakaan didistribusikan di bawah lisensi yang disetujui OSI. Semua sistem operasi dan arsitektur saat ini didukung, begitu pula Elbrus Rusia 2000.

Secara historis, libmdbx adalah pengerjaan ulang mendalam dari DBMS LMDB dan lebih unggul dari pendahulunya dalam hal keandalan, rangkaian fitur, dan kinerja. Dibandingkan dengan LMDB, libmdbx lebih menekankan pada kualitas kode, stabilitas API, pengujian, dan pemeriksaan otomatis. Utilitas untuk memeriksa integritas struktur database dengan beberapa kemampuan pemulihan disediakan.

Dari segi teknologi, libmdbx menawarkan ACID, serialisasi perubahan yang kuat, dan pembacaan non-pemblokiran dengan penskalaan linier di seluruh inti CPU. Pemadatan otomatis, manajemen ukuran database otomatis, dan estimasi rentang kueri didukung. Sejak 2016, proyek-proyek tersebut didanai oleh Positive Technologies dan sejak 2017 telah digunakan dalam produk-produknya.

libmdbx menawarkan C++ API, serta binding bahasa yang didukung antusias untuk Rust, Haskell, Python, NodeJS, Ruby, Go, dan Nim. Untuk libfpta, hanya deskripsi API yang tersedia untuk umum dalam bentuk file header C/C++.

Inovasi, perbaikan, dan koreksi besar ditambahkan sejak berita sebelumnya pada tanggal 9 Mei:

  • Mengaktifkan build yang dapat direproduksi.
  • Memperbaiki bug yang menyebabkan, dalam keadaan yang sangat jarang terjadi, loop/freeze dapat terjadi selama transaksi dilakukan. Masalahnya diidentifikasi oleh spesialis Teknologi Positif selama pengujian internal produk mereka sendiri.
  • Pengujian telah ditingkatkan dan skenario pengujian telah diperluas untuk memeriksa semua status non-isomorfik yang dapat dijangkau dari pohon halaman dan konten GC di dalam database.
  • Di C++ API, tambahan “nokecuali” telah diperbaiki, kelebihan beban tambahan telah ditambahkan untuk metode “cursor::erase()”, implementasi buffer telah terhindar dari penggunaan “std::string” untuk memastikan keselarasan (relevan untuk CLANG libstdc++).
  • Regresi dalam algoritme penumpahan halaman kotor (pengusiran selektif halaman database yang diubah) yang dimanifestasikan oleh kesalahan tak terduga yang jarang terjadi MDBX_PROBLEM saat mengubah data dalam transaksi besar telah dihilangkan.
  • Pengujian bertahap dilakukan dengan penambahan sejumlah pemeriksaan untuk memastikan stabilitas jika terjadi kerusakan yang disengaja pada database.
  • Memperbaiki peringatan kecil masalah UndefinisiBehaviorSanitizer dan Coverity Scan.
  • Memperbaiki pemeriksaan tanda internal "P_DIRTY" yang sudah usang dan tidak lagi digunakan di halaman bersarang di dalam gambar database yang dibuat oleh versi perpustakaan yang lebih lama.
  • Dalam skrip CMake, pencarian komponen kompiler yang diperlukan untuk LTO (optimasi waktu tautan) telah ditingkatkan.
  • Jumlah maksimum pembaca simultan telah ditingkatkan menjadi 32767.
  • Peningkatan kinerja saat menggunakan Valgrind dan AddressSanitizer.
  • Di Windows, penggunaan kunci SRW secara rekursif saat bekerja dalam mode MDBX_NOTLS (tanpa menggunakan penyimpanan lokal thread) telah dihilangkan, pembuatan bootid telah diperbaiki jika waktu sistem telah berubah, deteksi WSL1 dan WSL2 telah ditingkatkan, dan kemampuan untuk membuka database pada Paket 9 yang dipasang melalui DrvFS telah ditambahkan.
  • Secara total, lebih dari 160 perubahan dilakukan pada 57 file, ~5000 baris ditambahkan, ~2500 dihapus.

Saya terutama ingin mengucapkan terima kasih kepada tim proyek Erigon (ekosistem Ethereum) atas bantuan mereka dalam pengujian dalam skenario penggunaan ekstrem. Penting untuk dicatat bahwa dalam lima bulan sejak rilis libmdbx v0.10.0, dengan volume database 1-2 TB di setiap instalasi Erigon (digunakan pada 7% node Ethereum), hanya tiga laporan kerusakan database yang diterima, semuanya yang terjadi karena alasan eksternal, dan bukan kesalahan perangkat lunak: dalam dua kasus penyebabnya adalah kegagalan RAM, yang ketiga karena kesalahan dalam mengatur ulang data dalam konfigurasi tertentu dari subsistem penyimpanan menggunakan BTRFS.

Sumber: opennet.ru

Tambah komentar