|
| |
| 2.4, Аноним (3), 19:15, 07/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Алсо если кто-то уже использует, как оно для совсем маленьких датасетов?
| | |
| |
| 3.22, erthink (ok), 11:13, 08/01/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
 Также хорошо как и для больших.
На самом деле, то насколько (не)подходит MDBX определяется другим.
MDBX совсем не подойдет, если:
- много изменений, которые нельзя потерять = нужна БД с WAL.
- много коротко живущих изменений (значения часто обновляются) и/или много коротко живущих данных (данные удаляются вскоре после добавления) = нужна БД на основе LSM.
- требуются долгие читающие транзакции на фоне постоянных изменений.
- требуется несколько пишущих транзакций одновременно.
MDBX очень хорошо подойдет, если:
- много чтения и мало изменений (характерный пример LDAP).
- много изменений, но данные можно потерять при системной аварии.
| | |
|
|
| |
| 2.26, erthink (ok), 12:38, 08/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Это как Berkeley DB?
И да и нет.
MDBX является сильно переработанным форком LMDB, в свою очередь LMDB была сделана для замены Berkeley DB в OpenLDAP.
Поэтому API libmdbx похоже и на dbm и на Berkeley DB, но существенно проще.
| | |
| 2.49, adolfus (ok), 12:38, 15/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.
| | |
| |
| 3.50, erthink (ok), 15:04, 15/01/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Исторически прародитель обсуждаемой СУБД создавался для замены BerkeleyDB, в ч... большой текст свёрнут, показать | | |
|
|
| 1.8, ананим.orig (?), 21:25, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> Библиотека MDBX является существенно переработанным ответвлением от LMDB
прозрачная замена предполагается?
например для самбы.
| | |
| |
| 2.23, erthink (ok), 11:27, 08/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
> прозрачная замена предполагается?
> например для самбы.
Совсем прозрачная - нет, поскольку у LMDB есть совершенно кошмарная специфика.
Например:
- в LMDB курсоры нужно по-разному закрывать/переиспользовать в пишущих и читающих транзакциях.
- в LMDB DBI-хендлы нужно открывать заранее.
- в LMDB разный формат БД для 32-битных и 64-битных платформ (не считая зависимости от endianess).
Но никаких проблем с заменой быть не должно, только плюсы.
В частности, в MDBX есть авто-компактификация и LIFO-политика для переработки мусора.
Поэтому в MDBX нет одной из мега-проблем LMDB - если БД распухает (например из-за долгих читающих транзакций), то это навечно и при этом еще деградирует производительность.
| | |
|
| 1.9, Аноним (9), 21:39, 07/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –9 +/– |
Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость? Ну вроде бы это неплохо, но таких немало. Чем эта выделяется? У неё < 300 звёзд на гитхабе и не очень ясно, где она используется. То есть выглядит так, что это слабоизвестная экспериментальная разработка в области, где есть дохрена оттестированных проверенных временем решений.
| | |
| |
| 2.10, Аноним (6), 21:43, 07/01/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
Потому что это форк LMDB. LMDB - это широко известная key-value база для хайлоада. Используется в Firefox и rpm в том числе.
| | |
| |
| |
| 4.24, erthink (ok), 11:53, 08/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Странно, что нет результатов сравнения с IOWOW...
На сайте IOWOW есть сравнение c LMDB, в свою очередь MDBX немного быстрее LMDB.
На всякий следует уточнить, что "внутри" MDBX до 20% быстрее LMDB, но это не видно в большинстве CRUD-тестов, так как узким место становится запись на диск.
Но в некоторых "особо синтетических" тестах MDBX может быть чуть медленнее LMDB из-за различных дополнительных проверок (LMDB падает в корку или повреждает данные в массе случаев при неверном использовании API).
Тем не менее, это всё достаточно условные сравнения "теплого" с "мягким". В MDBX и LMDB есть транзакции с ACID, доказанная не-ломаемость при системых авариях и отсутствие фазы восстановления, плюс неблокируемое чтение с линейным масштабирование по CPU. А в IOWOW, насколько я знаю ничего из этого нет. Это не значит что IOWOW какая-то плохая/ущербная, но показывает что это сильно разные БД для разных целей.
| | |
|
|
| 2.11, Аноним (11), 22:55, 07/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость?
Как минимум, потому что релиз 1.0. На этой стадии, кстати, вполне позволительно иметь <300 звёзд.
Ну и БД действительно гораздо важнее всяких нескучных ZorinOS и ламeрских наeздов на линуксовый планировщик задач.
| | |
| |
| 3.14, Аноним (14), 02:38, 08/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.
| | |
| |
| 4.37, erthink (ok), 20:50, 08/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.
Не история завершена, а остановлено развитие, ибо некуда.
В libmdbx уже сделано примерно всё что можно в рамках текущего формата БД и API. Какие-то мелкие доработки и улучшения конечно возможны, но принципиальное развитие возможно только с изменением формата и сломом совместимости.
| | |
|
|
| 2.15, arisu (ok), 06:14, 08/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
 потому что автору очень хочется, чтобы его велосипед заметили. и потому что порядочные люди после небольшого data mining с автором работать не хотят, и его велосипеды тоже не хотят.
| | |
| |
| 3.17, Аноним (-), 07:36, 08/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> потому что автору очень хочется, чтобы его велосипед заметили. и потому что
> порядочные люди после небольшого data mining с автором работать не хотят,
> и его велосипеды тоже не хотят.
Я уже сделал clone, потом профайл разработчика посмотрел и планы по "развитию" базы. И пришлось F8 нажать. "Ребята, нас надули, это не яйцеклетка, это кариес!!!"
| | |
| 3.25, erthink (ok), 12:24, 08/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
"Велосипед" давно "широко известен в узких кругах", примерно с доклада на highload++ в 2015.
На всякий стоит отметить, что "велосипед" был сделан для Мегафона, когда ребята из Symas не смогли устранить ряд проблем.
Ну а data mining как раз и покажет, что "порядочные люди" с "автором" вовсю работают )
Тем не менее, для полноты картины следует упомянуть и о проблемах.
Собственно, из публичных в production была история с мессенджером Mirinda NG - там проявился унаследованный из LMDB баг перебалансировки дерева.
Кроме этого, было несколько багов в коде самого мессенджера (в коде БД-драйвера использующего MDBX).
В результате это затронуло несколько десятков пользователей (если я правильно оцениваю).
Но в целом, Mirinda NG - отдельная история, они используют свою версию libmdbx, со своими правками.
При этом мне сложно сказать, корректны ли эти изменения и насколько корректно сейчас там используется API библиотеки.
| | |
| |
| 4.44, крокодил (?), 05:20, 09/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
В миранде это под вайном не работает, приходится ждать когда допилят sqlite3 драйвер базы
| | |
| |
| 5.46, erthink (ok), 13:55, 09/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> В миранде это под вайном не работает, приходится ждать когда допилят sqlite3
> драйвер базы
Это из-за ограничений/недоделок вайна, видимо в нем не реализованы такие функции как NtExtendSection() и т.д.
Ситуация слегка анекдотическая: MDBX была сделана для linux (не поддерживала windows), потом поддержка windows была добавлена с решением массы проблем (винда многого не умеет), теперь жалобы о том, что виндовая версия (внезапно) не работает под эмулятором винды на linux.
Тем не менее, я еще год назад писал - если будут указаны конкретные проблемы/причины не работоспособности "под вайном", то я постараюсь их решить.
| | |
| |
| 6.52, JL2001 (ok), 00:38, 03/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
> NtExtendSection().
> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.
а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял
в миранде главная проблема была в том, что миранда завершалась совершенно молча и нормальным образом, ни логов, ни проблем, просто нихотит
| | |
| |
| 7.53, erthink (ok), 01:49, 03/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции
>> NtExtendSection().
>> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.
> а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял
Функционал NtExtendSection() требуется для увеличения размера файла с данными "на ходу", не только без закрытия/открытия, но и автоматически при активной транзакции.
> в миранде главная проблема была в том, что миранда завершалась совершенно молча
> и нормальным образом, ни логов, ни проблем, просто нихотит
Проблема Wine в том, что функция NtExtendSection() экспортируется из ntdll.dll, но при её вызове процесс тупо и безусловно терминируется, а причину можно увидеть только в логах wine (если не отключены).
https://bugs.winehq.org/show_bug.cgi?id=48620
Исправить это внутри Wine достаточно проблематично - нужно не только реализовать NtExtendSection(), но и существенно допеределать все управление вируальной памятью. Поэтому пришлось ставить костыли внутри libmdbx/
| | |
|
|
|
|
|
|
| 1.16, Аноним (-), 07:34, 08/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
И всем бы хороша была либа, казалось бы. Но увы, нет в жизни счастья: разработчик стремный, политоту в профайл гитхаба тащит. Какие гарантии что он в код бэкдоров не впихнет? Читать вообще все его коммиты от и до, с особым пристрастием? И лицензия какая-то своеобразная. А так все хорошо, прекрасная маркиза.
| | |
| |
| 2.18, Сарабонг (?), 09:45, 08/01/2020 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> политоту в профайл гитхаба тащит.
Adolf Hitler, Stepan Bandera, (внезапно) George Soros. Это как же надо упороться, чтобы Сороса через запятую в одном ряду с Гитлером перечислять.
| | |
| |
| 3.20, Аноним (-), 10:52, 08/01/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Не знаю, но проверять что может откаблучить такой разработчик, да еще из стремной фирмы применительно ко мне - впадлу. С такого разработчика надо все комиты под микроскопом штудировать. Лениво, сорь.
| | |
| |
| |
| 5.39, Аноним (-), 00:23, 09/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> У него есть позиция
При том я догадываюсь кто в какой позе в этой позиции. Очень хорошо что я профайл разработчика и планы по развитию позырил: предупрежден - значит вооружен.
| | |
| |
| 6.42, erthink (ok), 00:30, 09/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> У него есть позиция
> При том я догадываюсь кто в какой позе в этой позиции. Очень
> хорошо что я профайл разработчика и планы по развитию позырил: предупрежден
> - значит вооружен.
А мне-то покажете где вы увидели "планы по развитию", а то я не в курсе (но может-быть забыл где-то что-то удалить/почистить)?
| | |
|
|
|
| |
| |
| 5.40, Аноним (-), 00:25, 09/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Это не вата, это кодекс поведения государева человека.
Жириновский как раз задвинул недавно и о кодексах и о том как эти государевы человеки на самом деле называются.
| | |
|
|
|
|
| 1.29, Аноним (29), 13:42, 08/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ю больше внимания уделяется качеству кода
Фи, как несовременно!
Сейчас надо писать быстро, потому что пока вы будете писать свой качественный код, макаки выкинут на рынок своё быстровысер, а потом вы припрётесь на рынок со своим качественным продуктом, потребитель откажется от макакоподелия и вы будете виноваты провале перспективного инновационного макакостартапа.
| | |
| |
| 2.32, Аноним (33), 16:46, 08/01/2020 [^] [^^] [^^^] [ответить] | –3 +/– | Лучше в коде макак найти что-то годное, чем юзать продукт человека, который пише... большой текст свёрнут, показать | | |
| |
| 3.34, erthink (ok), 17:08, 08/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> про себя: "антагонист Java"
Да, ибо не люблю лишних абстракций ради абстракций и последующей героической борьбы с ними.
> А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба.
Не статья, я скорее заметка. Не написал сортировку, а скомбинировал варианты и показал удачный результат. Ну и т.д.
> Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте.
В нужном мне контексте, показанная там комбинация существующих алгоритмов действительно лучше.
Но заведомо известно, что среди всех N! возможных комбинаций данных будут такие, где будет медленнее.
+ Но я таки еще раз вам доставлю, написав еще одну "статью" в продолжение.
Ибо текущий вариант внутренней сортировки в libmdbx на 10-30% быстрее std::sort, причем как на Эльбрусе, так и на x86.
> Вангую что сабжевый автор еще дальше отъехавший чем Шигорин.
Это комплимент, я читаю.
| | |
| |
| 4.36, erthink (ok), 19:11, 08/01/2020 [^] [^^] [^^^] [ответить] | +3 +/– | Чтобы не быть голословным и доставить удовольствие местным анонимным икспёртам ... большой текст свёрнут, показать | | |
| |
| 5.41, Аноним (-), 00:26, 09/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux
А конфига которую вот просто хрен проверишь и сравнишь - специальна взята, чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее в гости.
| | |
| |
| 6.43, erthink (ok), 00:40, 09/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux
> А конфига которую вот просто хрен проверишь и сравнишь - специальна взята,
> чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее
> в гости.
Если у вас нет Эльбруса, то вы _никак_ это не проверите, вне зависимости от прочего.
Но как вы наверно заметили, показаны циферки и для x86-64. Попробуйте взять [исходники](https://github.com/leo-yuriev/libmdbx/blob/devel/src/elements/core.c#L1472-L20) и показать тест, в котором эта сортировка целых чисел (мне нужно именно это) не будет обгонять 'std::sort()' (с 'qsort()' сравнивать некорректно, ибо там много накладных расходов на вызов компаратора).
| | |
|
|
|
| 3.38, Аноним (38), 23:37, 08/01/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> чем юзать продукт человека, который пишет про себя: "антагонист Java"
Не пользуйтесь.
А я взял бы такого человека на заметку, потому что жаба жЫрная, тормозная и дырявая (в любой ипостаси - скала, груви, котлин, какой угодно), и человек, который не хочет иметь с ней дела, как минимум заботится о том, как его продукт будер работать, а не только о том, чтобы побыстрее что-то накарябать и выпихнуть в продакшон.
| | |
|
|
| 1.47, Аноним (47), 18:32, 09/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> линейным масштабированием по ядрам CPU.
Ага-ага, на графике его прямо видно.
| | |
| |
| 2.48, erthink (ok), 18:41, 09/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ага-ага, на графике его прямо видно.
На графике показаны результаты теста на ноутбуке 2013-го года, с i7-4600U у которого "на самом деле" два ядра (4 в режиме HyperThreading). Информация о модели CPU есть в [README](https://github.com/leo-yuriev/libmdbx#performance-comparison). Кроме этого, там достаточно быстро узким местом становится memory bandwidth.
Но в целом, это действительно ляп, который требует (как минимум уточнения). Поэтому спасибо за наводку!
| | |
|
|
