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

Выпуск компактной встраиваемой СУБД libmdbx 0.9.1, opennews (ok), 30-Сен-20, (0) [смотреть все] баги в 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 1,3,7,9,24

Сообщения

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

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

	19. "Выпуск компактной встраиваемой СУБД libmdbx 0.9.1"	+1 +/–
	Сообщение от erthink (ok), 01-Окт-20, 01:43
	> Там разница идёт на порядки в зависимости от объёма данных, собственно, потому > они и существуют. Некорректно так сравнивать -- они не универсальны. Не совсем понятно что именно вы хотели сказать в контексте бенчмарков 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ообщить модератору

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

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

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

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