forum.opennet.ru - "Выпуск компактной встраиваемой СУБД libmdbx 0.9.1" (51)

"Выпуск компактной встраиваемой СУБД libmdbx 0.9.1"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск компактной встраиваемой СУБД libmdbx 0.9.1"	+/–
Сообщение от opennews (ok), 30-Сен-20, 21:18
Выпущена версия 0.9.1 библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License... Подробнее: https://www.opennet.me/opennews/art.shtml?num=53812
Ответить \| Правка \| Cообщить модератору

Оглавление

баги в miranda с mdbx под wine все починили уже , JL2001 (ok), 21:18 , 30-Сен-20, (1)

В Wine не реализованы некоторые принципиальные вещи, без которых libmdbx не може, erthink (ok), 21:38 , 30-Сен-20, (2) +5

Пользуйтесь Dbx_sqlite dll, если приспичило вайнить миранду, _hide_ (ok), 10:55 , 01-Окт-20, (27) –2

На всякий1 sqlite не работает под Wine по схожим причинам, см https github co, erthink (ok), 11:15 , 01-Окт-20, (28) +2

У меня работает, что я сделал неправильно Правда под x32 И да, плагин контакт , _hide_ (ok), 19:16 , 01-Окт-20, (34)

Может у dartraiden-а спросить нафига он завел эту багу, если всё работает , _ (??), 21:28 , 01-Окт-20, (35) +1

Не работает оно убунта 20 04 последний стабильный тестовый вайн На 32-битны, dartraiden (?), 14:11 , 02-Окт-20, (40) +1

О да, дистр тут не важен - важно, чтобы Миранда и Вайн был под x32 настраиваетс, _hide_ (ok), 12:55 , 05-Окт-20, (49)

Почитал mdbx h, просто грустно во что превратился язык ц brief Returns t, x3who (?), 21:44 , 30-Сен-20, (3) +3

просто имя у функции длинное, Аноним (4), 21:46 , 30-Сен-20, (4) +1
как будто до превращения ц в нем и в ц таких конструкций никто не делал, Аноним (5), 21:56 , 30-Сен-20, (5) +2

Нормальная конструкция Зато не надо писать лишних комментариев , IRASoldier_registered (ok), 22:52 , 30-Сен-20, (6) –3

Согласен в общем случае но тут враппер тупой пролог хидера ввобще жжет напалм, x3who (?), 00:07 , 01-Окт-20, (11)

А чем плоха амальгамация , IRASoldier_registered (ok), 02:00 , 01-Окт-20, (21) –3

я вроде не говорил, что ненормальная А как помогут комментарии с танцами вокруг, Аноним (26), 09:46 , 01-Окт-20, (26)

Ну в любом активно развивающимся языке с достаточной историей будут новые фичи к, Аноним (8), 23:06 , 30-Сен-20, (8)

Вообще у них так и сделано - только Ц 11, x3who (?), 00:10 , 01-Окт-20, (12) +1

Тут дело не в языке, а в количестве компиляторов и их версий и желании разработч, Аноним (31), 12:14 , 01-Окт-20, (31) +2

Почему релизы теперь опять на GitHubе и куда же подевались ваши позиция и принци, Аноним (7), 22:59 , 30-Сен-20, (7) –4

теперь опять см последнюю строчку readme , erthink (ok), 23:56 , 30-Сен-20, (10) +1

Я вот лично до последней строчки не добрался, плюнул читать дальше на этом месте, x3who (?), 00:17 , 01-Окт-20, (13) +1

Исходный код LMDB - изначально ребус гляньте https github com LMDB lmdb blob , erthink (ok), 01:58 , 01-Окт-20, (20) +1

Надо эту цитату вставлять в каждую новость про LMDB Сразу отпадёт много вопросо, Аноним (33), 15:51 , 01-Окт-20, (33)
Ревьюверы кода LMDB иного мнения impressive codebase , the implementation is , _ (??), 21:38 , 01-Окт-20, (36)

Формулировки похожи на то как бы описывал своё творение Говард, mos87 (ok), 00:48 , 02-Окт-20, (39)

Да и не совсем это зеркало Потому что вы создаёте issue на баг-трекере этого , Аноним (7), 09:10 , 01-Окт-20, (25)
Поглядел Крым не российский, да Какие проблемы-то , andy (??), 15:51 , 01-Окт-20, (32) –4

Как-то кто-то просил сравнить производительность libmdbx, LMDB и sqlite Для этог, erthink (ok), 23:51 , 30-Сен-20, (9) +2

Были случаи использования этого в микроконтроллерах Ну там дейталоггеры какие-н, x3who (?), 00:25 , 01-Окт-20, (14)

Половина связанных с производительностью бонусов libmdbx происходит от отображ, erthink (ok), 00:40 , 01-Окт-20, (15)

Это для чтения, писатель, как я понимаю, там предполагается один Или в варианте, x3who (?), 00:50 , 01-Окт-20, (16)

Если ОЗУ мало, то БД просто некуда mmap-ить Т е если ОЗУ недостаточно, то будут, erthink (ok), 01:01 , 01-Окт-20, (17)

Диск - это абстракция более высокого уровня Сам микроконтроллер ничего про диск, x3who (?), 01:13 , 03-Окт-20, (42)

Чтобы использовать libmdbx как есть, без каких-либо доработок, то от системы тре, erthink (ok), 15:19 , 03-Окт-20, (44) +1

Не, мегабайт жирновато для _микро_-контроллера Но вообще код интересный, наше, x3who (?), 01:49 , 04-Окт-20, (46)

offtop 2 если что, в sqlite3 есть PRAGMA mmap_size x Насколько помню, по умолч, n80 (?), 03:19 , 04-Окт-20, (48)

mmap в sqlite будет немного ускорять чтение, за счет потенциального расширения , erthink (ok), 15:09 , 06-Окт-20, (50)

О как У меня было по большей части чтение, поэтому и получилось некоторое ускор, n80 (?), 15:16 , 06-Окт-20, (51)

На всякий, для информации 1 Заметил что при 25M итераций размер БД в sqlite полу, erthink (ok), 17:59 , 06-Окт-20, (52)

Там разница идёт на порядки в зависимости от объёма данных, собственно, потому о, Аноним (18), 01:18 , 01-Окт-20, (18) –1

Не совсем понятно что именно вы хотели сказать в контексте бенчмарков ioarena П, erthink (ok), 01:43 , 01-Окт-20, (19) +1

В контексте данного бенчмарка в наличии key size и value size, и, если я правиль, Аноним (18), 02:46 , 01-Окт-20, (22)

1 Пока размеры будут в пределах разумного , существенно разницы не будет 2 Пр, erthink (ok), 03:17 , 01-Окт-20, (23)

Скажите, пожалуйста, а насколько хорошо libmdbx подойдет для хранения счетчиков,, phprus (ok), 20:47 , 02-Окт-20, (41)

Для короткоживущих данных, как правило, лучше подходят БД на основе LSM https , erthink (ok), 14:54 , 03-Окт-20, (43) +1

Спасибо за ответ Буду тестировать Чтение запись почти одинаково с маленьким пере, phprus (ok), 17:06 , 03-Окт-20, (45)

Оперативно Вроде же, люди не любят регистрироваться А там даже зарегистрироват, Андрей (??), 04:34 , 01-Окт-20, (24) +3

trolling mode onДля перехода на Миранду осталось переписать её на Rust и сделат, erthink (ok), 11:20 , 01-Окт-20, (29)

Там же голимый WinAPI вроде используют во всех местах ИМХО проще переписать сов, llolik (ok), 11:51 , 01-Окт-20, (30) +1

Ядро уже собирается на Linux насколько я знаю А винапи там по большей части тол, мяя (?), 22:28 , 01-Окт-20, (37) +1
FYI как-то я встречал похожий OSAL, называется WinPR и используется в FreeRDP, n80 (?), 03:04 , 04-Окт-20, (47) +1

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от JL2001 (ok), 30-Сен-20, 21:18 +/–

баги в miranda с mdbx под wine все починили уже?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от erthink (ok), 30-Сен-20, 21:38 +5 +/–

В Wine не реализованы некоторые принципиальные вещи, без которых libmdbx не может динамически менять размер БД. Это нельзя починить в libmdbx, максимум - чтобы не падало внутри Wine, и это сделано ещё весной.
Тем не менее, Миранда сможет работать с libmdbx под Wine если сделать соответствующие доработки в самой Миранде (например, задавать достаточный, но фиксированный размер БД).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #27

3. Сообщение от x3who (?), 30-Сен-20, 21:44 +3 +/–

Почитал mdbx.h, просто грустно во что превратился язык ц++
  /// \brief Returns the number of bytes.
  MDBX_NOTHROW_PURE_FUNCTION MDBX_CXX20_CONSTEXPR size_t size() const noexcept {
    return length();
  }
Сколько лишних букв! Программирование ради программирования кокое-то :-/

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #5, #8, #31

4. Сообщение от Аноним (4), 30-Сен-20, 21:46 +1 +/–

просто имя у функции длинное

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

5. Сообщение от Аноним (5), 30-Сен-20, 21:56 +2 +/–

как будто до "превращения" ц++ в нем и в ц таких конструкций никто не делал

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6

6. Сообщение от IRASoldier_registered (ok), 30-Сен-20, 22:52 –3 +/–

Нормальная конструкция. Зато не надо писать лишних комментариев.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #11, #26

7. Сообщение от Аноним (7), 30-Сен-20, 22:59 –4 +/–

Почему релизы теперь опять на GitHubе и куда же подевались ваши позиция и принципиальность? Вопрос - риторический, можете не отвечать ;)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

8. Сообщение от Аноним (8), 30-Сен-20, 23:06 +/–

Ну в любом активно развивающимся языке с достаточной историей будут новые фичи которые хочется использовать, но не хочется при этом ломать пользователей сидящих на древнем гoвне.
Про питон стоит напоминать? Я даже не про 2/3 - в одной только 3 ветке уже появились фичи которыми можно было неоднократно сломать запуск кода под старыми питонами. Одну только сигнатуру функции можно было сначала сломать аннотациями типов, потом positional only аргументами. Но питону хорошо - у него старые версии перестают поддерживаться через пять лет, например пользователям 3.5 можно уже две недели как смело плюнуть в рожу и сломать им всё к чертяим, ИЧСХ нет смысла этого не делать потому что EoL версию перестают поддерживать все, значит у них в любом случае что-то сломается если они останутся на 3.5 и попробуют обновлять модули.
А в C++ депрекации можно по пальцам одной руки посчитать, C++98 до сих пор используется в 90% кода и никакого EoL у него нет, а может уже и не будет. Вот и результат. Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #12

9. Сообщение от erthink (ok), 30-Сен-20, 23:51 +2 +/–

Как-то кто-то просил сравнить производительность libmdbx, LMDB и sqlite.
Для этого в GNUMakefile в ветке devel теперь доступна цель "bench-triplet". Чтобы это работало нужно рядом с libmdbx клонировать репозиторий ioarena, сконфигурировать с поддержкой требуемых драйверов СУБД и собрать (предварительно установив sqlite и т.д.).
Остальные подробности бенчмарка см внутри [[https://github.com/erthink/libmdbx/blob/devel/GNUmakefile#L424 GNUMakefile]] и описании [[https://github.com/pmwkaa/ioarena ioarena]]. На всякий - сам по себе бенчмарк не чистит данные от предыдущих прогонов.
Так вот, ради интереса сделал пару прогонов для сравнения. В результатах ниже для каждого кейса смотреть стоит только на первую строку (ибо в драйвере sqlite остальное не реализовано).
Получается:
1) sqlite медленнее примерно в 20 раз в CRUD операциях в no-sync режиме (данные пишутся на диск лениво, при системном сбое вы теряете БД). Такой бенчмарк оценивает "собственную" скорость СУБД почти без привязки к I/O (диск нас почти не сдерживает). Я прогонял на 25.000.000 итерациях.
$ NN=25000000 BENCH_CRUD_MODE=nosync make bench-triplet
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B crud -m nosync -n 25000000 | tee bench-mdbx_25000000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B get,iterate -m nosync -r 4 -n 25000000 | tee -a bench-mdbx_25000000.txt | grep throughput || mv -f bench-mdbx_25000000.txt bench-mdbx_25000000.txt.error
throughput: 203.882Kops/s
throughput:  44.168Mops/s
throughput:   3.765Mops/s
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B crud -m nosync -n 25000000 | tee bench-lmdb_25000000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B get,iterate -m sync -r 4 -n 25000000 | tee -a bench-lmdb_25000000.txt | grep throughput || mv -f bench-lmdb_25000000.txt bench-lmdb_25000000.txt.error
throughput: 187.228Kops/s
throughput:  45.762Mops/s
throughput:   3.853Mops/s
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B crud -m nosync -n 25000000 | tee bench-sqlite3_25000000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B get,iterate -m sync -r 4 -n 25000000 | tee -a bench-sqlite3_25000000.txt | grep throughput || mv -f bench-sqlite3_25000000.txt bench-sqlite3_25000000.txt.error
throughput:   9.599Kops/s

2) sqlite медленнее примерно в 2-3 раза в CRUD операциях в sync режиме (данные записываются на диск при коммите каждой транзакции, допускается использование WAL, при системном сбое вы ничего не теряете). Такой бенчмарк оценивает "наблюдаемую" скорость СУБД с привязкой к I/O-производительности конкретного диска (тут мы в неё упираемся). Я прогонял на 10.000 итерациях.
$ NN=10000 BENCH_CRUD_MODE=sync make bench-triplet
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B crud -m sync -n 10000 | tee bench-mdbx_10000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B get,iterate -m sync -r 4 -n 10000 | tee -a bench-mdbx_10000.txt | grep throughput || mv -f bench-mdbx_10000.txt bench-mdbx_10000.txt.error
throughput:  80.578 ops/s
throughput:   5.902Mops/s
throughput:   3.053Mops/s
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B crud -m sync -n 10000 | tee bench-lmdb_10000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B get,iterate -m sync -r 4 -n 10000 | tee -a bench-lmdb_10000.txt | grep throughput || mv -f bench-lmdb_10000.txt bench-lmdb_10000.txt.error
throughput:  80.146 ops/s
throughput:   4.247Mops/s
throughput:   2.644Mops/s
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B crud -m sync -n 10000 | tee bench-sqlite3_10000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B get,iterate -m sync -r 4 -n 10000 | tee -a bench-sqlite3_10000.txt | grep throughput || mv -f bench-sqlite3_10000.txt bench-sqlite3_10000.txt.error
throughput:  33.919 ops/s
На всякий - эти бенчмарки нельзя считать абсолютно объективными, ибо они воспроизводят лишь некоторый один сценарий использования из крайне большого множества. Тем не менее, результаты ожидаемы (для меня).

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #18, #41

10. Сообщение от erthink (ok), 30-Сен-20, 23:56 +1 +/–

"теперь опять" см. последнюю строчку readme.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #13, #25, #32

11. Сообщение от x3who (?), 01-Окт-20, 00:07 +/–

Согласен в общем случае.. но тут враппер тупой. пролог хидера ввобще жжет напалмом - там и проверки на микрософтовский mad конпелятор, и объявления для специфической системы документировпния кода. Собственно функцонал занимает меньше чем все эти приседания.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21

12. Сообщение от x3who (?), 01-Окт-20, 00:10 +1 +/–

> Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна.
Вообще у них так и сделано - только Ц++11

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

13. Сообщение от x3who (?), 01-Окт-20, 00:17 +1 +/–

>  см. последнюю строчку readme
Я вот лично до последней строчки не добрался, плюнул читать дальше на этом месте: "The next version is under active non-public development from scratch and will be released as MithrilDB"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20

14. Сообщение от x3who (?), 01-Окт-20, 00:25 +/–

Были случаи использования этого в микроконтроллерах? Ну там дейталоггеры какие-нибудь? В таких применениях производительность критична даже не потому, что это время, а потому, что это микроватты-милли-ватты, от которых зависит самый дорогой на Земле ресурс - батарейка, или самый дорргой в космосе - охлаждение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15

15. Сообщение от erthink (ok), 01-Окт-20, 00:40 +/–

Половина (связанных с производительностью) бонусов libmdbx происходит от отображения файла БД в память и последующего совместного использования несколькими процессами. Такие сценарии достаточно далеки от среднего микроконтроллера, у большинства из которых нет MMU.
Тем не менее, если взять некий "микроконтроллер" где работает buildroot, то (скорее всего) libmdbx будет там работать. Но мне о таких запусках ничего не известно, и в целом "СУБД" и "микроконтроллер" не выглядят рациональной парой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16, #48

16. Сообщение от x3who (?), 01-Окт-20, 00:50 +/–

Это для чтения, писатель, как я понимаю, там предполагается один. Или в варианте с ограниченной RAM выигрыш в производятельно
сти пропадает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от erthink (ok), 01-Окт-20, 01:01 +/–

> Это для чтения, писатель, как я понимаю, там предполагается один. Или в
> варианте с ограниченной RAM выигрыш в производятельно
> сти пропадает?
Если ОЗУ мало, то БД просто некуда mmap-ить.
Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
И это при условии что есть MMU для управления виртуальной памятью.
Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит от ОС, включая наличие/отсутствие unified page cache).
Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только некий минимум для загрузки и обновления прошивки на флешке.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #42

18. Сообщение от Аноним (18), 01-Окт-20, 01:18 –1 +/–

Там разница идёт на порядки в зависимости от объёма данных, собственно, потому они и существуют. Некорректно так сравнивать -- они не универсальны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #19

19. Сообщение от erthink (ok), 01-Окт-20, 01:43 +1 +/–

> Там разница идёт на порядки в зависимости от объёма данных, собственно, потому
> они и существуют. Некорректно так сравнивать -- они не универсальны.
Не совсем понятно что именно вы хотели сказать в контексте бенчмарков ioarena. Поэтому я дам некоторые пояснения:
1) Разницы "на порядки в зависимости от объёма данных" не будет, поскольку и libmdbx и sqlite основываются на B-Tree (в обоих случаях зависимость логарифмическая). Но разница будет в тех сценариях, где будет "играть" наличие WAL в sqlite и отсутствие WAL в libmdbx.
2) Сравнивать libmdbx (встраиваемый key-value) и sqlite (встраиваемый sql) конечно некорректно, но всё-таки (если сильно хочется) можно сравнить некоторое подмножество сценариев (эмулировать key-value средствами sql). Что и было сделано.
3) Конечно, корректнее было-бы сравнивать sqlite с https://github.com/PositiveTechnologies/libfpta (где есть "таблички" и вторичные индексы реализованные поверх libmdbx), но готовых инструментов для этого сейчас нет, а зная внутреннее устройство, я могу поспорить что соотношений производительности сохранится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22

20. Сообщение от erthink (ok), 01-Окт-20, 01:58 +1 +/–

Исходный код LMDB - изначально ребус (гляньте https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblm...), а многие около-архитектурные решения там сделаны по принципу "ХХивП".
Поэтому кроме как "from scratch" пути нет, при этом также снимается вопрос с "не-своей" лицензией и появляется возможность избавиться от многих проблем/слабостей (что впрочем требует неслабого research-а).
А допиливание libmdbx - это потому что "мы в ответе за тех, кого приручили", в том числе для актуального production.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #33, #36

21. Сообщение от IRASoldier_registered (ok), 01-Окт-20, 02:00 –3 +/–

А чем плоха амальгамация?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

22. Сообщение от Аноним (18), 01-Окт-20, 02:46 +/–

В контексте данного бенчмарка в наличии key size и value size, и, если я правильно предполагаю их назначение, они будут влиять на результат и WAL тут ни при чём. Это не универсальные дб, все они разрабатываются с оптимизацией под определённые кейсы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23

23. Сообщение от erthink (ok), 01-Окт-20, 03:17 +/–

1) Пока размеры будут "в пределах разумного", существенно разницы не будет.
2) При длинных значениях sqlite будет проигрывать сильнее из-за больших накладных расходах. А libmdbx будет "огурцом" и при гигабайтных размерах, лишь-бы памяти хватило.
3) С длинными ключами несколько сложнее.
- В libmdbx есть ограничения на максимальную длину ключа, которое зависит от размера страницы. Проще говоря, libmdbx не предусматривает поддержку длинных ключей, из-за которых сильно деградирует производительность.
- sqlite напротив реализует максимально гибкую схему и будет "тянуть лямку" сколько сможет, существенно замедляясь на длинных ключах.

Таким образом, libmdbx будет быстрее (думаю, в обозначенных пропорциях или лучше) пока размеры ключей и данных будут в поддерживаемых пределах.
А если эти пределы будут превышены, то сравнивать sqlite по скорости уже будет как-бы не с чем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Андрей (??), 01-Окт-20, 04:34 +3 +/–

> Для оперативной поддержки и ответов на вопросы создана открытая группа в Телеграм.
Оперативно? Вроде же, люди не любят регистрироваться. А там даже зарегистрироваться-то нельзя. Номер телефон требует и нет опции "пропустить". Не попасть в этот телеграм. Вообще.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

25. Сообщение от Аноним (7), 01-Окт-20, 09:10 +/–

>This is a mirror
Да и не совсем это "зеркало". Потому что вы создаёте issue на баг-трекере этого проекта в GitHub, и вообще им пользуетесь, потому что если закрыть баг-трекер на GitHub, как обычно делают, если github - всего лишь зеркало, то на росоподелку никто не пойдёт регаться.

Учитывая
>  1 contribution in private repositories Oct 1
> 189 contributions in private repositories Sep 1 – Sep 30
очень не похоже на бойкотирование GitHub.

P.S. Зачем такое в ReadMe пихать? В таком случае, если тот же исходник засунуть на "оригинал", то сообщение будет не очень верно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

26. Сообщение от Аноним (26), 01-Окт-20, 09:46 +/–

я вроде не говорил, что ненормальная. А как помогут комментарии с танцами вокруг разных версий разных компиляторов с разными хаками?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

27. Сообщение от _hide_ (ok), 01-Окт-20, 10:55 –2 +/–

Пользуйтесь Dbx_sqlite.dll, если приспичило вайнить миранду

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #28

28. Сообщение от erthink (ok), 01-Окт-20, 11:15 +2 +/–

На всякий
1) sqlite не работает под Wine по схожим причинам, см https://github.com/miranda-ng/miranda-ng/issues/2323
2) С плагином dbx_sqlite связано 8 багов (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is...), а с плагином libmdbx по-сути ни одного (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is...): из двух один баг является напоминалкой об упомянутой выше доработке, а второй про роспись памяти где-то в миранде (вовсе не факт что в плагине).
3) C sqlite будет несколько медленнее (см https://www.opennet.me/openforum/vsluhforumID3/121987.html#9), но впрочем очень сильно зависит от реализации самих "плагинов".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #34

29. Сообщение от erthink (ok), 01-Окт-20, 11:20 +/–

/trolling mode on
Для перехода на Миранду осталось переписать её на Rust и сделать переносимой (отвязать от Windows).
/trolling mode off

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #30

30. Сообщение от llolik (ok), 01-Окт-20, 11:51 +1 +/–

> и сделать переносимой (отвязать от Windows).
Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к. GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #37, #47

31. Сообщение от Аноним (31), 01-Окт-20, 12:14 +2 +/–

Тут дело не в языке, а в количестве компиляторов и их версий и желании разработчиков поддерживать продукт для большого количества платформ.
Фактически тут все идентификаторы в верхнем регистре - это макроподставновки препроцессора, которые определены где-то выше и имеют значения в зависимости от выбранного компилятора для сборки
По факту это можно для типовых современных компиляторов заменить на :
constexpr size_t size() const noexcept {
  return length ();
}

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

32. Сообщение от andy (??), 01-Окт-20, 15:51 –4 +/–

Поглядел. Крым не российский, да. Какие проблемы-то?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

33. Сообщение от Аноним (33), 01-Окт-20, 15:51 +/–

> Исходный код LMDB - изначально ребус, а многие около-архитектурные решения там сделаны по принципу "ХХивП".
Надо эту цитату вставлять в каждую новость про LMDB. Сразу отпадёт много вопросов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

34. Сообщение от _hide_ (ok), 01-Окт-20, 19:16 +/–

> На всякий
> 1) sqlite не работает под Wine по схожим причинам, см https://github.com/miranda-ng/miranda-ng/issues/2323
У меня работает, что я сделал неправильно? Правда под x32. И да, плагин контакт листа я тоже поменял.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #35

35. Сообщение от _ (??), 01-Окт-20, 21:28 +1 +/–

Может у dartraiden-а спросить нафига он завел эту багу, если всё работает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #40

36. Сообщение от _ (??), 01-Окт-20, 21:38 +/–

Ревьюверы кода LMDB иного мнения: "impressive codebase", "the implementation is really quite brilliant".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #39

37. Сообщение от мяя (?), 01-Окт-20, 22:28 +1 +/–

>> и сделать переносимой (отвязать от Windows).
> Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать
> совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или
> писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к.
> GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).
Ядро уже собирается на Linux насколько я знаю. А винапи там по большей части только в GUI у плагинов. Со временем отвяжут его и всё будет работать везде.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

39. Сообщение от mos87 (ok), 02-Окт-20, 00:48 +/–

Формулировки похожи на то как бы описывал своё творение Говард

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

40. Сообщение от dartraiden (?), 02-Окт-20, 14:11 +1 +/–

Не работает оно (убунта 20.04 + последний стабильный/тестовый вайн). На 32-битных дистрах не пробовал, да.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #49

41. Сообщение от phprus (ok), 02-Окт-20, 20:47 +/–

Скажите, пожалуйста, а насколько хорошо libmdbx подойдет для хранения счетчиков, если данные - это ключ 16 байт и счетчик, которому надо делать инкремент/декремент и удаление? Время жизни отдельного ключа небольшое (от секунд до часов и порядка десятков операций ++/--, но редко бывают и десятки тысяч операций). Одновременно существующих ключей/счетчиков - тысячи, редко десятки тысяч. Вероятность конкурентных операций на один ключ мала. Пожелание - не пухнуть базой, те иметь предсказуемое ограничение на размер файлов на диске сверху.
Или может быть вы можете порекомендовать что-то другое готовое для хранения короткоживущих счетчиков?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #43

42. Сообщение от x3who (?), 03-Окт-20, 01:13 +/–

>> Это для чтения, писатель, как я понимаю, там предполагается один. Или в
>> варианте с ограниченной RAM выигрыш в производятельно
>> сти пропадает?
> Если ОЗУ мало, то БД просто некуда mmap-ить.
> Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
> И это при условии что есть MMU для управления виртуальной памятью.
> Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит
> от ОС, включая наличие/отсутствие unified page cache).
> Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только
> некий минимум для загрузки и обновления прошивки на флешке.
Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски не знает, как и персональный компъютер или мобилка или сервер какой. Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту БД к логгингу, и если можно - то какие требования к железу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #44

43. Сообщение от erthink (ok), 03-Окт-20, 14:54 +1 +/–

Для короткоживущих данных, как правило, лучше подходят БД на основе LSM (https://ru.wikipedia.org/wiki/LSM-п╢п╣я─п╣п╡п╬).
Бонус там в том, что при слиянии внутри LSM удаление данных почти бесплатно.
Вам стоит попробовать/посмотреть на tarantool и rocksdb.
Однако, однозначного универсального ответа нет. В конкретных случаях отдельные нюансы могут сделать использование LSM не рациональным или невозможным. В частности, реальная эффективность LSM непосредственно зависит от того насколько хорошо в конкретной ОС и конкретной файловой системе работает APPEND режим для файлов. Т.е. в вашем случае, при использовании LSM, скорее всего всё будет хорошо в Linux, а в Windows может быть значительно хуже.
Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный доступ и какова пропорция по объему операций чтения и записи.
Если много операций чтения или нужен доступ к БД из нескольких процессов, то libmdbx однозначно выиграет - не будет НИКАКИХ накладных расходов.
Если в основном будут операции изменения данных и нужны транзакции, то (думаю) лучше взять tarantool.

Если не важна стабильность по времени выполнения отдельных операций и не важны транзакции, то rockdb.
И т.д., таких "если" наберется еще пара десятков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #45

44. Сообщение от erthink (ok), 03-Окт-20, 15:19 +1 +/–

> Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски
> не знает, как и персональный компъютер или мобилка или сервер какой.
> Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную
> информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту
> БД к логгингу, и если можно - то какие требования к
> железу.
Чтобы использовать libmdbx как есть, без каких-либо доработок, то от системы требуется поддержка mmap() и PTHREAD_MUTEX_ROBUST. Проще говоря, если на микроконтроллере есть MMU и можно запустить linux (buildroot и т.п.).
При необходимости, конечно, можно портировать libmdbx на более слабые платформы, в том числе на "голое железо". Требуется не так уж много (32-битный процессор, мегабайт ОЗУ и блочный обмен с "диском"). Грубо говоря, достаточно реализовать соответствующие функции libc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #46

45. Сообщение от phprus (ok), 03-Окт-20, 17:06 +/–

Спасибо за ответ!
Буду тестировать.
> Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный
> доступ и какова пропорция по объему операций чтения и записи.
Чтение/запись почти одинаково с маленьким перевесом чтения. Так как это счетчики, то транзакции нужны (отдельные операции в основном имеют вид: прочитали, изменили значение, записали значение или удалили ключ).
Многопоточный доступ и на чтение, и на изменение нужен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от x3who (?), 04-Окт-20, 01:49 +/–

> При необходимости, конечно, можно портировать libmdbx на более слабые платформы, в том
> числе на "голое железо". Требуется не так уж много (32-битный процессор,
> мегабайт ОЗУ и блочный обмен с "диском"). Грубо говоря, достаточно реализовать
> соответствующие функции libc.
Не, мегабайт жирновато для _микро_-контроллера :)
Но вообще код интересный, нашел в src/osal.c код, который ммапит файл. Даже не знал, что в венде это есть - теперь знаю где посмотреть пример.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от n80 (?), 04-Окт-20, 03:04 +1 +/–

FYI: как-то я встречал /похожий/ OSAL, называется WinPR и используется в FreeRDP (замена rdesktop). Ну и libwine, куда ж без него. Вроде, что-то ещё вспоминается, но уже более смутно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

48. Сообщение от n80 (?), 04-Окт-20, 03:19 +/–

offtop/2: если что, в sqlite3 есть PRAGMA mmap_size=x. Насколько помню, по умолчанию там 0, т.е. mmap не используется. Как-то раз удавалось за счёт включения этой настройки немного ускорить существующую базу. В репозитории ioarena не нашёл упоминания mmap_size, т.е. возможно что этот момент был упущен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #50

49. Сообщение от _hide_ (ok), 05-Окт-20, 12:55 +/–

> Не работает оно (убунта 20.04 + последний стабильный/тестовый вайн). На 32-битных дистрах
> не пробовал, да.
О да, дистр тут не важен - важно, чтобы Миранда и Вайн был под x32 (настраивается Вайн при создании профиля, Миранда качается нужно версии).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

50. Сообщение от erthink (ok), 06-Окт-20, 15:09 +/–

> offtop/2: если что, в sqlite3 есть PRAGMA mmap_size=x. Насколько помню, по умолчанию
> там 0, т.е. mmap не используется. Как-то раз удавалось за счёт
> включения этой настройки немного ускорить существующую базу. В репозитории ioarena не
> нашёл упоминания mmap_size, т.е. возможно что этот момент был упущен.
mmap в sqlite будет немного ускорять чтение, за счет потенциального "расширения" page cache на весь объем данных. Но libmdbx тут (в сценариях интенсивного чтения) всё равно _всегда_ в разы быстрее, ибо примерно совсем не выполняет лишних операций (минимум накладных расходов). В Сети можно найти достаточно результатов бенчмарков (sqlite vs LMDB) подтверждающих это. Навскидку вот один из них https://hsto.org/webt/uw/du/4z/uwdu4zfgewvmqwkzuzaszja_qeq.png (фон прозначный, в зависимости от браузера может получится черное на черном).
В сценариях с интенсивной записью/обновлением (в том числе в показанных ранее CRUD) mmap существенного влияния не окажет. На всякий добавил прагму в драйвер ioarena и повторил один из тестов.
Патч:
```
diff --git a/src/drivers/ia_sqlite3.c b/src/drivers/ia_sqlite3.c
index 96a3e45..cad1c30 100644
--- a/src/drivers/ia_sqlite3.c
+++ b/src/drivers/ia_sqlite3.c
@@ -77,7 +77,7 @@ static int ia_sqlite3_open(const char *datadir) {
     snprintf(cmd_buf, CMD_SIZE, "PRAGMA journal_mode=%s;", "WAL");
     break;
   case IA_WAL_OFF:
-    snprintf(cmd_buf, CMD_SIZE, "PRAGMA journal_mode=%s;", "OFF");
+    snprintf(cmd_buf, CMD_SIZE, "PRAGMA journal_mode=%s; PRAGMA mmap_size=%u;", "OFF", 1024*1024*512);
     break;
   default:
     ia_log("error: %s(): unsupported walmode %s", __func__,
```
Результат:
```
$ NN=25000000 BENCH_CRUD_MODE=nosync make bench-triplet
[...]
LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B crud -m nosync -n 25000000 | tee bench-sqlite3_25000000.txt | grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B get,iterate -m nosync -r 4 -n 25000000 | tee -a bench-sqlite3_25000000.txt | grep throughput || mv -f bench-sqlite3_25000000.txt bench-sqlite3_25000000.txt.error
throughput:   7.794Kops/s
```
Т.е. стало хуже, без "PRAGMA mmap_size=#" было 9.599Kops/s.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #51

51. Сообщение от n80 (?), 06-Окт-20, 15:16 +/–

О как. У меня было по большей части чтение, поэтому и получилось некоторое ускорение.
Понятно, что специализированное хранилище в разы быстрее, но было интересно понять, насколько удалось выжать всё из sqlite3 (и не только понять, какие опции используются, но и почему). Опять же, момент с замедлением записи при включении mmap оказался неожиданностью.
Премного благодарю за информацию!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #52

52. Сообщение от erthink (ok), 06-Окт-20, 17:59 +/–

На всякий, для информации.
1)
Заметил что при 25M итераций размер БД в sqlite получается порядка 2.5Gb.
Соответственно, заданная pragma не покрывает все данные.
Поэтому перепроверил задав mmap_size в 3Gb, но результат не изменился (медленнее чем без mmap).
2)
Вспомнил что как-то был разговор о том, что неплохо-хо бы также сравнить размер БД (sqlite vs libmdbx), при одинаковом тестовом сценарии.
Итого, в этом конкретном случае, получилось 2.5Gb в sqlite против 2Gb в libmdbx.
Кроме этого, посредством mdbx_chk можно узнать больше подробностей (заполненность страниц и т.п.)
$ ./mdbx_chk -vv .
mdbx_chk v0.9.1-11-g9d1bfa5b2 (2020-10-06T01:34:14+03:00, T-8f7227d37aed94d650826896bb3e69b34efd254c)
Running for . in 'read-only' mode...
   open-MADV_DONTNEED 522315..524288
   readahead OFF 0..522315
- monopolistic mode
- current boot-id b7e779bb77d4d4d6-f890ee824260423e
- pagesize 4096 (4096 system), max keysize 1300..1344, max readers 120
- mapsize 137438953472 (128.00 Gb)
- dynamic datafile: 1048576 (1.00 Mb) .. 137438953472 (128.00 Gb), +67108864 (64.00 Mb), -67108864 (64.00 Mb)
- current datafile: 2147483648 (2.00 Gb), 524288 pages
- transactions: recent 25000003, latter reader 25000003, lag 0
- meta-0: steady txn#25000003, head
- meta-1: weak-intact (same boot-id) txn#25000001, tail
- meta-2: weak-intact (same boot-id) txn#25000002, stay
- performs check for meta-pages clashes
- performs full check recent-txn-id with meta-pages
Traversal b-tree by txn#25000003...
- pages: walked 522299, left/unused 16
     @GC: subtotal 1, leaf 1
     @MAIN: subtotal 522295, branch 4503, leaf 517792
     @META: subtotal 3
- usage: total 2139336704 bytes, payload 1473954308 (68.9%), unused 665382396 (31.1%)
- summary: average fill 68.9%, 0 problems
Processing '@MAIN'...
- key-value kind: usual-key => single-value, flags: none
- page size 4096, entries 25000000
- b-tree depth 4, pages: branch 4503, leaf 517792, overflow 0
- summary: 25000000 records, 0 dups, 400000000 key's bytes, 800000000 data's bytes, 0 problems
Processing '@GC'...
- key-value kind: ordinal-key => single-value, flags: integerkey
- page size 4096, entries 2
- b-tree depth 1, pages: branch 0, leaf 1, overflow 0
- fixed key-size 8
- summary: 2 records, 0 dups, 16 key's bytes, 72 data's bytes, 0 problems
- space: 33554432 total pages, backed 524288 (1.6%), allocated 522315 (1.6%), remained 33032117 (98.4%), used 522299 (1.6%), gc 16 (0.0%), detained 8 (0.0%), reclaimable 8 (0.0%), available 33032125 (98.4%)
No error is detected, elapsed 10.331 seconds

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от JL2001 (ok), 30-Сен-20, 21:18	+/–
баги в miranda с mdbx под wine все починили уже?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2

2. Сообщение от erthink (ok), 30-Сен-20, 21:38	+5 +/–
В Wine не реализованы некоторые принципиальные вещи, без которых libmdbx не может динамически менять размер БД. Это нельзя починить в libmdbx, максимум - чтобы не падало внутри Wine, и это сделано ещё весной. Тем не менее, Миранда сможет работать с libmdbx под Wine если сделать соответствующие доработки в самой Миранде (например, задавать достаточный, но фиксированный размер БД).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #27

3. Сообщение от x3who (?), 30-Сен-20, 21:44	+3 +/–
Почитал mdbx.h, просто грустно во что превратился язык ц++ /// \brief Returns the number of bytes. MDBX_NOTHROW_PURE_FUNCTION MDBX_CXX20_CONSTEXPR size_t size() const noexcept { return length(); } Сколько лишних букв! Программирование ради программирования кокое-то :-/
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #4, #5, #8, #31

4. Сообщение от Аноним (4), 30-Сен-20, 21:46	+1 +/–
просто имя у функции длинное
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

5. Сообщение от Аноним (5), 30-Сен-20, 21:56	+2 +/–
как будто до "превращения" ц++ в нем и в ц таких конструкций никто не делал
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #6

6. Сообщение от IRASoldier_registered (ok), 30-Сен-20, 22:52	–3 +/–
Нормальная конструкция. Зато не надо писать лишних комментариев.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #11, #26

7. Сообщение от Аноним (7), 30-Сен-20, 22:59	–4 +/–
Почему релизы теперь опять на GitHubе и куда же подевались ваши позиция и принципиальность? Вопрос - риторический, можете не отвечать ;)
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10

8. Сообщение от Аноним (8), 30-Сен-20, 23:06	+/–
Ну в любом активно развивающимся языке с достаточной историей будут новые фичи которые хочется использовать, но не хочется при этом ломать пользователей сидящих на древнем гoвне. Про питон стоит напоминать? Я даже не про 2/3 - в одной только 3 ветке уже появились фичи которыми можно было неоднократно сломать запуск кода под старыми питонами. Одну только сигнатуру функции можно было сначала сломать аннотациями типов, потом positional only аргументами. Но питону хорошо - у него старые версии перестают поддерживаться через пять лет, например пользователям 3.5 можно уже две недели как смело плюнуть в рожу и сломать им всё к чертяим, ИЧСХ нет смысла этого не делать потому что EoL версию перестают поддерживать все, значит у них в любом случае что-то сломается если они останутся на 3.5 и попробуют обновлять модули. А в C++ депрекации можно по пальцам одной руки посчитать, C++98 до сих пор используется в 90% кода и никакого EoL у него нет, а может уже и не будет. Вот и результат. Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #12

9. Сообщение от erthink (ok), 30-Сен-20, 23:51	+2 +/–
Как-то кто-то просил сравнить производительность libmdbx, LMDB и sqlite. Для этого в GNUMakefile в ветке devel теперь доступна цель "bench-triplet". Чтобы это работало нужно рядом с libmdbx клонировать репозиторий ioarena, сконфигурировать с поддержкой требуемых драйверов СУБД и собрать (предварительно установив sqlite и т.д.). Остальные подробности бенчмарка см внутри [[https://github.com/erthink/libmdbx/blob/devel/GNUmakefile#L424 GNUMakefile]] и описании [[https://github.com/pmwkaa/ioarena ioarena]]. На всякий - сам по себе бенчмарк не чистит данные от предыдущих прогонов. Так вот, ради интереса сделал пару прогонов для сравнения. В результатах ниже для каждого кейса смотреть стоит только на первую строку (ибо в драйвере sqlite остальное не реализовано). Получается: 1) sqlite медленнее примерно в 20 раз в CRUD операциях в no-sync режиме (данные пишутся на диск лениво, при системном сбое вы теряете БД). Такой бенчмарк оценивает "собственную" скорость СУБД почти без привязки к I/O (диск нас почти не сдерживает). Я прогонял на 25.000.000 итерациях. $ NN=25000000 BENCH_CRUD_MODE=nosync make bench-triplet LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B crud -m nosync -n 25000000 \| tee bench-mdbx_25000000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B get,iterate -m nosync -r 4 -n 25000000 \| tee -a bench-mdbx_25000000.txt \| grep throughput \|\| mv -f bench-mdbx_25000000.txt bench-mdbx_25000000.txt.error throughput: 203.882Kops/s throughput: 44.168Mops/s throughput: 3.765Mops/s LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B crud -m nosync -n 25000000 \| tee bench-lmdb_25000000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B get,iterate -m sync -r 4 -n 25000000 \| tee -a bench-lmdb_25000000.txt \| grep throughput \|\| mv -f bench-lmdb_25000000.txt bench-lmdb_25000000.txt.error throughput: 187.228Kops/s throughput: 45.762Mops/s throughput: 3.853Mops/s LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B crud -m nosync -n 25000000 \| tee bench-sqlite3_25000000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B get,iterate -m sync -r 4 -n 25000000 \| tee -a bench-sqlite3_25000000.txt \| grep throughput \|\| mv -f bench-sqlite3_25000000.txt bench-sqlite3_25000000.txt.error throughput: 9.599Kops/s 2) sqlite медленнее примерно в 2-3 раза в CRUD операциях в sync режиме (данные записываются на диск при коммите каждой транзакции, допускается использование WAL, при системном сбое вы ничего не теряете). Такой бенчмарк оценивает "наблюдаемую" скорость СУБД с привязкой к I/O-производительности конкретного диска (тут мы в неё упираемся). Я прогонял на 10.000 итерациях. $ NN=10000 BENCH_CRUD_MODE=sync make bench-triplet LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B crud -m sync -n 10000 \| tee bench-mdbx_10000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D mdbx -B get,iterate -m sync -r 4 -n 10000 \| tee -a bench-mdbx_10000.txt \| grep throughput \|\| mv -f bench-mdbx_10000.txt bench-mdbx_10000.txt.error throughput: 80.578 ops/s throughput: 5.902Mops/s throughput: 3.053Mops/s LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B crud -m sync -n 10000 \| tee bench-lmdb_10000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D lmdb -B get,iterate -m sync -r 4 -n 10000 \| tee -a bench-lmdb_10000.txt \| grep throughput \|\| mv -f bench-lmdb_10000.txt bench-lmdb_10000.txt.error throughput: 80.146 ops/s throughput: 4.247Mops/s throughput: 2.644Mops/s LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B crud -m sync -n 10000 \| tee bench-sqlite3_10000.txt \| grep throughput && LD_LIBRARY_PATH="./:${LD_LIBRARY_PATH}" ../ioarena/@BUILD/src/ioarena -D sqlite3 -B get,iterate -m sync -r 4 -n 10000 \| tee -a bench-sqlite3_10000.txt \| grep throughput \|\| mv -f bench-sqlite3_10000.txt bench-sqlite3_10000.txt.error throughput: 33.919 ops/s На всякий - эти бенчмарки нельзя считать абсолютно объективными, ибо они воспроизводят лишь некоторый один сценарий использования из крайне большого множества. Тем не менее, результаты ожидаемы (для меня).
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #14, #18, #41

10. Сообщение от erthink (ok), 30-Сен-20, 23:56	+1 +/–
"теперь опять" см. последнюю строчку readme.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #13, #25, #32

11. Сообщение от x3who (?), 01-Окт-20, 00:07	+/–
Согласен в общем случае.. но тут враппер тупой. пролог хидера ввобще жжет напалмом - там и проверки на микрософтовский mad конпелятор, и объявления для специфической системы документировпния кода. Собственно функцонал занимает меньше чем все эти приседания.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #21

12. Сообщение от x3who (?), 01-Окт-20, 00:10	+1 +/–
> Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна. Вообще у них так и сделано - только Ц++11
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

13. Сообщение от x3who (?), 01-Окт-20, 00:17	+1 +/–
> см. последнюю строчку readme Я вот лично до последней строчки не добрался, плюнул читать дальше на этом месте: "The next version is under active non-public development from scratch and will be released as MithrilDB"
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #20

14. Сообщение от x3who (?), 01-Окт-20, 00:25	+/–
Были случаи использования этого в микроконтроллерах? Ну там дейталоггеры какие-нибудь? В таких применениях производительность критична даже не потому, что это время, а потому, что это микроватты-милли-ватты, от которых зависит самый дорогой на Земле ресурс - батарейка, или самый дорргой в космосе - охлаждение.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #15

15. Сообщение от erthink (ok), 01-Окт-20, 00:40	+/–
Половина (связанных с производительностью) бонусов libmdbx происходит от отображения файла БД в память и последующего совместного использования несколькими процессами. Такие сценарии достаточно далеки от среднего микроконтроллера, у большинства из которых нет MMU. Тем не менее, если взять некий "микроконтроллер" где работает buildroot, то (скорее всего) libmdbx будет там работать. Но мне о таких запусках ничего не известно, и в целом "СУБД" и "микроконтроллер" не выглядят рациональной парой.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #16, #48

16. Сообщение от x3who (?), 01-Окт-20, 00:50	+/–
Это для чтения, писатель, как я понимаю, там предполагается один. Или в варианте с ограниченной RAM выигрыш в производятельно сти пропадает?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от erthink (ok), 01-Окт-20, 01:01	+/–
> Это для чтения, писатель, как я понимаю, там предполагается один. Или в > варианте с ограниченной RAM выигрыш в производятельно > сти пропадает? Если ОЗУ мало, то БД просто некуда mmap-ить. Т.е. если ОЗУ недостаточно, то будут постоянные page faults. И это при условии что есть MMU для управления виртуальной памятью. Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит от ОС, включая наличие/отсутствие unified page cache). Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только некий минимум для загрузки и обновления прошивки на флешке.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #42

18. Сообщение от Аноним (18), 01-Окт-20, 01:18	–1 +/–
Там разница идёт на порядки в зависимости от объёма данных, собственно, потому они и существуют. Некорректно так сравнивать -- они не универсальны.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #19

19. Сообщение от erthink (ok), 01-Окт-20, 01:43	+1 +/–
> Там разница идёт на порядки в зависимости от объёма данных, собственно, потому > они и существуют. Некорректно так сравнивать -- они не универсальны. Не совсем понятно что именно вы хотели сказать в контексте бенчмарков ioarena. Поэтому я дам некоторые пояснения: 1) Разницы "на порядки в зависимости от объёма данных" не будет, поскольку и libmdbx и sqlite основываются на B-Tree (в обоих случаях зависимость логарифмическая). Но разница будет в тех сценариях, где будет "играть" наличие WAL в sqlite и отсутствие WAL в libmdbx. 2) Сравнивать libmdbx (встраиваемый key-value) и sqlite (встраиваемый sql) конечно некорректно, но всё-таки (если сильно хочется) можно сравнить некоторое подмножество сценариев (эмулировать key-value средствами sql). Что и было сделано. 3) Конечно, корректнее было-бы сравнивать sqlite с https://github.com/PositiveTechnologies/libfpta (где есть "таблички" и вторичные индексы реализованные поверх libmdbx), но готовых инструментов для этого сейчас нет, а зная внутреннее устройство, я могу поспорить что соотношений производительности сохранится.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #22

20. Сообщение от erthink (ok), 01-Окт-20, 01:58	+1 +/–
Исходный код LMDB - изначально ребус (гляньте https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblm...), а многие около-архитектурные решения там сделаны по принципу "ХХивП". Поэтому кроме как "from scratch" пути нет, при этом также снимается вопрос с "не-своей" лицензией и появляется возможность избавиться от многих проблем/слабостей (что впрочем требует неслабого research-а). А допиливание libmdbx - это потому что "мы в ответе за тех, кого приручили", в том числе для актуального production.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #33, #36

21. Сообщение от IRASoldier_registered (ok), 01-Окт-20, 02:00	–3 +/–
А чем плоха амальгамация?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

22. Сообщение от Аноним (18), 01-Окт-20, 02:46	+/–
В контексте данного бенчмарка в наличии key size и value size, и, если я правильно предполагаю их назначение, они будут влиять на результат и WAL тут ни при чём. Это не универсальные дб, все они разрабатываются с оптимизацией под определённые кейсы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19 Ответы: #23

23. Сообщение от erthink (ok), 01-Окт-20, 03:17	+/–
1) Пока размеры будут "в пределах разумного", существенно разницы не будет. 2) При длинных значениях sqlite будет проигрывать сильнее из-за больших накладных расходах. А libmdbx будет "огурцом" и при гигабайтных размерах, лишь-бы памяти хватило. 3) С длинными ключами несколько сложнее. - В libmdbx есть ограничения на максимальную длину ключа, которое зависит от размера страницы. Проще говоря, libmdbx не предусматривает поддержку длинных ключей, из-за которых сильно деградирует производительность. - sqlite напротив реализует максимально гибкую схему и будет "тянуть лямку" сколько сможет, существенно замедляясь на длинных ключах. Таким образом, libmdbx будет быстрее (думаю, в обозначенных пропорциях или лучше) пока размеры ключей и данных будут в поддерживаемых пределах. А если эти пределы будут превышены, то сравнивать sqlite по скорости уже будет как-бы не с чем.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

24. Сообщение от Андрей (??), 01-Окт-20, 04:34	+3 +/–
> Для оперативной поддержки и ответов на вопросы создана открытая группа в Телеграм. Оперативно? Вроде же, люди не любят регистрироваться. А там даже зарегистрироваться-то нельзя. Номер телефон требует и нет опции "пропустить". Не попасть в этот телеграм. Вообще.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #29

25. Сообщение от Аноним (7), 01-Окт-20, 09:10	+/–
>This is a mirror Да и не совсем это "зеркало". Потому что вы создаёте issue на баг-трекере этого проекта в GitHub, и вообще им пользуетесь, потому что если закрыть баг-трекер на GitHub, как обычно делают, если github - всего лишь зеркало, то на росоподелку никто не пойдёт регаться. Учитывая > 1 contribution in private repositories Oct 1 > 189 contributions in private repositories Sep 1 – Sep 30 очень не похоже на бойкотирование GitHub. P.S. Зачем такое в ReadMe пихать? В таком случае, если тот же исходник засунуть на "оригинал", то сообщение будет не очень верно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

26. Сообщение от Аноним (26), 01-Окт-20, 09:46	+/–
я вроде не говорил, что ненормальная. А как помогут комментарии с танцами вокруг разных версий разных компиляторов с разными хаками?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

27. Сообщение от _hide_ (ok), 01-Окт-20, 10:55	–2 +/–
Пользуйтесь Dbx_sqlite.dll, если приспичило вайнить миранду
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #28

28. Сообщение от erthink (ok), 01-Окт-20, 11:15	+2 +/–
На всякий 1) sqlite не работает под Wine по схожим причинам, см https://github.com/miranda-ng/miranda-ng/issues/2323 2) С плагином dbx_sqlite связано 8 багов (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is...), а с плагином libmdbx по-сути ни одного (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is...): из двух один баг является напоминалкой об упомянутой выше доработке, а второй про роспись памяти где-то в миранде (вовсе не факт что в плагине). 3) C sqlite будет несколько медленнее (см https://www.opennet.me/openforum/vsluhforumID3/121987.html#9), но впрочем очень сильно зависит от реализации самих "плагинов".
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #34

29. Сообщение от erthink (ok), 01-Окт-20, 11:20	+/–
/trolling mode on Для перехода на Миранду осталось переписать её на Rust и сделать переносимой (отвязать от Windows). /trolling mode off
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #30

30. Сообщение от llolik (ok), 01-Окт-20, 11:51	+1 +/–
> и сделать переносимой (отвязать от Windows). Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к. GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #29 Ответы: #37, #47