| |
| 2.7, Аноним (7), 22:31, 01/08/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Автор как-то слишком страшно и дотошно формулирует описание исправлений.
Ошибки-то в совсем новом API и проявлялись только на маке.
А остальное и ошибками можно не называть, в GCC таких сотни, если не тысячи.
| | |
|
| 1.4, Аноним (2), 22:20, 01/08/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот что автор пишет про свою СУБД:
"libmdbx is extraordinarily fast ... in the case of libmdbx, a simple linear search may be more profitable than complex indexes"
Просто перебирайте значения
| | |
| |
| 2.5, Аноним (2), 22:23, 01/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
Вот ещё:
"In comparison to LMDB, libmdbx make things “just work” perfectly and out-of-the-box"
| | |
| |
| 3.28, знайка (?), 15:22, 04/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
А вот так и есть.
Работает без глюков LMDB.
Почитайте блог разрабов Erigon.
| | |
|
| 2.6, Аноним (6), 22:23, 01/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
Про асимптотическую сложность не слышал, чо. Действительно, нафига нам индексы.
| | |
| 2.10, Аноним (7), 22:43, 01/08/2025 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Ага, и написано это в подразделе Gotchas.
On the other hand, if you make something suboptimally, you can notice detrimentally only on sufficiently large data.
Автор там похоже удачно стебёться над любителями кодить и читать по-верхам не вникая ;)
| | |
| |
| 3.36, Аффтар (?), 20:44, 26/08/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Там имелось в виду, что нужно вдумчиво подходить к вопросу селективности.
Например, увеличение длины ключа на 1 байт ради более точного поиска может сделать хуже/медленнее чем приблизительный поиск DUPSORT-куста и перебор в нём значений.
| | |
|
|
| |
| 2.29, знайка (?), 15:43, 04/08/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Офигенно работает, и поддержка первоклассная!
В телеге автор очень оперативно и подробно отвечает на все вопросы.
Помог быстрее чем службы поддержки ptsecurity и солара.
| | |
|
| 1.9, Аноним (2), 22:37, 01/08/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– | |
Ещё на его странице: "Donations are welcome to the Ethereum/ERC-20 ... Всё будет хорошо!"
А для кого хорошо? Напомню, оплата товаров и услуг криптовалютой запрещена в России с 2021 года
| | |
| |
| |
| |
| 4.13, Аноним (7), 23:03, 01/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну так логично что автор собирает донаты от индустрии.
Но причем тут запрет на оплату криптой товаров и услуг?
| | |
| |
| 5.16, Аноним (7), 00:05, 02/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
Нет тут никакой скрытой продажи, ведь вы не приобретаете ни товар, ни услугу.
Исходники, документация, поддержка доступны вне зависимости от крипты.
Причем приём платежей в крипте запрещен внутри РФ, но разрешен из-за рубежа.
| | |
|
|
|
|
| |
| 2.20, Анонима (?), 07:29, 02/08/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
десятилетиями блобы хранились в обычных реляционных субд, но кто-то с похмелья подумал что блобы в традиционных субд хранятся неоптимально, на страницах с обычными данными и оперативная память "забивается", и понеслась...
| | |
| |
| |
| 4.27, _ (??), 03:51, 04/08/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Только полные еб***шки думают что SQL db появились __ДО__ key-value db ...
О сколько _вам_ открытий чудных готовит!(С) Наше всиО
| | |
|
| 3.24, Аноним (24), 14:27, 02/08/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если "сводные таблицы" не планируются, то зачем заморачиваться с реляционностью?
| | |
|
|
| |
| 2.23, Аноним (7), 09:06, 02/08/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
ACID
Доступ из нескольких процессов.
Работа читателей без блокировок.
Поддержка "дубликатов", когда с ключом связано очень много значений они хранятся во вложенном b-tree.
Много key-value таблиц в одном файле.
| | |
|
| |
| 2.26, Аноним (7), 18:03, 03/08/2025 [^] [^^] [^^^] [ответить]
| +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.
| | |
|
| 1.31, adolfus (ok), 16:25, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 На фоне BerkeleyDB это MDBX просто школьное поделие. Мало того, у BDB лицензия AGPL, а у MDBX -- Apache.
Ключевое различие между лицензиями:
- AGPL накладывает сильные обязательства по открытию исходного кода при любом использовании программного продукта, в том числе через сеть, что характерно для копилефтных лицензий.
- Apache 2.0 — разрешительная лицензия с защитой патентов, дающая больше свободы в использовании и включении кода в закрытые проекты без обязательств раскрывать исходный код.
| | |
| |
| 2.32, Имя (?), 23:00, 19/08/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон.
Не только лишь все могут это принять.
Главное батхерт успеть вылечить до начала деменции.
| | |
| |
| 3.33, adolfus (ok), 12:26, 26/08/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Поделие уделывает LMDB, а LMDB как тузик грелку рвет этот ваш фон.
Смешно. Оно и пятой части возможностей BDB не реализует, какая тут грелка. Попытка что-то сляпать на замену. Поверх BDB MySQL был написан. Напиши что-либо похожее поверх этого поделия.
| | |
| |
| 4.34, Аффтар (?), 20:37, 26/08/2025 [^] [^^] [^^^] [ответить] | +1 +/– | По части MySQL вы заблуждаетесь, а информация с отсылкой к MySQL не соответствуе... большой текст свёрнут, показать | | |
| |
| 5.37, adolfus (ok), 16:18, 27/08/2025 [^] [^^] [^^^] [ответить]
| +/– |
> 2. LMDB была создана Говардом Чу (Howard Chu) для OpenLDAP ради избавления
> от проблем BerkeleyDB.
От нормальных курсоров и вторичных индексов, да? От детального управления транзакциями, в том числе и вложенными? И что в таком случае остается? -- А то, что невозможно использовать кроме как на локалхосте для кеширования.
Все то, от чего избавился этот ваш Чу, позволяет во многих случаях избавиться от использования sql-серверов. Я знаю несколько достаточно больших проектов на базе BDB, реально работающих более 15 лет. Среди них есть такой, который обслуживает в режиме OLTP полторы сотни клиентов в среднем одновременно.
| | |
| |
| 6.38, Аффтар (?), 23:07, 27/08/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Исходное 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 лет и старше.
| | |
|
|
|
|
|
|
