Опубликован выпуск библиотеки libmdbx 0.13.6 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией Apache 2.0. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000. Для libmdbx предлагается развитое API для C++, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala. Из проектов, использующих libmdbx, можно отметить Isar, Erigon и Reth, а также разработки компаний StarkWare и Positive Technologies...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63134
Кто разбирается, объясните, в чем преимущества ключ-значение перед табличными бд? Ощущение что отрасль буквально помешалась на к/з базах.
"Табличная БД" это тоже ключ-значение, но в значении лежит кортеж полей строки таблицы.Ну и далее по-возрастанию сложности, реляционная БД -- это такая "табличная БД", в которой могут быть определены как дополнительные индекс, так и отношения между полями таблиц... и БД будет автоматически все это проверять/использовать.
Поэтому ключ-значение тут базис, который может быть как неприемлемо примитивен для многих задач, так и может позволить избежать лишних накладных расходов и/или ненужных операций.
Используют и то и другое вместе, нет отказа от реляционных баз. Как пример, в базу ключ- значение выносят из реляционки поля типа блоб, в реляционку записывают только ключ. Тогда реляционка значительно похудеет и станет быстрее.
Для большинства задач этого функционала ДОСТАТОЧНО.
ПРОСТО положить (сохранить) пару К-З в файл базы не диске. ПРОСТО быстро найти З по К и считать в переменную. Особенно, если и К, и З у нас простые сами по себе (сериализованный объект в бинарном виде тоже может считаться простым, если не предполагается, что на уровне базы нужен доступ к полям).
Смотрите локальность данных тогба все поймёте.
Дык, табличная СУБД она же и построена на основе табличек ключ-значение. Одна табличка содержит список колонок. Другие - формат колонок, третьи - данные этих колонок, и т.п. Когда вы просите таблицу, она собирается из этих к-з табличек, обычными SELECT-ами.
"Бузина" - аффтырь не разочаровывает.
Аффтыр там реально жжет.Потыкал тут палочно
github восстановил доступ? Оно было read-only, от чего Гугол выдавал в выдаче ссылки на устаревшею версию, чем насолил пользователям и автору.
там же целый абзац есть
https://github.com/erthink/libmdbx?tab=readme-ov-file#github
Там сокращённо и без таких подробностей. Ладно бы полностью удалили, тогда бы пользователи нашли зеркало с актуальной версией. А так поисковик подсовывал устаревшую, а поддерживаемый репозиторий был на 10-й странице выдачи, куда мало кто заглядывает.
Об MDBX во многих местах заявляется что быстрее и т.п. При этом автор пиарится что у него там "самые быстрые реализации" неких алгоритмов, например https://t.me/libmdbx/1/3475, https://t.me/libmdbx/1/5257.Для branchless bsearch нашлось подтверждение https://probablydance.com/2023/04/27/beautiful-branchless-bi..., что код автора действительно быстрее (даже при использовании clang с плохой поддержкой cmov).
А что известно про base58 и что там может быть быстрее?
Кто-нибудь пробовал или может прояснить?https://github.com/erthink/libmdbx/blob/master/src/mdbx.c�...
Мне все буквы понятны, но не вместе.
> Please don't use github's tarballs nor zips, but the amalgamated sources or clone the git repositoryДа щас.
Подозреваю, что это предупреждение, а не просьба ;)