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

"Выпуск встраиваемой СУБД libmdbx 0.13.6 "	+/–
Сообщение от opennews (ok), 01-Авг-25, 21:57
Опубликован выпуск библиотеки libmdbx 0.13.7 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение.  Код libmdbx распространяется под лицензией Apache 2.0. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000. Для libmdbx предлагается развитое API для C++, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala. Из проектов, использующих libmdbx, можно отметить Isar, Erigon и Reth, а также разработки компаний StarkWare и Positive Technologies... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63653
Ответить | Правка | Cообщить модератору

Сообщения

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

2. Сообщение от Аноним (2), 01-Авг-25, 22:08	–2 +/–
Что-то ошибок многовато
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

4. Сообщение от Аноним (2), 01-Авг-25, 22:20	+/–
Вот что автор пишет про свою СУБД: "libmdbx is extraordinarily fast ... in the case of libmdbx, a simple linear search may be more profitable than complex indexes" Просто перебирайте значения
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #6, #10

5. Сообщение от Аноним (2), 01-Авг-25, 22:23	+/–
Вот ещё: "In comparison to LMDB, libmdbx make things “just work” perfectly and out-of-the-box"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #28

6. Сообщение от Аноним (6), 01-Авг-25, 22:23	+/–
Про асимптотическую сложность не слышал, чо. Действительно, нафига нам индексы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Аноним (7), 01-Авг-25, 22:31	+2 +/–
Автор как-то слишком страшно и дотошно формулирует описание исправлений. Ошибки-то в совсем новом API и проявлялись только на маке. А остальное и ошибками можно не называть, в GCC таких сотни, если не тысячи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Аноним (8), 01-Авг-25, 22:32	+1 +/–
Пользуюсь, нареканий нет, спасибо автору!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #35

9. Сообщение от Аноним (2), 01-Авг-25, 22:37	–4 +/–
Ещё на его странице: "Donations are welcome to the Ethereum/ERC-20 ... Всё будет хорошо!" А для кого хорошо? Напомню, оплата товаров и услуг криптовалютой запрещена в России с 2021 года
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

10. Сообщение от Аноним (7), 01-Авг-25, 22:43	+3 +/–
Ага, и написано это в подразделе Gotchas. On the other hand, if you make something suboptimally, you can notice detrimentally only on sufficiently large data. Автор там похоже удачно стебёться над любителями кодить и читать по-верхам не вникая ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #36

11. Сообщение от Аноним (7), 01-Авг-25, 22:46	+/–
А причем тут донаты и продажа крипты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #12

12. Сообщение от Аноним (2), 01-Авг-25, 23:00	+/–
"Since 2020 libmdbx is used in Ethereum"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #13

13. Сообщение от Аноним (7), 01-Авг-25, 23:03	+/–
Ну так логично что автор собирает донаты от индустрии. Но причем тут запрет на оплату криптой товаров и услуг?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #14, #16

14. Сообщение от Аноним (2), 01-Авг-25, 23:42	–3 +/–
Так эти самые донейшены - разве не скрытая оплата товара?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #30

16. Сообщение от Аноним (7), 02-Авг-25, 00:05	+/–
Нет тут никакой скрытой продажи, ведь вы не приобретаете ни товар, ни услугу. Исходники, документация, поддержка доступны вне зависимости от крипты. Причем приём платежей в крипте запрещен внутри РФ, но разрешен из-за рубежа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

18. Сообщение от Аноним10084 и 1008465039 (?), 02-Авг-25, 01:25	+/–
Что-то баз данных ключ-значение много очень стало
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20

19. Сообщение от Аноним (19), 02-Авг-25, 04:02	–2 +/–
Чем она лучше dbm?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

20. Сообщение от Анонима (?), 02-Авг-25, 07:29	–1 +/–
десятилетиями блобы хранились в обычных реляционных субд, но кто-то с похмелья подумал что блобы в традиционных субд хранятся неоптимально, на страницах с обычными данными и оперативная память "забивается", и понеслась...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22, #24

22. Сообщение от Аноним (22), 02-Авг-25, 08:56	–1 +/–
Дидам хватало — и нам должно хватать, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #27

23. Сообщение от Аноним (7), 02-Авг-25, 09:06	+1 +/–
ACID Доступ из нескольких процессов. Работа читателей без блокировок. Поддержка "дубликатов", когда с ключом связано очень много значений они хранятся во вложенном b-tree. Много key-value таблиц в одном файле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

24. Сообщение от Аноним (24), 02-Авг-25, 14:27	+1 +/–
Если "сводные таблицы" не планируются, то зачем заморачиваться с реляционностью?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

25. Сообщение от 14yoexpert (?), 03-Авг-25, 13:56	+1 +/–
Нахрена козе боян когда есть всеми используемый sqlite?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

26. Сообщение от Аноним (7), 03-Авг-25, 18:03	+2 +/–
Для большинства web-поделок и мобильных свистелок sqlite подходит идеально. И 99% разработчиков MDBX не нужна, именно как баяйн козе. Но есть куча сценариев где удобство sqlite малополезно или слишком дорого, либо когда масштаб не-лайтовый как в Ethereum. Поэтому, например, Erigon и Reth сидят на MDBX. Еще sqlightning (https://github.com/LMDB/sqlightning) намекает что sqlite можно ускорить заменив внутреннее хранилище и b-tree на LMDB. За 12 лет инфа конечно устарела, но в Isar (БД для Flutter, с блекджеком и т.п.) была поддержка sqlite и выходило что MDBX примерно вдвое быстрее. Картинки с результатами и исходники бенчмарков где-то на Github.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

27. Сообщение от _ (??), 04-Авг-25, 03:51	+2 +/–
Только полные еб***шки думают что SQL db появились __ДО__ key-value db ... О сколько _вам_ открытий чудных готовит!(С) Наше всиО
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

28. Сообщение от знайка (?), 04-Авг-25, 15:22	+/–
А вот так и есть. Работает без глюков LMDB. Почитайте блог разрабов Erigon.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

29. Сообщение от знайка (?), 04-Авг-25, 15:43	+1 +/–
Офигенно работает, и поддержка первоклассная! В телеге автор очень оперативно и подробно отвечает на все вопросы. Помог быстрее чем службы поддержки ptsecurity и солара.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

30. Сообщение от Аноним (30), 04-Авг-25, 19:52	+/–
Диванные юристы на опеннете :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

31. Сообщение от adolfus (ok), 19-Авг-25, 16:25	–2 +/–
На фоне BerkeleyDB это MDBX просто школьное поделие. Мало того, у BDB лицензия AGPL, а у MDBX -- Apache. Ключевое различие между лицензиями: - AGPL накладывает сильные обязательства по открытию исходного кода при любом использовании программного продукта, в том числе через сеть, что характерно для копилефтных лицензий. - Apache 2.0 — разрешительная лицензия с защитой патентов, дающая больше свободы в использовании и включении кода в закрытые проекты без обязательств раскрывать исходный код.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

32. Сообщение от Имя (?), 19-Авг-25, 23:00	+2 +/–
Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон. Не только лишь все могут это принять. Главное батхерт успеть вылечить до начала деменции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #33

33. Сообщение от adolfus (ok), 26-Авг-25, 12:26	–1 +/–
> Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон. Смешно. Оно и пятой части возможностей BDB не реализует, какая тут грелка. Попытка что-то сляпать на замену. Поверх BDB MySQL был написан. Напиши что-либо похожее поверх этого поделия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #34

34. Сообщение от Аффтар (?), 26-Авг-25, 20:37	+1 +/–
По части MySQL вы заблуждаетесь, а информация с отсылкой к MySQL не соответствует действительности: 1. MySQL не был написан поверх Berkeley DB. Поддержка BDB как одного из storage engine была добавлена в 2000 спустя примерно 5 лет после первого релиза, а еще через 5 лет удалена. Подключали BDB (предположительно, свечку не держал) для "попробовать улучшить" некоторые показатели, но результат не оправдал ожиданий. Berkeley DB не дала ничего хорошего: ни производительности, ни стабильности, ни уменьшения потребления памяти, ни популярности. Пользователи не пользовались BDB, а по объективным причинам предпочитали MyISAM или InnoDB. Поэтому возможность использования Berkeley DB удалили из MySQL почти 20 лет назад. 2. Нет принципиальных препятствий для использования MDBX/LMDB в качестве storage engine в SQL-движках, в том числе в MySQL. Это может подтвердить любой специалист разбирающийся в теме. Более того, эксперимент с SQLightning (SQLite пересаженный на LMDB) показал кратный рост производительности в релевантных сценариях. Далее, если не ошибаюсь, то уже давал комментарии/пояснения по теме "сравнения" BerkeleyDB и MDBX, но видимо стоит повторить. 1. MDBX является развитием/допеределкой LMDB. При этом исправлено множество ошибок, добавлены новые возможности, ликвидированы или смягчены архитектурные проблемы, принципиально (до нескольких порядков) увеличена производительность в специфических нагруженных сценариях, и т.д. Однако, все базовые свойства и возможности сохранены. Поэтому сравнивать с BDB лучше LMDB, но не забывая что MDBX "тоже самое, только лучше". 2. LMDB была создана Говардом Чу (Howard Chu) для OpenLDAP ради избавления от проблем BerkeleyDB. В Сети можно найти массу соответствующих материалов (слайды, статьи, видео, результаты бенчмарков и исходный код). Первые тесты Говарда показали что LMDB в 2-3 раза быстрее BerkeleyDB, процесс slapd потреблял в 2-3 раза меньше памяти, даже БД была на 30% меньше, и т.д. 3. Пожалуй принципиальное отличие MDBX/LMDB от BerkeleyDB в отсутствии накладных расходов на лишнее. Нет затрат на возню с блокировками, так как для читателей обеспечивается lockfree, а пишущие транзакции сериализуются одним мьютексом. Нет затрат на возню с кешированием, так как файл БД отображенный в память автоматически кешируется ядром ОС (причем с использованием всего свободной памяти). Нет затрат на WAL и undo/redo/replay при открытии БД, и т.д. Поэтому MDBX/LMDB просто делают меньше системных вызовов и меньше тратят таков ЦПУ на обработку запросов. 4. Тем не менее, MDBX/LMDB действительно являются относительно простыми/прозрачными движками хранения (без собственных тредов, без WAL) с отображением БД в ОЗУ. Соответственно, "совершенно внезапно" они хорошо подходят для одних сценариев использования и совсем не подходят для других (много раз отвечал/пояснял в комментариях на opennet). В том числе, конечно, есть сценарии где BDB будет предпочтительнее и/или даже лучшим вариантом из-за наличия конкретных фичей/возможностей. 5. В подходящих (хотя-бы не противопоказанных) сценариях использования, MDBX/LMDB позволяют получить потребительские качества кратно превосходящие Berkeley DB. Это не значит что так будет всегда, и/или во всех случаях, и/или без дополнительных усилий, но всё-таки MDBX/LMDB _могут_ быть намного быстрее BDB. А MDBX еще может эффективно обрабатывать огромные пишущие транзакции (с объемом изменений в сотни гигабайт, в БД размером в несколько терабайт). Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #37

35. Сообщение от Аффтар (?), 26-Авг-25, 20:39	+/–
Спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

36. Сообщение от Аффтар (?), 26-Авг-25, 20:44	+/–
Там имелось в виду, что нужно вдумчиво подходить к вопросу селективности. Например, увеличение длины ключа на 1 байт ради более точного поиска может сделать хуже/медленнее чем приблизительный поиск DUPSORT-куста и перебор в нём значений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

37. Сообщение от adolfus (ok), 27-Авг-25, 16:18	+/–
> 2. LMDB была создана Говардом Чу (Howard Chu) для OpenLDAP ради избавления > от проблем BerkeleyDB. От нормальных курсоров и вторичных индексов, да? От детального управления транзакциями, в том числе и вложенными? И что в таком случае остается? -- А то, что невозможно использовать кроме как на локалхосте для кеширования. Все то, от чего избавился этот ваш Чу, позволяет во многих случаях избавиться от использования sql-серверов. Я знаю несколько достаточно больших проектов на базе BDB, реально работающих более 15 лет. Среди них есть такой, который обслуживает в режиме OLTP полторы сотни клиентов в среднем одновременно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #38

38. Сообщение от Аффтар (?), 27-Авг-25, 23:07	+/–
Исходное API LMDB во многом копирует Berkeley DB, но с существенным упрощением за счет отказа от лишнего. Курсоры в MDBX/LMDB такие же как в Berkeley DB. Точнее говоря, некоторые отличия есть, но сводятся к объективным отличиям в возможностях движков. Вложенные транзакции тоже есть, и non-durable тоже. Но ими почти никто не пользуется. В OpenLDAP вторичные индексы были не нужны и Говард не стал их делать (а я бы наверное сделал). Однако, несмотря на полезность вторичных индексов в реальности они оказались не востребованными: - если возможностей простого key-value не хватает индустрия предпочитает SQL (SQLite либо внешний сервер); - там где накладные расходы на SQL слишком велики и вложения в разработку оправданы, реализуются собственные схемы со всякими трюками и экономией на спичках. 30 лет назад, когда делали BDB, всё было иначе. В том числе, диски были медленнее и собственные накладные расходы BDB на кеширование и блокировки были незаметны. Языков программирования и их runtime-сред было сильно меньше. Темп изменений в схемах данных был на порядок меньше. Поэтому было приемлемо заморачиваться с BDB и возится с собственными кортежами и индексами. Сейчас же всё сводится к трем вариантам и их комбинации: 1) SQLite или SQL-сервер; 2) key-value из-за достаточности и/или простоты схемы данных; 3) собственные решения ради уменьшения накладных расходов. Вторичные индексы BDB тут оказываются не востребованными, а часто и BDB в целом. MDBX/LMDB же работают в пунктах 2 и 3, но (конечно) не во всех случаях, а там где подходят под сценарий использования БД. Всё сказанное не ставит под сомнения факта что есть много проектов использующих BDB. Однако, в основном это именно проекты возрастом от 15 лет и старше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

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

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