После пяти лет разработки доступен для тестирования второй кандидат в релизы библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базой данных класса ключ-значение. Текущая версия (0.5) является техническим релизом, отмечает завершение каких-либо доработок и переход к фазе публичного финального тестирования и стабилизации, с последующем формированием первого полноценного релиза библиотеки. Код libmdbx распространяется под лицензией OpenLDAP Public License...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52147
Матан кокой-то. И не холиварно! Скушшо, а такие новости и без вас (наверно) на fossies будут.
Как раз недавно пригодилась нативная альтернатива mapdb. Попробую
Алсо если кто-то уже использует, как оно для совсем маленьких датасетов?
Также хорошо как и для больших.
На самом деле, то насколько (не)подходит MDBX определяется другим.MDBX совсем не подойдет, если:
- много изменений, которые нельзя потерять = нужна БД с WAL.
- много коротко живущих изменений (значения часто обновляются) и/или много коротко живущих данных (данные удаляются вскоре после добавления) = нужна БД на основе LSM.
- требуются долгие читающие транзакции на фоне постоянных изменений.
- требуется несколько пишущих транзакций одновременно.MDBX очень хорошо подойдет, если:
- много чтения и мало изменений (характерный пример LDAP).
- много изменений, но данные можно потерять при системной аварии.
Это как Berkeley DB?
Нет.
> Это как Berkeley DB?И да и нет.
MDBX является сильно переработанным форком LMDB, в свою очередь LMDB была сделана для замены Berkeley DB в OpenLDAP.
Поэтому API libmdbx похоже и на dbm и на Berkeley DB, но существенно проще.
До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.
> До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.Исторически прародитель обсуждаемой "СУБД" создавался для замены BerkeleyDB, в частности из-за неустраняемых проблем в BerkeleyDB с взаимными блокировками и багами в кешировании (могут читаться старые данные и т.д.). Результат получился не только стабильнее, но и существенно быстрее BerkeleyDB. Поэтому многие проекты давно приняли решение об уходе с BerkeleyDB, для примера см абзац в википедии https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berke.... Поэтому вопрос "дорасти до BerkeleyDB" давно не стоит.
По поводу отношения к "СУБД" - ваше мнение сильно не совпадает с терминологией принятой в индустрии, см определение что такое "Встраиваемая база данных" в википедии https://ru.wikipedia.org/wiki/%D0%92%D1%.... Собственно вы вправе иметь любое мнение, но если оно противоречит принятой терминологии, то лучше это как-то обозначать (а то можно подумать что вы не владеете терминологией).
Вторичные индексы, в классическом понимании, требуют некоторого подобия колонок/ячеек, т.е. хранения значений в виде кортежей, с соответствующими ограничениями в виде определяемой схемы.
Таким образом, классических "вторичных индексов" не может быть в классическом key-value, так как value непрозрачно с точки зрения БД и там нечего индексировать. Это ни хорошо и не плохо - просто добавление схемы и вторичных индексов означает отказа от присущих key-value простоты и минимализма.Тем не менее, дополнительные "пользовательские/вторичные" индексы реализуются "поверх" key-value очень просто. Настолько просто, что использование "движка" key-value де-факто подразумевает использование дополнительных индексов по-необходимости. Поэтому отсылка ко вторичным индексам, на самом деле, обесценивает ваше мнение ибо выдаёт отсутствия опыта разработки с использованием СУБД класса key-value.
Курсоров и транзакций во многих СУБД действительно нет, в частности во многих движках основанных на LSM. Но определяется это целью создания этих СУБД и ограничениями (эффективностью) вследствие внутреннего устройства, а не какими-либо критериями полноты API или критериям соответствия теримину "СУБД".
Кстати, в MDBX есть и курсоры с предельно эффективными операциями поиска и переходов, и ACID-транзакции. А вторичные индексы в явном виде есть в libfpta - это "табличная" СУБД основанная на libmdbx.
Лео, ни ваши демонстративные поливания некоторых серьёзных людей негативом (путём называния их сначала criminal а потом felonами), в профиле на гитхабе, ни работа над DPI в серьёзных структурах всем известных не менее серьёзных людей, вам чести не делают.Раньше в у вас в гитхабе красовалась надпись о том, что вы валите с гитхаба в знак протеста против блокировки крыма, а гитлер с бандерой не были упомянуты, только сорос и ходор. Что-то ваш протест выдохся, а закон Годвина - выполнился.
Неужели вам не стыдно всем этим заниматься?
> Библиотека MDBX является существенно переработанным ответвлением от LMDBпрозрачная замена предполагается?
например для самбы.
> прозрачная замена предполагается?
> например для самбы.Совсем прозрачная - нет, поскольку у LMDB есть совершенно кошмарная специфика.
Например:
- в LMDB курсоры нужно по-разному закрывать/переиспользовать в пишущих и читающих транзакциях.
- в LMDB DBI-хендлы нужно открывать заранее.
- в LMDB разный формат БД для 32-битных и 64-битных платформ (не считая зависимости от endianess).Но никаких проблем с заменой быть не должно, только плюсы.
В частности, в MDBX есть авто-компактификация и LIFO-политика для переработки мусора.
Поэтому в MDBX нет одной из мега-проблем LMDB - если БД распухает (например из-за долгих читающих транзакций), то это навечно и при этом еще деградирует производительность.
спасибо. как раз то что хотел услышать.
нужно присмотреться к сабжу
Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость? Ну вроде бы это неплохо, но таких немало. Чем эта выделяется? У неё < 300 звёзд на гитхабе и не очень ясно, где она используется. То есть выглядит так, что это слабоизвестная экспериментальная разработка в области, где есть дохрена оттестированных проверенных временем решений.
Потому что это форк LMDB. LMDB - это широко известная key-value база для хайлоада. Используется в Firefox и rpm в том числе.
Странно, что нет результатов сравнения с IOWOW...
> Странно, что нет результатов сравнения с IOWOW...На сайте IOWOW есть сравнение c LMDB, в свою очередь MDBX немного быстрее LMDB.
На всякий следует уточнить, что "внутри" MDBX до 20% быстрее LMDB, но это не видно в большинстве CRUD-тестов, так как узким место становится запись на диск.
Но в некоторых "особо синтетических" тестах MDBX может быть чуть медленнее LMDB из-за различных дополнительных проверок (LMDB падает в корку или повреждает данные в массе случаев при неверном использовании API).Тем не менее, это всё достаточно условные сравнения "теплого" с "мягким". В MDBX и LMDB есть транзакции с ACID, доказанная не-ломаемость при системых авариях и отсутствие фазы восстановления, плюс неблокируемое чтение с линейным масштабирование по CPU. А в IOWOW, насколько я знаю ничего из этого нет. Это не значит что IOWOW какая-то плохая/ущербная, но показывает что это сильно разные БД для разных целей.
> Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость?Как минимум, потому что релиз 1.0. На этой стадии, кстати, вполне позволительно иметь <300 звёзд.
Ну и БД действительно гораздо важнее всяких нескучных ZorinOS и ламeрских наeздов на линуксовый планировщик задач.
При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.
> При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.Не история завершена, а остановлено развитие, ибо некуда.
В libmdbx уже сделано примерно всё что можно в рамках текущего формата БД и API. Какие-то мелкие доработки и улучшения конечно возможны, но принципиальное развитие возможно только с изменением формата и сломом совместимости.
потому что автору очень хочется, чтобы его велосипед заметили. и потому что порядочные люди после небольшого data mining с автором работать не хотят, и его велосипеды тоже не хотят.
> потому что автору очень хочется, чтобы его велосипед заметили. и потому что
> порядочные люди после небольшого data mining с автором работать не хотят,
> и его велосипеды тоже не хотят.Я уже сделал clone, потом профайл разработчика посмотрел и планы по "развитию" базы. И пришлось F8 нажать. "Ребята, нас надули, это не яйцеклетка, это кариес!!!"
"Велосипед" давно "широко известен в узких кругах", примерно с доклада на highload++ в 2015.
На всякий стоит отметить, что "велосипед" был сделан для Мегафона, когда ребята из Symas не смогли устранить ряд проблем.Ну а data mining как раз и покажет, что "порядочные люди" с "автором" вовсю работают )
Тем не менее, для полноты картины следует упомянуть и о проблемах.
Собственно, из публичных в production была история с мессенджером Mirinda NG - там проявился унаследованный из LMDB баг перебалансировки дерева.
Кроме этого, было несколько багов в коде самого мессенджера (в коде БД-драйвера использующего MDBX).
В результате это затронуло несколько десятков пользователей (если я правильно оцениваю).
Но в целом, Mirinda NG - отдельная история, они используют свою версию libmdbx, со своими правками.
При этом мне сложно сказать, корректны ли эти изменения и насколько корректно сейчас там используется API библиотеки.
> для Мегафонастало ещё хуже.
В миранде это под вайном не работает, приходится ждать когда допилят sqlite3 драйвер базы
> В миранде это под вайном не работает, приходится ждать когда допилят sqlite3
> драйвер базыЭто из-за ограничений/недоделок вайна, видимо в нем не реализованы такие функции как NtExtendSection() и т.д.
Ситуация слегка анекдотическая: MDBX была сделана для linux (не поддерживала windows), потом поддержка windows была добавлена с решением массы проблем (винда многого не умеет), теперь жалобы о том, что виндовая версия (внезапно) не работает под эмулятором винды на linux.
Тем не менее, я еще год назад писал - если будут указаны конкретные проблемы/причины не работоспособности "под вайном", то я постараюсь их решить.
Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции NtExtendSection().
Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.Заведен соответствующий баг https://bugs.winehq.org/show_bug.cgi?id=48620
В libmdbx добавлен костыль
https://github.com/erthink/libmdbx/commit/f750086bc190d581cf...Вероятно в какое-то разумное время эти изменения попадут в Миранду.
> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
> NtExtendSection().
> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял
в миранде главная проблема была в том, что миранда завершалась совершенно молча и нормальным образом, ни логов, ни проблем, просто нихотит
>> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
>> NtExtendSection().
>> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.
> а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понялФункционал NtExtendSection() требуется для увеличения размера файла с данными "на ходу", не только без закрытия/открытия, но и автоматически при активной транзакции.
> в миранде главная проблема была в том, что миранда завершалась совершенно молча
> и нормальным образом, ни логов, ни проблем, просто нихотитПроблема Wine в том, что функция NtExtendSection() экспортируется из ntdll.dll, но при её вызове процесс тупо и безусловно терминируется, а причину можно увидеть только в логах wine (если не отключены).
https://bugs.winehq.org/show_bug.cgi?id=48620Исправить это внутри Wine достаточно проблематично - нужно не только реализовать NtExtendSection(), но и существенно допеределать все управление вируальной памятью. Поэтому пришлось ставить костыли внутри libmdbx/
Ну и коммитов получилось в итоге несколько...
см. https://github.com/erthink/libmdbx/issues/83
И всем бы хороша была либа, казалось бы. Но увы, нет в жизни счастья: разработчик стремный, политоту в профайл гитхаба тащит. Какие гарантии что он в код бэкдоров не впихнет? Читать вообще все его коммиты от и до, с особым пристрастием? И лицензия какая-то своеобразная. А так все хорошо, прекрасная маркиза.
> политоту в профайл гитхаба тащит.Adolf Hitler, Stepan Bandera, (внезапно) George Soros. Это как же надо упороться, чтобы Сороса через запятую в одном ряду с Гитлером перечислять.
Не знаю, но проверять что может откаблучить такой разработчик, да еще из стремной фирмы применительно ко мне - впадлу. С такого разработчика надо все комиты под микроскопом штудировать. Лениво, сорь.
У него есть позиция и срать он хотел на твое мнение, затрода анонимная.
Нет у него позиции как ему сказали так и будет.
> У него есть позицияПри том я догадываюсь кто в какой позе в этой позиции. Очень хорошо что я профайл разработчика и планы по развитию позырил: предупрежден - значит вооружен.
>> У него есть позиция
> При том я догадываюсь кто в какой позе в этой позиции. Очень
> хорошо что я профайл разработчика и планы по развитию позырил: предупрежден
> - значит вооружен.А мне-то покажете где вы увидели "планы по развитию", а то я не в курсе (но может-быть забыл где-то что-то удалить/почистить)?
VataDB какая-то
Это не вата, это кодекс поведения государева человека.
> Это не вата, это кодекс поведения государева человека.Жириновский как раз задвинул недавно и о кодексах и о том как эти государевы человеки на самом деле называются.
>2020
>обращать внимание на Жириновского
HoholDB, точнее, если уж Stepan Bandera
Ю больше внимания уделяется качеству кода
Фи, как несовременно!
Сейчас надо писать быстро, потому что пока вы будете писать свой качественный код, макаки выкинут на рынок своё быстровысер, а потом вы припрётесь на рынок со своим качественным продуктом, потребитель откажется от макакоподелия и вы будете виноваты провале перспективного инновационного макакостартапа.
Лучше в коде макак найти что-то годное, чем юзать продукт человека, который пишет про себя: "антагонист Java". А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба. Цитата: "Весьма вероятно, что этот вариант чуть быстрее и/или несущественно медленнее подавляющего большинства сортировок, но выяснить это — буквально титанический труд, который я не могу себе позволить." Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте. Гений копирайта не меньше.А продолжая смотреть где он работает и что делает как тут уже выше написали желание пользовать его поделку улетучивается само по себе. Вангую что сабжевый автор еще дальше отъехавший чем Шигорин.
Простой совет если у вас на компьютере установлен Альт Линукс сабж вам подходит на все 146% если нет ни в коем случае не приближайтесь к нему и не скачивайте и не упоминайте в суе.
> про себя: "антагонист Java"Да, ибо не люблю лишних абстракций ради абстракций и последующей героической борьбы с ними.
> А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба.
Не статья, я скорее заметка. Не написал сортировку, а скомбинировал варианты и показал удачный результат. Ну и т.д.
> Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте.
В нужном мне контексте, показанная там комбинация существующих алгоритмов действительно лучше.
Но заведомо известно, что среди всех N! возможных комбинаций данных будут такие, где будет медленнее.+ Но я таки еще раз вам доставлю, написав еще одну "статью" в продолжение.
Ибо текущий вариант внутренней сортировки в libmdbx на 10-30% быстрее std::sort, причем как на Эльбрусе, так и на x86.> Вангую что сабжевый автор еще дальше отъехавший чем Шигорин.
Это комплимент, я читаю.
Чтобы не быть голословным и доставить удовольствие местным анонимным икспёртам.
Текущая сортировка внутри libmdbx показывает такие циферки:---
Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linuxrandom, 11 items std::sort: 413.168 ticks, ok
mdbx: 96.050 ticks 430.16% speed, ok
mixed, 11 items std::sort: 400.129 ticks, ok
mdbx: 96.050 ticks 416.58% speed, okrandom, 111 items std::sort: 6750.706 ticks, ok
mdbx: 4671.339 ticks 144.51% speed, ok
mixed, 111 items std::sort: 4541.049 ticks, ok
mdbx: 2836.840 ticks 160.07% speed, okrandom, 1111 items std::sort: 93208.344 ticks, ok
mdbx: 77806.556 ticks 119.79% speed, ok
mixed, 1111 items std::sort: 52042.322 ticks, ok
mdbx: 40537.589 ticks 128.38% speed, okrandom, 11111 items std::sort: 1200639.556 ticks, ok
mdbx: 1085497.222 ticks 110.61% speed, ok
mixed, 11111 items std::sort: 819688.111 ticks, ok
mdbx: 618397.111 ticks 132.55% speed, ok---
Intel x86-64, компилятор gcc 9.2.1random, 11 items std::sort: 439.045 ticks, ok
mdbx: 60.506 ticks 725.62% speed, ok
mixed, 11 items std::sort: 113.641 ticks, ok
mdbx: 47.006 ticks 241.76% speed, okrandom, 111 items std::sort: 7217.518 ticks, ok
mdbx: 5166.508 ticks 139.70% speed, ok
mixed, 111 items std::sort: 2533.239 ticks, ok
mdbx: 1952.844 ticks 129.72% speed, okrandom, 1111 items std::sort: 101895.956 ticks, ok
mdbx: 88060.700 ticks 115.71% speed, ok
mixed, 1111 items std::sort: 42254.344 ticks, ok
mdbx: 32174.811 ticks 131.33% speed, okrandom, 11111 items std::sort: 1431319.556 ticks, ok
mdbx: 1240181.444 ticks 115.41% speed, ok
mixed, 11111 items std::sort: 688404.444 ticks, ok
mdbx: 486213.778 ticks 141.58% speed, ok---
Intel x86-64, компилятор clang 9.0random, 11 items std::sort: 270.146 ticks, ok
mdbx: 42.616 ticks 633.91% speed, ok
mixed, 11 items std::sort: 97.677 ticks, ok
mdbx: 42.713 ticks 228.68% speed, okrandom, 111 items std::sort: 8251.918 ticks, ok
mdbx: 5323.947 ticks 155.00% speed, ok
mixed, 111 items std::sort: 2792.332 ticks, ok
mdbx: 2016.517 ticks 138.47% speed, okrandom, 1111 items std::sort: 120649.822 ticks, ok
mdbx: 92747.533 ticks 130.08% speed, ok
mixed, 1111 items std::sort: 41854.211 ticks, ok
mdbx: 33450.478 ticks 125.12% speed, okrandom, 11111 items std::sort: 1520248.667 ticks, ok
mdbx: 1198299.667 ticks 126.87% speed, ok
mixed, 11111 items std::sort: 711888.222 ticks, ok
mdbx: 504380.000 ticks 141.14% speed, ok---
Intel x86-64, компилятор gcc 7.4 (тут хуже, потому что до 9.x у gcc плохо с CMOV).random, 11 items std::sort: 242.481 ticks, ok
mdbx: 202.167 ticks 119.94% speed, ok
mixed, 11 items std::sort: 100.371 ticks, ok
mdbx: 58.314 ticks 172.12% speed, okrandom, 111 items std::sort: 7136.350 ticks, ok
mdbx: 7360.917 ticks 96.95% speed, ok
mixed, 111 items std::sort: 2634.730 ticks, ok
mdbx: 2448.223 ticks 107.62% speed, okrandom, 1111 items std::sort: 105528.567 ticks, ok
mdbx: 107678.700 ticks 98.00% speed, ok
mixed, 1111 items std::sort: 39723.067 ticks, ok
mdbx: 36326.300 ticks 109.35% speed, okrandom, 11111 items std::sort: 1389003.667 ticks, ok
mdbx: 1409333.000 ticks 98.56% speed, ok
mixed, 11111 items std::sort: 651409.667 ticks, ok
mdbx: 558271.000 ticks 116.68% speed, okНа всякий: машины разные, тики посчитаны посредством MFENCE+RDTSC (выбираются лучшие для 100 повторов и усредняются за несколько прогонов с разными данными), сравнивать их между собой не совсем корректно.
С "random"-паттерном думаю все очевидно, а "mixed" - это симуляция наиболее частого случая при работе MDBX (половина данных отсортирована, четверть в обратном порядке, еще четверть в случайном порядке).
> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linuxА конфига которую вот просто хрен проверишь и сравнишь - специальна взята, чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее в гости.
>> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux
> А конфига которую вот просто хрен проверишь и сравнишь - специальна взята,
> чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее
> в гости.Если у вас нет Эльбруса, то вы _никак_ это не проверите, вне зависимости от прочего.
Но как вы наверно заметили, показаны циферки и для x86-64. Попробуйте взять [исходники](https://github.com/leo-yuriev/libmdbx/blob/devel/src/element...) и показать тест, в котором эта сортировка целых чисел (мне нужно именно это) не будет обгонять `std::sort()` (с `qsort()` сравнивать некорректно, ибо там много накладных расходов на вызов компаратора).
> чем юзать продукт человека, который пишет про себя: "антагонист Java"Не пользуйтесь.
А я взял бы такого человека на заметку, потому что жаба жЫрная, тормозная и дырявая (в любой ипостаси - скала, груви, котлин, какой угодно), и человек, который не хочет иметь с ней дела, как минимум заботится о том, как его продукт будер работать, а не только о том, чтобы побыстрее что-то накарябать и выпихнуть в продакшон.
> линейным масштабированием по ядрам CPU.Ага-ага, на графике его прямо видно.
> Ага-ага, на графике его прямо видно.На графике показаны результаты теста на ноутбуке 2013-го года, с i7-4600U у которого "на самом деле" два ядра (4 в режиме HyperThreading). Информация о модели CPU есть в [README](https://github.com/leo-yuriev/libmdbx#performance-comparison). Кроме этого, там достаточно быстро узким местом становится memory bandwidth.
Но в целом, это действительно ляп, который требует (как минимум уточнения). Поэтому спасибо за наводку!