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

"Опубликован второй кандидат в релизы встраиваемой СУБД libmd..."	+/–
Сообщение от opennews (?), 07-Янв-20, 18:54
После пяти лет разработки доступен для тестирования второй кандидат в релизы библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базой данных класса ключ-значение. Текущая версия (0.5) является техническим релизом, отмечает завершение каких-либо доработок и переход к фазе публичного финального тестирования и стабилизации, с последующем формированием первого полноценного релиза библиотеки. Код libmdbx  распространяется под лицензией  OpenLDAP Public License... Подробнее: https://www.opennet.me/opennews/art.shtml?num=52147
Ответить | Правка | Cообщить модератору

Сообщения

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

2. Сообщение от user90 (?), 07-Янв-20, 19:09    Скрыто ботом-модератором	–6 +/–
Матан кокой-то. И не холиварно! Скушшо, а такие новости и без вас (наверно) на fossies будут.
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Аноним (3), 07-Янв-20, 19:11	+1 +/–
Как раз недавно пригодилась нативная альтернатива mapdb. Попробую
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от Аноним (3), 07-Янв-20, 19:15	+2 +/–
Алсо если кто-то уже использует, как оно для совсем маленьких датасетов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #22

5. Сообщение от Аноним (5), 07-Янв-20, 19:17	+1 +/–
Это как Berkeley DB?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #26, #49

6. Сообщение от Аноним (6), 07-Янв-20, 20:00    Скрыто ботом-модератором	–1 +/–
Лео, ни ваши демонстративные поливания некоторых серьёзных людей негативом (путём называния их сначала criminal а потом felonами), в профиле на гитхабе, ни работа над DPI в серьёзных структурах всем известных не менее серьёзных людей, вам чести не делают. Раньше в у вас в гитхабе красовалась надпись о том, что вы валите с гитхаба в знак протеста против блокировки крыма, а гитлер с бандерой не были упомянуты, только сорос и ходор. Что-то ваш протест выдохся, а закон Годвина - выполнился. Неужели вам не стыдно всем этим заниматься?
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от ананим.orig (?), 07-Янв-20, 21:25	+2 +/–
> Библиотека MDBX является существенно переработанным ответвлением от LMDB прозрачная замена предполагается? например для самбы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

9. Сообщение от Аноним (9), 07-Янв-20, 21:39	–9 +/–
Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость? Ну вроде бы это неплохо, но таких немало. Чем эта выделяется? У неё < 300 звёзд на гитхабе и не очень ясно, где она используется. То есть выглядит так, что это слабоизвестная экспериментальная разработка в области, где есть дохрена оттестированных проверенных временем решений.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #11, #15

10. Сообщение от Аноним (6), 07-Янв-20, 21:43	+8 +/–
Потому что это форк LMDB. LMDB - это широко известная key-value база для хайлоада. Используется в Firefox и rpm в том числе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #19

11. Сообщение от Аноним (11), 07-Янв-20, 22:55	+2 +/–
> Непонятно, а почему о какой-то ноунейм опенсорсной библиотеке (окей, бд) отдельная новость? Как минимум, потому что релиз 1.0. На этой стадии, кстати, вполне позволительно иметь <300 звёзд. Ну и БД действительно гораздо важнее всяких нескучных ZorinOS и ламeрских наeздов на линуксовый планировщик задач.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #14

12. Сообщение от anonymous (??), 08-Янв-20, 01:31	+2 +/–
Нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

14. Сообщение от Аноним (14), 08-Янв-20, 02:38	+/–
При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #37

15. Сообщение от arisu (ok), 08-Янв-20, 06:14	+/–
потому что автору очень хочется, чтобы его велосипед заметили. и потому что порядочные люди после небольшого data mining с автором работать не хотят, и его велосипеды тоже не хотят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #17, #25

16. Сообщение от Аноним (-), 08-Янв-20, 07:34	–1 +/–
И всем бы хороша была либа, казалось бы. Но увы, нет в жизни счастья: разработчик стремный, политоту в профайл гитхаба тащит. Какие гарантии что он в код бэкдоров не впихнет? Читать вообще все его коммиты от и до, с особым пристрастием? И лицензия какая-то своеобразная. А так все хорошо, прекрасная маркиза.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

17. Сообщение от Аноним (-), 08-Янв-20, 07:36	–1 +/–
> потому что автору очень хочется, чтобы его велосипед заметили. и потому что > порядочные люди после небольшого data mining с автором работать не хотят, > и его велосипеды тоже не хотят. Я уже сделал clone, потом профайл разработчика посмотрел и планы по "развитию" базы. И пришлось F8 нажать. "Ребята, нас надули, это не яйцеклетка, это кариес!!!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

18. Сообщение от Сарабонг (?), 08-Янв-20, 09:45	–1 +/–
> политоту в профайл гитхаба тащит. Adolf Hitler, Stepan Bandera, (внезапно) George Soros. Это как же надо упороться, чтобы Сороса через запятую в одном ряду с Гитлером перечислять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #20, #21

19. Сообщение от Сарабонг (?), 08-Янв-20, 10:22	+/–
Странно, что нет результатов сравнения с IOWOW...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #24

20. Сообщение от Аноним (-), 08-Янв-20, 10:52	–2 +/–
Не знаю, но проверять что может откаблучить такой разработчик, да еще из стремной фирмы применительно ко мне - впадлу. С такого разработчика надо все комиты под микроскопом штудировать. Лениво, сорь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #28

21. Сообщение от Аноним (21), 08-Янв-20, 10:56	–2 +/–
VataDB какая-то
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #27, #30

22. Сообщение от erthink (ok), 08-Янв-20, 11:13	+7 +/–
Также хорошо как и для больших. На самом деле, то насколько (не)подходит MDBX определяется другим. MDBX совсем не подойдет, если: - много изменений, которые нельзя потерять = нужна БД с WAL. - много коротко живущих изменений (значения часто обновляются) и/или много коротко живущих данных (данные удаляются вскоре после добавления) = нужна БД на основе LSM. - требуются долгие читающие транзакции на фоне постоянных изменений. - требуется несколько пишущих транзакций одновременно. MDBX очень хорошо подойдет, если: - много чтения и мало изменений (характерный пример LDAP). - много изменений, но данные можно потерять при системной аварии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

23. Сообщение от erthink (ok), 08-Янв-20, 11:27	+5 +/–
> прозрачная замена предполагается? > например для самбы. Совсем прозрачная - нет, поскольку у LMDB есть совершенно кошмарная специфика. Например: - в LMDB курсоры нужно по-разному закрывать/переиспользовать в пишущих и читающих транзакциях. - в LMDB DBI-хендлы нужно открывать заранее. - в LMDB разный формат БД для 32-битных и 64-битных платформ (не считая зависимости от endianess). Но никаких проблем с заменой быть не должно, только плюсы. В частности, в MDBX есть авто-компактификация и LIFO-политика для переработки мусора. Поэтому в MDBX нет одной из мега-проблем LMDB - если БД распухает (например из-за долгих читающих транзакций), то это навечно и при этом еще деградирует производительность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #35

24. Сообщение от erthink (ok), 08-Янв-20, 11:53	+4 +/–
> Странно, что нет результатов сравнения с IOWOW... На сайте IOWOW есть сравнение c LMDB, в свою очередь MDBX немного быстрее LMDB. На всякий следует уточнить, что "внутри" MDBX до 20% быстрее LMDB, но это не видно в большинстве CRUD-тестов, так как узким место становится запись на диск. Но в некоторых "особо синтетических" тестах MDBX может быть чуть медленнее LMDB из-за различных дополнительных проверок (LMDB падает в корку или повреждает данные в массе случаев при неверном использовании API). Тем не менее, это всё достаточно условные сравнения "теплого" с "мягким". В MDBX и LMDB есть транзакции с ACID, доказанная не-ломаемость при системых авариях и отсутствие фазы восстановления, плюс неблокируемое чтение с линейным масштабирование по CPU. А в IOWOW, насколько я знаю ничего из этого нет. Это не значит что IOWOW какая-то плохая/ущербная, но показывает что это сильно разные БД для разных целей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

25. Сообщение от erthink (ok), 08-Янв-20, 12:24	+3 +/–
"Велосипед" давно "широко известен в узких кругах", примерно с доклада на highload++ в 2015. На всякий стоит отметить, что "велосипед" был сделан для Мегафона, когда ребята из Symas не смогли устранить ряд проблем. Ну а data mining как раз и покажет, что "порядочные люди" с "автором" вовсю работают ) Тем не менее, для полноты картины следует упомянуть и о проблемах. Собственно, из публичных в production была история с мессенджером Mirinda NG - там проявился унаследованный из LMDB баг перебалансировки дерева. Кроме этого, было несколько багов в коде самого мессенджера (в коде БД-драйвера использующего MDBX). В результате это затронуло несколько десятков пользователей (если я правильно оцениваю). Но в целом, Mirinda NG - отдельная история, они используют свою версию libmdbx, со своими правками. При этом мне сложно сказать, корректны ли эти изменения и насколько корректно сейчас там используется API библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #31, #44

26. Сообщение от erthink (ok), 08-Янв-20, 12:38	+5 +/–
> Это как Berkeley DB? И да и нет. MDBX является сильно переработанным форком LMDB, в свою очередь LMDB была сделана для замены Berkeley DB в OpenLDAP. Поэтому API libmdbx похоже и на dbm и на Berkeley DB, но существенно проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

27. Сообщение от Аноним (6), 08-Янв-20, 13:21	–2 +/–
Это не вата, это кодекс поведения государева человека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #40

28. Сообщение от Товарищ майор (?), 08-Янв-20, 13:23	+4 +/–
У него есть позиция и срать он хотел на твое мнение, затрода анонимная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #33, #39

29. Сообщение от Аноним (29), 08-Янв-20, 13:42	–1 +/–
Ю  больше внимания уделяется качеству кода Фи, как несовременно! Сейчас надо писать быстро, потому что пока вы будете писать свой качественный код, макаки выкинут на рынок своё быстровысер, а потом вы припрётесь на рынок со своим качественным продуктом, потребитель откажется от макакоподелия и вы будете виноваты провале перспективного инновационного макакостартапа.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

30. Сообщение от Аноним (30), 08-Янв-20, 13:43	–4 +/–
HoholDB, точнее, если уж Stepan Bandera
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

31. Сообщение от arisu (ok), 08-Янв-20, 13:45	–6 +/–
> для Мегафона стало ещё хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

32. Сообщение от Аноним (33), 08-Янв-20, 16:46	–2 +/–
Лучше в коде макак найти что-то годное, чем юзать продукт человека, который пишет про себя: "антагонист Java". А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба. Цитата: "Весьма вероятно, что этот вариант чуть быстрее и/или несущественно медленнее подавляющего большинства сортировок, но выяснить это — буквально титанический труд, который я не могу себе позволить." Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте. Гений копирайта не меньше. А продолжая смотреть где он работает и что делает как тут уже выше написали желание пользовать его поделку улетучивается само по себе. Вангую что сабжевый автор еще дальше отъехавший чем Шигорин. Простой совет если у вас на компьютере установлен Альт Линукс сабж вам подходит на все 146% если нет ни в коем случае не приближайтесь к нему и не скачивайте и не упоминайте в суе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #34, #38

33. Сообщение от Аноним (33), 08-Янв-20, 16:47	–3 +/–
Нет у него позиции как ему сказали так и будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от erthink (ok), 08-Янв-20, 17:08	+1 +/–
> про себя: "антагонист Java" Да, ибо не люблю лишних абстракций ради абстракций и последующей героической борьбы с ними. > А его статья на хабре про то что он написал сортировку не хуже чем гнушный sort это бомба. Не статья, я скорее заметка. Не написал сортировку, а скомбинировал варианты и показал удачный результат. Ну и т.д. > Т.е. новый алгоритм лучше, но это не точно, скачайте мою бд и попробуйте. В нужном мне контексте, показанная там комбинация существующих алгоритмов действительно лучше. Но заведомо известно, что среди всех N! возможных комбинаций данных будут такие, где будет медленнее. + Но я таки еще раз вам доставлю, написав еще одну "статью" в продолжение. Ибо текущий вариант внутренней сортировки в libmdbx на 10-30% быстрее std::sort, причем как на Эльбрусе, так и на x86. > Вангую что сабжевый автор еще дальше отъехавший чем Шигорин. Это комплимент, я читаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #36

35. Сообщение от ананим.orig (?), 08-Янв-20, 17:27	+1 +/–
спасибо. как раз то что хотел услышать. нужно присмотреться к сабжу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

36. Сообщение от erthink (ok), 08-Янв-20, 19:11	+2 +/–
Чтобы не быть голословным и доставить удовольствие местным анонимным икспёртам. Текущая сортировка внутри libmdbx показывает такие циферки: --- Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux random, 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, ok random, 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, ok random, 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, ok random, 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.1 random, 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, ok random, 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, ok random, 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, ok random, 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.0 random, 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, ok random, 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, ok random, 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, ok random, 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, ok random, 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, ok random, 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, ok random, 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 (половина данных отсортирована, четверть в обратном порядке, еще четверть в случайном порядке).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #41

37. Сообщение от erthink (ok), 08-Янв-20, 20:50	+/–
> При этом заявлено, что в этой версии 1.0 её история и будет завершена в угоду другой бд. Не история завершена, а остановлено развитие, ибо некуда. В libmdbx уже сделано примерно всё что можно в рамках текущего формата БД и API. Какие-то мелкие доработки и улучшения конечно возможны, но принципиальное развитие возможно только с изменением формата и сломом совместимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

38. Сообщение от Аноним (38), 08-Янв-20, 23:37	+/–
> чем юзать продукт человека, который пишет про себя: "антагонист Java" Не пользуйтесь. А я взял бы такого человека на заметку, потому что жаба жЫрная, тормозная и дырявая (в любой ипостаси - скала, груви, котлин, какой угодно), и человек, который не хочет иметь с ней дела, как минимум заботится о том, как его продукт будер работать, а не только о том, чтобы побыстрее что-то накарябать и выпихнуть в продакшон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #55

39. Сообщение от Аноним (-), 09-Янв-20, 00:23	+1 +/–
> У него есть позиция При том я догадываюсь кто в какой позе в этой позиции. Очень хорошо что я профайл разработчика и планы по развитию позырил: предупрежден - значит вооружен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #42

40. Сообщение от Аноним (-), 09-Янв-20, 00:25	+/–
> Это не вата, это кодекс поведения государева человека. Жириновский как раз задвинул недавно и о кодексах и о том как эти государевы человеки на самом деле называются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #45

41. Сообщение от Аноним (-), 09-Янв-20, 00:26	+/–
> Эльбрус E8C, компилятор lcc:1.23.19:Jun-19-2019:e2k-v4-linux А конфига которую вот просто хрен проверишь и сравнишь - специальна взята, чтобы маркетинговый булшит получше был? Ну тогда и вам набутыливателей посуровее в гости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #43

42. Сообщение от erthink (ok), 09-Янв-20, 00:30	+1 +/–
>> У него есть позиция > При том я догадываюсь кто в какой позе в этой позиции. Очень > хорошо что я профайл разработчика и планы по развитию позырил: предупрежден > - значит вооружен. А мне-то покажете где вы увидели "планы по развитию", а то я не в курсе (но может-быть забыл где-то что-то удалить/почистить)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

43. Сообщение от erthink (ok), 09-Янв-20, 00:40	+2 +/–
>> Эльбрус 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()` сравнивать некорректно, ибо там много накладных расходов на вызов компаратора).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

44. Сообщение от крокодил (?), 09-Янв-20, 05:20	+1 +/–
В миранде это под вайном не работает, приходится ждать когда допилят sqlite3 драйвер базы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #46, #51

45. Сообщение от Аноним (6), 09-Янв-20, 10:27	+/–
>2020 >обращать внимание на Жириновского
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

46. Сообщение от erthink (ok), 09-Янв-20, 13:55	+2 +/–
> В миранде это под вайном не работает, приходится ждать когда допилят sqlite3 > драйвер базы Это из-за ограничений/недоделок вайна, видимо в нем не реализованы такие функции как NtExtendSection() и т.д. Ситуация слегка анекдотическая: MDBX была сделана для linux (не поддерживала windows), потом поддержка windows была добавлена с решением массы проблем (винда многого не умеет), теперь жалобы о том, что виндовая версия (внезапно) не работает под эмулятором винды на linux. Тем не менее, я еще год назад писал - если будут указаны конкретные проблемы/причины не работоспособности "под вайном", то я постараюсь их решить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от Аноним (47), 09-Янв-20, 18:32	+/–
> линейным масштабированием по ядрам CPU. Ага-ага, на графике его прямо видно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

48. Сообщение от erthink (ok), 09-Янв-20, 18:41	+1 +/–
> Ага-ага, на графике его прямо видно. На графике показаны результаты теста на ноутбуке 2013-го года, с i7-4600U у которого "на самом деле" два ядра (4 в режиме HyperThreading). Информация о модели CPU есть в [README](https://github.com/leo-yuriev/libmdbx#performance-comparison). Кроме этого, там достаточно быстро узким местом становится memory bandwidth. Но в целом, это действительно ляп, который требует (как минимум уточнения). Поэтому спасибо за наводку!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

49. Сообщение от adolfus (ok), 15-Янв-20, 12:38	–1 +/–
До BerkeleyDB все эти упомянутые "СУБД" вряд ли когда-нибудь дорастут. И вообще, чтобы называться СУБД, нужно хотя бы поддерживать вторичные индексы, курсоры, транзакции и команды последовательного доступа в порядке любого из индексов начиная с любого места.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #50

50. Сообщение от erthink (ok), 15-Янв-20, 15:04	+1 +/–
> До 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

51. Сообщение от erthink (ok), 19-Фев-20, 15:35	+1 +/–
Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции NtExtendSection(). Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено. Заведен соответствующий баг https://bugs.winehq.org/show_bug.cgi?id=48620 В libmdbx добавлен костыль https://github.com/erthink/libmdbx/commit/f750086bc190d581cf... Вероятно в какое-то разумное время эти изменения попадут в Миранду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #52

52. Сообщение от JL2001 (ok), 03-Апр-20, 00:38	+/–
> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции > NtExtendSection(). > Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено. а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял в миранде главная проблема была в том, что миранда завершалась совершенно молча и нормальным образом, ни логов, ни проблем, просто нихотит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #53

53. Сообщение от erthink (ok), 03-Апр-20, 01:49	+1 +/–
>> Причина проблем с libmdbx под Wine найдена - это отсутствие реализации функции >> NtExtendSection(). >> Во всех версиях Wine при вызове этой функции приложение будет аварийно завершено. > а для чего использовалась/-уется NtExtendSection() ? по коммиту увы не понял Функционал NtExtendSection() требуется для увеличения размера файла с данными "на ходу", не только без закрытия/открытия, но и автоматически при активной транзакции. > в миранде главная проблема была в том, что миранда завершалась совершенно молча > и нормальным образом, ни логов, ни проблем, просто нихотит Проблема Wine в том, что функция NtExtendSection() экспортируется из ntdll.dll, но при её вызове процесс тупо и безусловно терминируется, а причину можно увидеть только в логах wine (если не отключены). https://bugs.winehq.org/show_bug.cgi?id=48620 Исправить это внутри Wine достаточно проблематично - нужно не только реализовать NtExtendSection(), но и существенно допеределать все управление вируальной памятью. Поэтому пришлось ставить костыли внутри libmdbx/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #54

54. Сообщение от erthink (ok), 03-Апр-20, 01:59	+1 +/–
Ну и коммитов получилось в итоге несколько... см. https://github.com/erthink/libmdbx/issues/83
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

55. Сообщение от _hide_ (ok), 09-Сен-24, 17:45	+/–
Ява работает вполне адекватно. По производительности она уделывает питон раз в 100 и проигрывает чистым сям в 2-10 раз, что не так уж и много. А использование фреймворка для фреймворка ещё не говорит, что тормозит язык, а не используемый подход. Да и ниша явы такая, что докупить пачку серверов всегда дешевле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

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

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