После трех месяцев разработки состоялся выпуск библиотеки libmdbx 0.10.0 (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License. libmdbx является глубокой переработкой СУБД LMDB и по заявлению разработчиков превосходит своего прародителя по надежности, набору возможностей и производительности. Заявляется, что libmdbx до 20% быстрее LMDB в CRUD сценариях и до 30% быстрее, если при сборке libmdbx отключить внутренний контроль до сопоставимого с LMDB уровня...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55114
mdbx.c++ -> mdbx.cpp
mdbx.h++ -> mdbx.hppНе буду пользоваться, пока так не сделаете. :-D
MithrilDB на Rust зарелизится раньше ;)
Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ по-умолчанию их просто не поддерживает?Спасибо за минусы, ничего другого тут и не ожидалось.
> Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ их
> просто не поддерживает?
> Спасибо за минусы, ничего другого тут и не ожидалось.Минусы не мои.
с++ и h++ = один из _стандартных_ вариантов для файлов с исходными текстами на C++.
Исторически эти расширения не получили распространения из-за унаследованных ограничений на всяких старых и (теперь уже) вымерших системах.
Весь приличный софт давно их поддерживает, например gcc и clang автоматически выбирают/запускают компилятор С++.Если по какой-то причине это вам неудобно, то вы всегда можете переименовать файлы локально, и т.п.
> Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ по-умолчанию их просто не поддерживает?Да, надо. Приведи пример программы, которая это не поддерживает.
> Да, надо.
> ПриведиНа сегодня бисер закончился. Может быть, завтра.
После *вежливой* просьбы.
> На сегодня бисер закончился. Может быть, завтра.В смысле тебе подумать надо, потому что ни одного примера программы навскидку привести не можешь? Ну вот я тоже не могу, и поэтому...
> После *вежливой* просьбы.
... вежливо сообщаю тебе, что ты несёшь bullshit.
mdbx.c++/h++ -> mdbx.rsНе буду пользоваться, пока так не сделаете. :-D
Только после того как на Zig перепишут
mdbx.c++/h++ -> mdbx.js
бинарь же не меняется от этого. похожая ситуация и с .htm, который по факту ничем не отличается от привычного .html
Один анонимный эксперт по факту ничем не отличается от другого.
Они очень похожи в разных ситуациях.
Какая гадость, должно быть cxx/hxx чтобы не вызывать отвращения.
c××
.сипп или .си++
с++ -- си-кросс-кросс
а cpp -- это что?
p - в смайликах это высунутый язык. Типа, "беее".Т.о. cpp - сибеебее
>mdbx.c++ -> mdbx.cpp
>mdbx.h++ -> mdbx.hppWindows(TM) в такие имена не может?
>>mdbx.c++ -> mdbx.cpp
>>mdbx.h++ -> mdbx.hpp
> Windows(TM) в такие имена не может?Может давным-давно, и всё это проверяется на CI.
А у сабжа тоже компайлтайм лимиты? Вот у leveldb их нет (во всяком случае не 100 байт или сколько там).
$ make options
## TIP: Use `make V=1` for verbose.
INSTALL =install
DESTDIR =
prefix =/usr/local
mandir =/usr/local/man
suffix =CC =cc
CFLAGS_EXTRA =
CFLAGS =-std=gnu11 -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributes
CXX =g++
CXXSTD =-std=gnu++2a
CXXFLAGS =-std=gnu++2a -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributesLD =ld
LDFLAGS =-Wl,--gc-sections,-z,relro,-O1
EXE_LDFLAGS =-pthread
LIBS = -lrtMDBX_BUILD_OPTIONS =-DNDEBUG=1
## Assortment items for MDBX_BUILD_OPTIONS:
## Note that the defaults should already be correct for most platforms;
## you should not need to change any of these. Read their descriptions
## in README and source code (see src/options.h) if you do.
MDBX_DISABLE_GNU_SOURCE
MDBX_OSX_SPEED_INSTEADOF_DURABILITY
MDBX_ENV_CHECKPID
MDBX_TXN_CHECKOWNER
MDBX_TRUST_RTC
MDBX_ENABLE_REFUND
MDBX_ENABLE_PGOP_STAT
MDBX_ENABLE_MADVISE
MDBX_DISABLE_PAGECHECKS
MDBX_PNL_PREALLOC_FOR_RADIXSORT
MDBX_DPL_PREALLOC_FOR_RADIXSORT
MDBX_WITHOUT_MSVC_CRT
MDBX_ENVCOPY_WRITEBUF
MDBX_FORCE_ASSERTIONS
MDBX_ASSUME_MALLOC_OVERHEAD
MDBX_DEBUG
MDBX_USE_VALGRIND
MDBX_HAVE_C11ATOMICS
MDBX_LOCKING
MDBX_USE_OFDLOCKS
MDBX_USE_SENDFILE
MDBX_USE_COPYFILERANGE
MDBX_USE_SYNCFILERANGE
MDBX_CPU_WRITEBACK_INCOHERENT
MDBX_MMAP_INCOHERENT_FILE_WRITE
MDBX_MMAP_INCOHERENT_CPU_CACHE
MDBX_64BIT_ATOMIC
MDBX_64BIT_CAS
MDBX_UNALIGNED_OK
MDBX_CACHELINE_SIZE
Я не вижу тут MAXKEYSIZE, сколько там захадкожено? 4кб хотя бы влезет?
см. https://github.com/erthink/libmdbx/blob/master/README.md#lim...Т.е. "немного лучше" чем у Oracle, см. https://blogs.oracle.com/sql/how-to-fix-ora-01450-maximum-ke...
Насколько негативно скажется увеличение размера страницы, в частности, на производительности? 65к это вроде бы достаточно для большинства применений.
Хотя всё равно ограничения, у левелдб хоть мегабайты пихай.
> у левелдб хоть мегабайты пихай.Ну засунуть-то можно, толку только мало.
Этакий неуловимый джо наоборот ;)
А есть какий-нибудь носкуль сервер на сабже?
> А есть какий-нибудь носкуль сервер на сабже?ardb умеет использовать LMDB.
Скорее всего, после небольшой доработки mdbx тоже сумеет.
Спасибо!
Когда-то давно Ховард баловался с https://github.com/LMDB/sqlightning.
Там что-то вполне рабочее, но много собственных тестов SQLite не проходит.Потом (вроде-бы) по мотивам этого PoC сделали https://github.com/LumoSQL/lumosql.
Сам не пробовал, но теоретически оно рабочее и за пару дней можно пересадить с LMDB на MDBX.Еще есть https://github.com/PositiveTechnologies/libfpta с табличками, колонками, индексами..., но без SQL.
Спасибо!
В чём отличие от RocksDB? Можно ли использовать как storage backend для SQL или Object базы данных?
> В чём отличие от RocksDB?RocksDB - это ДЫЬ (https://ru.wikipedia.org/wiki/LSM-%D0%B4%D0&#...) с дополнительними читами и фичами.
MDBX - это B+Tree (https://ru.wikipedia.org/wiki/B%E2%81%BA-...) со своими читами и фичами.
Отличий как в плюс, так и в минус, очень много чтобы писать здесь, но в Сети есть масса информации.
Можете начать с https://github.com/erthink/libmdbx#comparison-with-other-dat... и https://www.opennet.dev/openforum/vsluhforumID3/121987.html#43> Можно ли использовать как storage backend для SQL или Object базы данных?
Да можно, если что-то "прикрутить", см https://www.opennet.dev/openforum/vsluhforumID3/124185.html#15
s/ДЫЬ/LSM-tree/
Это, конечно, впечатляет https://www.github.com/lmdbjava/benchmarks/tree/master/resul...Интересно посмотреть что-нибудь посвежее и для SSD
Принципиально ничего не изменилось.Если вычесть ожидание дисковых операций (например запустить в /dev/shm или на RAM-диске), то MDBX/LMDB как-правило оказываются быстрее, ибо
- OlogN от b+tree;
- очень мало лишних действий (оверхеда);
- zerocopy и неблокируемое чтение с масштабированием по ядрам.С учетом дисковых операций всё в них родимых и упирается. При этом у MDBX/LMDB амплификация записи в точности равна высоте дерева, т.е. тоже OlogN.
Соответственно, принципиальных изменений в бенчмарках нет, так как не меняются эти слагаемые и их пропорции.
На 20-30% быстрее чем master LMDB? Мне кажется вы не тестировали давно, а берёте старые цифры.Что насчёт новейших версий LMDB? Там же тоже код активно пилится, как я понял.
> На 20-30% быстрее чем master LMDB? Мне кажется вы не тестировали давно, а берёте старые цифры.
> Что насчёт новейших версий LMDB? Там же тоже код активно пилится, как я понял.Во-первых, на всякий (чтобы не упрекали в читерстве): 20-30% получается если оценивать скорость работы самих движков (без учета дисков) и отключить в MDBX дополнительный контроль (корректности операций и данных в БД).
В новых версиях нет ничего, чтобы позволяло LMDB становиться быстрее.
Буквально там примерно следующее:
- поддержка чтения больших БД на 32-битных системах (MDB_VL32), что существенно замедляет движок, так как требуете поддерживать кеш "окон отображения" файла БД в ОЗУ.
- поддержка шифрования, что требует дополнительных затрат на поддержку кеша прочитанных/расшифрованных страниц БД.
- добавление txn_id в заголовок страниц для определения их "грязного" статуса, но в MDBX txn_id был добавлен давным-давно.А различных багов и недочетов куча, их можно перечислять очень долго.
Что скажете про это https://github.com/spacejam/sled? Сравнивали, тестировали?
> то скажете про это https://github.com/spacejam/sled? Сравнивали, тестировали?80% ответа есть в https://github.com/spacejam/sled?#known-issues-warnings
Остальные 20% примерно такие:
1) В сценариях с интенсивным чтением превосходство будет у MDBX, ибо оверхеда и блокировок примерно 0.
2) В MDBX нет WAL - это принципиальный осознанный архитектурный выбор (унаследованный от LMDB) со своими минусами и плюсами.
Поэтому MDBX будет ожидаемо проигрывать в одних сценариях и выигрывать в других.
Соответственно, вопрос тут не в том "кто круче/быстрее", а насколько некий (условно ваш) сценарий использования соответствует свойствам/назначению того или иного движка.3) Авторы sled пускаются во все тяжкие с lockfree, rw-локами и atomic-операциями ради более-менее параллельного выполнения читающих и пишущих транзакций..., и всё это поверх смеси b-tree с lsm, приправленное массой дополнительных фишек и фичей.
Теоретически такое можно отладить, довести до production стабильность и производительность.
На практике же буду баги, время воспроизведения которых в разы больше времени жизни соответствующей версии кода.Другими словами, sled = концептуально интересно и действительно может дать существенный "выхлоп", но есть существенные риски что проект никогда не дойдет до production-готовности (см https://github.com/spacejam/sled/issues).
> введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.GitHub еще не заблокировали?... недоработка...
Не совсем в тему, но...git clone https://abf.io/erthink/ReOpenLDAP.git reopenldap
Cloning into 'reopenldap'...
remote: Enumerating objects: 43000, done.
remote: Counting objects: 100% (43000/43000), done.
remote: Compressing objects: 100% (10332/10332), done.
remote: Total 43000 (delta 33292), reused 42174 (delta 32471)
Receiving objects: 100% (43000/43000), 19.13 MiB | 8.62 MiB/s, done.
Resolving deltas: 100% (33292/33292), done.
fatal: bad object 00000000000000007c000000770000006e000000
fatal: remote did not send all necessary objects
У тебя место на диске закончилось.
Не похоже.
Другие работают в этом же месте.
Тоже самое на github
> Тоже самое на github$ git clone https://github.com/erthink/ReOpenLDAP.git
Клонирование в «ReOpenLDAP»…
remote: Enumerating objects: 43000, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 43000 (delta 0), reused 1 (delta 0), pack-reused 42997
Получение объектов: 100% (43000/43000), 24.88 MiB | 2.04 MiB/s, готово.
Определение изменений: 100% (32830/32830), готово.$ cd ReOpenLDAP/
$ git fsck
Проверка каталогов объектов: 100% (256/256), готово.
Проверка объектов: 100% (43000/43000), готово.$ git --version
git version 2.27.0Аналогично с https://abf.io/erthink/ReOpenLDAP.git и git 2.31.1
---
На всякий: я не занимался ReOpenLDAP-ом два года, в частности туда не портировались важные правки из OpenLDAP, и также движок хранения там совсем старый.
Кажется выяснилось. проблема проявляется в следущих версиях GIT=dev-vcs/git-2.31.1
=dev-vcs/git-2.31.0-r1Откат на 2.30.2 устранил проблему.
Я так понимаю ACID работает для многопоточности.А как быть с многопроцессорностью - например когда запускается два экземпляра одного приложения (GUI)? И оба, естественно, полезут в одну БД (по одному пути)
> Я так понимаю ACID работает для многопоточности.
> А как быть с многопроцессорностью - например когда запускается два экземпляра
> одного приложения (GUI)? И оба, естественно, полезут в одну БД (по
> одному пути)RTFM https://github.com/erthink/libmdbx/blob/master/README.md#lib...
- в 1-ов пункте: "Allows a swarm of multi-threaded processes to ACIDly read and update several key-value maps and multimaps in a locally-shared database.", т.е. с много-процессностью всё также хорошо как и с много-поточностью.
- в 5-ом пункте: "Enforces serializability for writers... affords wait-free for parallel readers without atomic/interlocked operations, while writing and reading transactions do not block each other", т.е. все пишущие транзакции выполняются строго последовательно, а читающие не блокируются.
Беру! Спасибо за подробные ответы, очень полезно
курсоры и вторичные ключи есть?
> курсоры и вторичные ключи есть?Курсоры есть, а вторичных ключей в key-value не бывает (для этого есть https://github.com/erthink/libfpta).
Нет руководства по программированию с использованием этого ПО
Также настораживает:
> Операции изменения данных никак не блокируют читателей.Это не очень понятно. Что прочитает "читатель" если "писатель" не завершит изменение? Запись в объект должна блокировать чтение из объекта на время исполнения записи. Тем более, если, как Вы говорите, имеется поддержка вторичных ключей.
> Нет руководства по программированию с использованием этого ПО.RTFM https://erthink.github.io/libmdbx/usage.html#starting
> Также настораживает:
> > Операции изменения данных никак не блокируют читателей.RTFM https://github.com/erthink/libmdbx/blob/master/README.md#fea..., среди прочего, там есть строки:
- Fully ACID-compliant, through to MVCC and CoW.
- Readers are non-blocking, notwithstanding snapshot isolation.Со ссылками на пояснения что такое ACID, MVCC, CoW и snapshot isolation.
Кроме этого, см. https://ru.bmstu.wiki/LMDB_(Lightning_Memory-Mapped_Database) - вся эта информация в принципе применима к libmdbx, ибо "Historically, libmdbx is a deeply revised and extended descendant of the Lightning Memory-Mapped Database" (https://github.com/erthink/libmdbx/blob/master/README.md#his...).> Это не очень понятно. Что прочитает "читатель" если "писатель" не завершит изменение?
RTFM: ACID предполагает транзакции с изоляцией, т.е. читатели видят результаты только успешно завершенных транзакций.
> Запись в объект должна блокировать чтение из объекта на время исполнения записи.
RTFM: MVCC, snapshot isolation, page shadowing and CoW.
До фиксации транзакции писатель изменяет копию данных, которая не видна читателям.
Примерно как https://ru.wikipedia.org/wiki/Read-copy-update> Тем более, если, как Вы говорите, имеется поддержка вторичных ключей.
Еще раз:
- в key-value не может быть вторичны ключей, ибо тогда это не key-value просто по определению.
- типизированные колонки, nullable, вторичные ключи, составные индексы - реализованы в https://github.com/PositiveTechnologies/libfpta поверх libmdbx.
>а введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.Ну это пока ... В уважаемых транснациональных компаниях давно уже требуют перед заключением договора заявления, что сама фирма не внесена ни в один санкционный список, и что продукция и услуги, поставленные по договорам, не будут переданы в руки лиц и компаний, находящихся в санкционных списках. Так что вангую, что с GH вас рано или поздно выкинут, а вместо врнды придётся довольствоваться реактосью. В прочем это к лучшему, наконец-то реактось до юзабельного состояния допилят.
P. S. Не брат ты мне.
>>а введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.
> Ну это пока ... В уважаемых транснациональных компаниях давно уже требуют перед
> заключением договора заявления, что сама фирма не внесена ни в один
> санкционный список, и что продукция и услуги, поставленные по договорам, не
> будут переданы в руки лиц и компаний, находящихся в санкционных списках.Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".
> Так что вангую, что с GH вас рано или поздно выкинут,
> а вместо врнды придётся довольствоваться реактосью. В прочем это к лучшему,
> наконец-то реактось до юзабельного состояния допилят.Обязательно, ведь каждый украинский хомячок - лев, и племянник Ванги, ибо еще не гриб, пока выкапывает черное море!
Ну и в завтрашний день не все могут смотреть.
Вернее смотреть могут не только лишь все, мало кто может это делать!;)
>Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".Ну верно, це Європа ведь, соответственно и глобус с Европой и Гермашкой. Не то что глобус Великой прекрасной России с Нашим Севером.
А если серьезно, то см https://tv.rbc.ru/archive/ekskluziv/609155ee2ae596b067b3745bЮрий там очень хорошо всё рассказал.
>Some results may have been delisted consistent with local lawsА телек я не смотрю ни в каком виде.
Поведение в стиле одноименного действия страуса никогда никого к добру не приводило.
А, ну смотрите регулярно шоу Соловьёва, станете добрее.
> А, ну смотрите регулярно шоу Соловьёва, станете добрее.Ну и зачем нам врать про "не смотрю ТВ ни в каком виде" если в курсе за такие ШОУ? Я, например, смотрю ТВ, но ниразу не в курсе за такие ШОУ.