| |
| 2.2, erthink (ok), 21:38, 30/09/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
 В Wine не реализованы некоторые принципиальные вещи, без которых libmdbx не может динамически менять размер БД. Это нельзя починить в libmdbx, максимум - чтобы не падало внутри Wine, и это сделано ещё весной.
Тем не менее, Миранда сможет работать с libmdbx под Wine если сделать соответствующие доработки в самой Миранде (например, задавать достаточный, но фиксированный размер БД).
| | |
| |
| |
| |
| |
| 6.35, _ (??), 21:28, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Может у dartraiden-а спросить нафига он завел эту багу, если всё работает?
| | |
| |
| 7.40, dartraiden (?), 14:11, 02/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не работает оно (убунта 20.04 + последний стабильный/тестовый вайн). На 32-битных дистрах не пробовал, да.
| | |
| |
| 8.49, _hide_ (ok), 12:55, 05/10/2020 [^] [^^] [^^^] [ответить] | +/– |  О да, дистр тут не важен - важно, чтобы Миранда и Вайн был под x32 настраиваетс... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.3, x3who (?), 21:44, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
Почитал mdbx.h, просто грустно во что превратился язык ц++
/// \brief Returns the number of bytes.
MDBX_NOTHROW_PURE_FUNCTION MDBX_CXX20_CONSTEXPR size_t size() const noexcept {
return length();
}
Сколько лишних букв! Программирование ради программирования кокое-то :-/
| | |
| |
| 2.5, Аноним (5), 21:56, 30/09/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
как будто до "превращения" ц++ в нем и в ц таких конструкций никто не делал
| | |
| |
| |
| 4.11, x3who (?), 00:07, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Согласен в общем случае.. но тут враппер тупой. пролог хидера ввобще жжет напалмом - там и проверки на микрософтовский mad конпелятор, и объявления для специфической системы документировпния кода. Собственно функцонал занимает меньше чем все эти приседания.
| | |
| 4.26, Аноним (26), 09:46, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
я вроде не говорил, что ненормальная. А как помогут комментарии с танцами вокруг разных версий разных компиляторов с разными хаками?
| | |
|
|
| 2.8, Аноним (8), 23:06, 30/09/2020 [^] [^^] [^^^] [ответить] | +/– | Ну в любом активно развивающимся языке с достаточной историей будут новые фичи к... большой текст свёрнут, показать | | |
| |
| 3.12, x3who (?), 00:10, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна.
Вообще у них так и сделано - только Ц++11
| | |
|
| 2.31, Аноним (31), 12:14, 01/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тут дело не в языке, а в количестве компиляторов и их версий и желании разработчиков поддерживать продукт для большого количества платформ.
Фактически тут все идентификаторы в верхнем регистре - это макроподставновки препроцессора, которые определены где-то выше и имеют значения в зависимости от выбранного компилятора для сборки
По факту это можно для типовых современных компиляторов заменить на :
constexpr size_t size() const noexcept {
return length ();
}
| | |
|
| 1.7, Аноним (7), 22:59, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Почему релизы теперь опять на GitHubе и куда же подевались ваши позиция и принципиальность? Вопрос - риторический, можете не отвечать ;)
| | |
| |
| |
| 3.13, x3who (?), 00:17, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> см. последнюю строчку readme
Я вот лично до последней строчки не добрался, плюнул читать дальше на этом месте: "The next version is under active non-public development from scratch and will be released as MithrilDB"
| | |
| |
| 4.20, erthink (ok), 01:58, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Исходный код LMDB - изначально ребус (гляньте https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c), а многие около-архитектурные решения там сделаны по принципу "ХХивП".
Поэтому кроме как "from scratch" пути нет, при этом также снимается вопрос с "не-своей" лицензией и появляется возможность избавиться от многих проблем/слабостей (что впрочем требует неслабого research-а).
А допиливание libmdbx - это потому что "мы в ответе за тех, кого приручили", в том числе для актуального production.
| | |
| |
| 5.33, Аноним (33), 15:51, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Исходный код LMDB - изначально ребус, а многие около-архитектурные решения там сделаны по принципу "ХХивП".
Надо эту цитату вставлять в каждую новость про LMDB. Сразу отпадёт много вопросов.
| | |
| 5.36, _ (??), 21:38, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ревьюверы кода LMDB иного мнения: "impressive codebase", "the implementation is really quite brilliant".
| | |
| |
| 6.39, mos87 (ok), 00:48, 02/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Формулировки похожи на то как бы описывал своё творение Говард
| | |
|
|
|
| 3.25, Аноним (7), 09:10, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>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 пихать? В таком случае, если тот же исходник засунуть на "оригинал", то сообщение будет не очень верно.
| | |
| 3.32, andy (??), 15:51, 01/10/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Поглядел. Крым не российский, да. Какие проблемы-то?
| | |
|
|
| 1.9, erthink (ok), 23:51, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ] | +2 +/– | Как-то кто-то просил сравнить производительность libmdbx, LMDB и sqlite Для это... большой текст свёрнут, показать | | |
| |
| 2.14, x3who (?), 00:25, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Были случаи использования этого в микроконтроллерах? Ну там дейталоггеры какие-нибудь? В таких применениях производительность критична даже не потому, что это время, а потому, что это микроватты-милли-ватты, от которых зависит самый дорогой на Земле ресурс - батарейка, или самый дорргой в космосе - охлаждение.
| | |
| |
| 3.15, erthink (ok), 00:40, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Половина (связанных с производительностью) бонусов libmdbx происходит от отображения файла БД в память и последующего совместного использования несколькими процессами. Такие сценарии достаточно далеки от среднего микроконтроллера, у большинства из которых нет MMU.
Тем не менее, если взять некий "микроконтроллер" где работает buildroot, то (скорее всего) libmdbx будет там работать. Но мне о таких запусках ничего не известно, и в целом "СУБД" и "микроконтроллер" не выглядят рациональной парой.
| | |
| |
| 4.16, x3who (?), 00:50, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это для чтения, писатель, как я понимаю, там предполагается один. Или в варианте с ограниченной RAM выигрыш в производятельно
сти пропадает?
| | |
| |
| 5.17, erthink (ok), 01:01, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Это для чтения, писатель, как я понимаю, там предполагается один. Или в
> варианте с ограниченной RAM выигрыш в производятельно
> сти пропадает?
Если ОЗУ мало, то БД просто некуда mmap-ить.
Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
И это при условии что есть MMU для управления виртуальной памятью.
Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит от ОС, включая наличие/отсутствие unified page cache).
Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только некий минимум для загрузки и обновления прошивки на флешке.
| | |
| |
| 6.42, x3who (?), 01:13, 03/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Это для чтения, писатель, как я понимаю, там предполагается один. Или в
>> варианте с ограниченной RAM выигрыш в производятельно
>> сти пропадает?
> Если ОЗУ мало, то БД просто некуда mmap-ить.
> Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
> И это при условии что есть MMU для управления виртуальной памятью.
> Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит
> от ОС, включая наличие/отсутствие unified page cache).
> Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только
> некий минимум для загрузки и обновления прошивки на флешке.
Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски не знает, как и персональный компъютер или мобилка или сервер какой. Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту БД к логгингу, и если можно - то какие требования к железу.
| | |
| |
| 7.44, erthink (ok), 15:19, 03/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски
> не знает, как и персональный компъютер или мобилка или сервер какой.
> Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную
> информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту
> БД к логгингу, и если можно - то какие требования к
> железу.
Чтобы использовать libmdbx как есть, без каких-либо доработок, то от системы требуется поддержка mmap() и PTHREAD_MUTEX_ROBUST. Проще говоря, если на микроконтроллере есть MMU и можно запустить linux (buildroot и т.п.).
При необходимости, конечно, можно портировать libmdbx на более слабые платформы, в том числе на "голое железо". Требуется не так уж много (32-битный процессор, мегабайт ОЗУ и блочный обмен с "диском"). Грубо говоря, достаточно реализовать соответствующие функции libc.
| | |
| |
| 8.46, x3who (?), 01:49, 04/10/2020 [^] [^^] [^^^] [ответить] | +/– | Не, мегабайт жирновато для _микро_-контроллера Но вообще код интересный, наш... текст свёрнут, показать | | |
|
|
|
|
| 4.48, n80 (?), 03:19, 04/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
offtop/2: если что, в sqlite3 есть PRAGMA mmap_size=x. Насколько помню, по умолчанию там 0, т.е. mmap не используется. Как-то раз удавалось за счёт включения этой настройки немного ускорить существующую базу. В репозитории ioarena не нашёл упоминания mmap_size, т.е. возможно что этот момент был упущен.
| | |
| |
| 5.50, erthink (ok), 15:09, 06/10/2020 [^] [^^] [^^^] [ответить] | +/– | mmap в sqlite будет немного ускорять чтение, за счет потенциального расширения ... большой текст свёрнут, показать | | |
| |
| 6.51, n80 (?), 15:16, 06/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
О как. У меня было по большей части чтение, поэтому и получилось некоторое ускорение.
Понятно, что специализированное хранилище в разы быстрее, но было интересно понять, насколько удалось выжать всё из sqlite3 (и не только понять, какие опции используются, но и почему). Опять же, момент с замедлением записи при включении mmap оказался неожиданностью.
Премного благодарю за информацию!
| | |
| |
| 7.52, erthink (ok), 17:59, 06/10/2020 [^] [^^] [^^^] [ответить] | +/– | На всякий, для информации 1 Заметил что при 25M итераций размер БД в sqlite по... большой текст свёрнут, показать | | |
|
|
|
|
|
| 2.18, Аноним (18), 01:18, 01/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Там разница идёт на порядки в зависимости от объёма данных, собственно, потому они и существуют. Некорректно так сравнивать -- они не универсальны.
| | |
| |
| 3.19, erthink (ok), 01:43, 01/10/2020 [^] [^^] [^^^] [ответить]
| +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), но готовых инструментов для этого сейчас нет, а зная внутреннее устройство, я могу поспорить что соотношений производительности сохранится.
| | |
| |
| 4.22, Аноним (18), 02:46, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
В контексте данного бенчмарка в наличии key size и value size, и, если я правильно предполагаю их назначение, они будут влиять на результат и WAL тут ни при чём. Это не универсальные дб, все они разрабатываются с оптимизацией под определённые кейсы.
| | |
| |
| 5.23, erthink (ok), 03:17, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
1) Пока размеры будут "в пределах разумного", существенно разницы не будет.
2) При длинных значениях sqlite будет проигрывать сильнее из-за больших накладных расходах. А libmdbx будет "огурцом" и при гигабайтных размерах, лишь-бы памяти хватило.
3) С длинными ключами несколько сложнее.
- В libmdbx есть ограничения на максимальную длину ключа, которое зависит от размера страницы. Проще говоря, libmdbx не предусматривает поддержку длинных ключей, из-за которых сильно деградирует производительность.
- sqlite напротив реализует максимально гибкую схему и будет "тянуть лямку" сколько сможет, существенно замедляясь на длинных ключах.
Таким образом, libmdbx будет быстрее (думаю, в обозначенных пропорциях или лучше) пока размеры ключей и данных будут в поддерживаемых пределах.
А если эти пределы будут превышены, то сравнивать sqlite по скорости уже будет как-бы не с чем.
| | |
|
|
|
| 2.41, phprus (ok), 20:47, 02/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Скажите, пожалуйста, а насколько хорошо libmdbx подойдет для хранения счетчиков, если данные - это ключ 16 байт и счетчик, которому надо делать инкремент/декремент и удаление? Время жизни отдельного ключа небольшое (от секунд до часов и порядка десятков операций ++/--, но редко бывают и десятки тысяч операций). Одновременно существующих ключей/счетчиков - тысячи, редко десятки тысяч. Вероятность конкурентных операций на один ключ мала. Пожелание - не пухнуть базой, те иметь предсказуемое ограничение на размер файлов на диске сверху.
Или может быть вы можете порекомендовать что-то другое готовое для хранения короткоживущих счетчиков?
| | |
| |
| 3.43, erthink (ok), 14:54, 03/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для короткоживущих данных, как правило, лучше подходят БД на основе LSM (https://ru.wikipedia.org/wiki/LSM-п╢п╣я─п╣п╡п╬).
Бонус там в том, что при слиянии внутри LSM удаление данных почти бесплатно.
Вам стоит попробовать/посмотреть на tarantool и rocksdb.
Однако, однозначного универсального ответа нет. В конкретных случаях отдельные нюансы могут сделать использование LSM не рациональным или невозможным. В частности, реальная эффективность LSM непосредственно зависит от того насколько хорошо в конкретной ОС и конкретной файловой системе работает APPEND режим для файлов. Т.е. в вашем случае, при использовании LSM, скорее всего всё будет хорошо в Linux, а в Windows может быть значительно хуже.
Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный доступ и какова пропорция по объему операций чтения и записи.
Если много операций чтения или нужен доступ к БД из нескольких процессов, то libmdbx однозначно выиграет - не будет НИКАКИХ накладных расходов.
Если в основном будут операции изменения данных и нужны транзакции, то (думаю) лучше взять tarantool.
Если не важна стабильность по времени выполнения отдельных операций и не важны транзакции, то rockdb.
И т.д., таких "если" наберется еще пара десятков.
| | |
| |
| 4.45, phprus (ok), 17:06, 03/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо за ответ!
Буду тестировать.
> Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный
> доступ и какова пропорция по объему операций чтения и записи.
Чтение/запись почти одинаково с маленьким перевесом чтения. Так как это счетчики, то транзакции нужны (отдельные операции в основном имеют вид: прочитали, изменили значение, записали значение или удалили ключ).
Многопоточный доступ и на чтение, и на изменение нужен.
| | |
|
|
|
| 1.24, Андрей (??), 04:34, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> Для оперативной поддержки и ответов на вопросы создана открытая группа в Телеграм.
Оперативно? Вроде же, люди не любят регистрироваться. А там даже зарегистрироваться-то нельзя. Номер телефон требует и нет опции "пропустить". Не попасть в этот телеграм. Вообще.
| | |
| |
| 2.29, erthink (ok), 11:20, 01/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
/trolling mode on
Для перехода на Миранду осталось переписать её на Rust и сделать переносимой (отвязать от Windows).
/trolling mode off
| | |
| |
| 3.30, llolik (ok), 11:51, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > и сделать переносимой (отвязать от Windows).
Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к. GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).
| | |
| |
| 4.37, мяя (?), 22:28, 01/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> и сделать переносимой (отвязать от Windows).
> Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать
> совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или
> писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к.
> GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).
Ядро уже собирается на Linux насколько я знаю. А винапи там по большей части только в GUI у плагинов. Со временем отвяжут его и всё будет работать везде.
| | |
| 4.47, n80 (?), 03:04, 04/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
FYI: как-то я встречал /похожий/ OSAL, называется WinPR и используется в FreeRDP (замена rdesktop). Ну и libwine, куда ж без него. Вроде, что-то ещё вспоминается, но уже более смутно.
| | |
|
|
|
|
