https://www.opennet.ru/openforum/vsluhforumID3/119418.html После пяти лет разработки доступен для тестирования второй кандидат в релизы библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базой данных класса ключ-значение. Текущая версия (0.5) является техническим релизом, отмечает завершение каких-либо доработок и переход к фазе публичного финального тестирования и стабилизации, с последующем формированием первого полноценного релиза библиотеки. Код libmdbx распространяется под лицензией OpenLDAP Public License...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52147<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#55 Mon, 09 Sep 2024 14:45:05 GMT Ява работает вполне адекватно. По производительности она уделывает питон раз в 100 и проигрывает чистым сям в 2-10 раз, что не так уж и много.<br>А использование фреймворка для фреймворка ещё не говорит, что тормозит язык, а не используемый подход.<br>Да и ниша явы такая, что докупить пачку серверов всегда дешевле.<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#54 Thu, 02 Apr 2020 22:59:04 GMT Ну и коммитов получилось в итоге несколько... <br>см. https://github.com/erthink/libmdbx/issues/83<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#53 Thu, 02 Apr 2020 22:49:53 GMT &gt;&gt; Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции <br>&gt;&gt; NtExtendSection().<br>&gt;&gt; Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.<br>&gt; а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял <br><br>Функционал NtExtendSection() требуется для увеличения размера файла с данными "на ходу", не только без закрытия/открытия, но и автоматически при активной транзакции.<br><br>&gt; в миранде главная проблема была в том, что миранда завершалась совершенно молча <br>&gt; и нормальным образом, ни логов, ни проблем, просто нихотит <br><br>Проблема Wine в том, что функция NtExtendSection() экспортируется из ntdll.dll, но при её вызове процесс тупо и безусловно терминируется, а причину можно увидеть только в логах wine (если не отключены).<br>https://bugs.winehq.org/show_bug.cgi?id=48620<br><br>Исправить это внутри Wine достаточно проблематично - нужно не только реализовать NtExtendSection(), но и существенно допеределать все управление вируальной памятью. Поэтому пришло https://www.opennet.ru/openforum/vsluhforumID3/119418.html#52 Thu, 02 Apr 2020 21:38:18 GMT &gt; Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции <br>&gt; NtExtendSection().<br>&gt; Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено. <br><br>а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял<br><br>в миранде главная проблема была в том, что миранда завершалась совершенно молча и нормальным образом, ни логов, ни проблем, просто нихотит<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#51 Wed, 19 Feb 2020 12:35:21 GMT Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции NtExtendSection().<br>Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено.<br><br>Заведен соответствующий баг https://bugs.winehq.org/show_bug.cgi?id=48620<br><br>В libmdbx добавлен костыль<br>https://github.com/erthink/libmdbx/commit/f750086bc190d581cf3d25aa1300714dd4e2a136<br><br>Вероятно в какое-то разумное время эти изменения попадут в Миранду.<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#50 Wed, 15 Jan 2020 12:04:35 GMT &gt; До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.<br><br>Исторически прародитель обсуждаемой "СУБД" создавался для замены BerkeleyDB, в частности из-за неустраняемых проблем в BerkeleyDB с взаимными блокировками и багами в кешировании (могут читаться старые данные и т.д.). Результат получился не только стабильнее, но и существенно быстрее BerkeleyDB. Поэтому многие проекты давно приняли решение об уходе с BerkeleyDB, для примера см абзац в википедии https://en.wikipedia.org/wiki/Embedded_database#Oracle_Berkeley_DB. Поэтому вопрос "дорасти до BerkeleyDB" давно не стоит.<br><br>По поводу отношения к "СУБД" - ваше мнение сильно не совпадает с терминологией принятой в индустрии, см определение что такое "Встраиваемая база данных" в википедии https://ru.wikipedia.org/wiki/%D0%92%D1%81%D1%82%D1%80%D0%B0%D0%B8%D0%B2% https://www.opennet.ru/openforum/vsluhforumID3/119418.html#49 Wed, 15 Jan 2020 09:38:17 GMT До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#48 Thu, 09 Jan 2020 15:41:54 GMT &gt; Ага-ага, на графике его прямо видно.<br><br>На графике показаны результаты теста на ноутбуке 2013-го года, с i7-4600U у которого "на самом деле" два ядра (4 в режиме HyperThreading). Информация о модели CPU есть в [README](https://github.com/leo-yuriev/libmdbx#performance-comparison). Кроме этого, там достаточно быстро узким местом становится memory bandwidth.<br><br>Но в целом, это действительно ляп, который требует (как минимум уточнения). Поэтому спасибо за наводку!<br> https://www.opennet.ru/openforum/vsluhforumID3/119418.html#47 Thu, 09 Jan 2020 15:32:30 GMT &gt; линейным масштабированием по ядрам CPU. <br><br>Ага-ага, на графике его прямо видно.<br>