| 1.1, data man (ok), 22:01, 09/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –17 +/– |
 mdbx.c++ -> mdbx.cpp
mdbx.h++ -> mdbx.hpp
Не буду пользоваться, пока так не сделаете. :-D
| | |
| |
| |
| 3.18, data man (ok), 00:28, 10/05/2021 [^] [^^] [^^^] [ответить]
| –9 +/– | |
Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ по-умолчанию их просто не поддерживает?
Спасибо за минусы, ничего другого тут и не ожидалось.
| | |
| |
| 4.21, erthink (ok), 01:12, 10/05/2021 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ их
> просто не поддерживает?
> Спасибо за минусы, ничего другого тут и не ожидалось.
Минусы не мои.
с++ и h++ = один из _стандартных_ вариантов для файлов с исходными текстами на C++.
Исторически эти расширения не получили распространения из-за унаследованных ограничений на всяких старых и (теперь уже) вымерших системах.
Весь приличный софт давно их поддерживает, например gcc и clang автоматически выбирают/запускают компилятор С++.
Если по какой-то причине это вам неудобно, то вы всегда можете переименовать файлы локально, и т.п.
| | |
| 4.26, Ordu (ok), 07:23, 10/05/2021 [^] [^^] [^^^] [ответить]
| +3 +/– |
 > Неужели необходимо объяснять, что это не общепринятые расширения, и куча программ по-умолчанию их просто не поддерживает?
Да, надо. Приведи пример программы, которая это не поддерживает.
| | |
| |
| 5.30, data man (ok), 09:28, 10/05/2021 [^] [^^] [^^^] [ответить]
| –9 +/– |
> Да, надо.
> Приведи
На сегодня бисер закончился. Может быть, завтра.
После *вежливой* просьбы.
| | |
| |
| 6.41, Ordu (ok), 13:00, 10/05/2021 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> На сегодня бисер закончился. Может быть, завтра.
В смысле тебе подумать надо, потому что ни одного примера программы навскидку привести не можешь? Ну вот я тоже не могу, и поэтому...
> После *вежливой* просьбы.
... вежливо сообщаю тебе, что ты несёшь bullshit.
| | |
|
|
|
|
| 2.3, Аноним (3), 22:06, 09/05/2021 [^] [^^] [^^^] [ответить]
| +7 +/– | |
mdbx.c++/h++ -> mdbx.rs
Не буду пользоваться, пока так не сделаете. :-D
| | |
| 2.4, Аноним (4), 22:08, 09/05/2021 [^] [^^] [^^^] [ответить]
| –3 +/– |
бинарь же не меняется от этого. похожая ситуация и с .htm, который по факту ничем не отличается от привычного .html
| | |
| |
| 3.5, data man (ok), 22:24, 09/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Один анонимный эксперт по факту ничем не отличается от другого.
Они очень похожи в разных ситуациях.
| | |
|
| 2.6, Аноним (6), 22:31, 09/05/2021 [^] [^^] [^^^] [ответить]
| –5 +/– |
Какая гадость, должно быть cxx/hxx чтобы не вызывать отвращения.
| | |
| 2.67, Аноним (68), 12:49, 11/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
>mdbx.c++ -> mdbx.cpp
>mdbx.h++ -> mdbx.hpp
Windows(TM) в такие имена не может?
| | |
| |
| 3.71, erthink (ok), 15:35, 11/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
>>mdbx.c++ -> mdbx.cpp
>>mdbx.h++ -> mdbx.hpp
> Windows(TM) в такие имена не может?
Может давным-давно, и всё это проверяется на CI.
| | |
|
|
| 1.7, Аноним (6), 22:33, 09/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А у сабжа тоже компайлтайм лимиты? Вот у leveldb их нет (во всяком случае не 100 байт или сколько там).
| | |
| |
| 2.10, erthink (ok), 23:07, 09/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
$ make options
## TIP: Use 'make V=1' for verbose.
INSTALL =install
DESTDIR =
prefix =/usr/local
mandir =/usr/local/man
suffix =
CC =cc
CFLAGS_EXTRA =
CFLAGS =-std=gnu11 -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributes
CXX =g++
CXXSTD =-std=gnu++2a
CXXFLAGS =-std=gnu++2a -O2 -g -Wall -Werror -Wextra -Wpedantic -ffunction-sections -fPIC -fvisibility=hidden -pthread -Wno-error=attributes
LD =ld
LDFLAGS =-Wl,--gc-sections,-z,relro,-O1
EXE_LDFLAGS =-pthread
LIBS = -lrt
MDBX_BUILD_OPTIONS =-DNDEBUG=1
## Assortment items for MDBX_BUILD_OPTIONS:
## Note that the defaults should already be correct for most platforms;
## you should not need to change any of these. Read their descriptions
## in README and source code (see src/options.h) if you do.
MDBX_DISABLE_GNU_SOURCE
MDBX_OSX_SPEED_INSTEADOF_DURABILITY
MDBX_ENV_CHECKPID
MDBX_TXN_CHECKOWNER
MDBX_TRUST_RTC
MDBX_ENABLE_REFUND
MDBX_ENABLE_PGOP_STAT
MDBX_ENABLE_MADVISE
MDBX_DISABLE_PAGECHECKS
MDBX_PNL_PREALLOC_FOR_RADIXSORT
MDBX_DPL_PREALLOC_FOR_RADIXSORT
MDBX_WITHOUT_MSVC_CRT
MDBX_ENVCOPY_WRITEBUF
MDBX_FORCE_ASSERTIONS
MDBX_ASSUME_MALLOC_OVERHEAD
MDBX_DEBUG
MDBX_USE_VALGRIND
MDBX_HAVE_C11ATOMICS
MDBX_LOCKING
MDBX_USE_OFDLOCKS
MDBX_USE_SENDFILE
MDBX_USE_COPYFILERANGE
MDBX_USE_SYNCFILERANGE
MDBX_CPU_WRITEBACK_INCOHERENT
MDBX_MMAP_INCOHERENT_FILE_WRITE
MDBX_MMAP_INCOHERENT_CPU_CACHE
MDBX_64BIT_ATOMIC
MDBX_64BIT_CAS
MDBX_UNALIGNED_OK
MDBX_CACHELINE_SIZE
| | |
| |
| 3.12, Аноним (6), 23:20, 09/05/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я не вижу тут MAXKEYSIZE, сколько там захадкожено? 4кб хотя бы влезет?
| | |
| |
| |
| 5.19, Аноним (6), 00:33, 10/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Насколько негативно скажется увеличение размера страницы, в частности, на производительности? 65к это вроде бы достаточно для большинства применений.
| | |
| |
| |
| 7.22, erthink (ok), 01:36, 10/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> у левелдб хоть мегабайты пихай.
Ну засунуть-то можно, толку только мало.
Этакий неуловимый джо наоборот ;)
| | |
|
|
|
|
|
|
| |
| 2.13, Ilya Evseev (?), 23:34, 09/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > А есть какий-нибудь носкуль сервер на сабже?
ardb умеет использовать LMDB.
Скорее всего, после небольшой доработки mdbx тоже сумеет.
| | |
|
| 1.23, Аноним (48), 05:48, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
В чём отличие от RocksDB? Можно ли использовать как storage backend для SQL или Object базы данных?
| | |
| |
| 2.35, erthink (ok), 10:21, 10/05/2021 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Принципиально ничего не изменилось.
Если вычесть ожидание дисковых операций (например запустить в /dev/shm или на RAM-диске), то MDBX/LMDB как-правило оказываются быстрее, ибо
- OlogN от b+tree;
- очень мало лишних действий (оверхеда);
- zerocopy и неблокируемое чтение с масштабированием по ядрам.
С учетом дисковых операций всё в них родимых и упирается. При этом у MDBX/LMDB амплификация записи в точности равна высоте дерева, т.е. тоже OlogN.
Соответственно, принципиальных изменений в бенчмарках нет, так как не меняются эти слагаемые и их пропорции.
| | |
|
| 1.25, Аноним (48), 06:57, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
На 20-30% быстрее чем master LMDB? Мне кажется вы не тестировали давно, а берёте старые цифры.
Что насчёт новейших версий LMDB? Там же тоже код активно пилится, как я понял.
| | |
| |
| 2.36, erthink (ok), 10:42, 10/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> На 20-30% быстрее чем master LMDB? Мне кажется вы не тестировали давно, а берёте старые цифры.
> Что насчёт новейших версий LMDB? Там же тоже код активно пилится, как я понял.
Во-первых, на всякий (чтобы не упрекали в читерстве): 20-30% получается если оценивать скорость работы самих движков (без учета дисков) и отключить в MDBX дополнительный контроль (корректности операций и данных в БД).
В новых версиях нет ничего, чтобы позволяло LMDB становиться быстрее.
Буквально там примерно следующее:
- поддержка чтения больших БД на 32-битных системах (MDB_VL32), что существенно замедляет движок, так как требуете поддерживать кеш "окон отображения" файла БД в ОЗУ.
- поддержка шифрования, что требует дополнительных затрат на поддержку кеша прочитанных/расшифрованных страниц БД.
- добавление txn_id в заголовок страниц для определения их "грязного" статуса, но в MDBX txn_id был добавлен давным-давно.
А различных багов и недочетов куча, их можно перечислять очень долго.
| | |
|
| |
| 2.39, erthink (ok), 12:22, 10/05/2021 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> то скажете про это https://github.com/spacejam/sled? Сравнивали, тестировали?
80% ответа есть в https://github.com/spacejam/sled?#known-issues-warnings
Остальные 20% примерно такие:
1) В сценариях с интенсивным чтением превосходство будет у MDBX, ибо оверхеда и блокировок примерно 0.
2) В MDBX нет WAL - это принципиальный осознанный архитектурный выбор (унаследованный от LMDB) со своими минусами и плюсами.
Поэтому MDBX будет ожидаемо проигрывать в одних сценариях и выигрывать в других.
Соответственно, вопрос тут не в том "кто круче/быстрее", а насколько некий (условно ваш) сценарий использования соответствует свойствам/назначению того или иного движка.
3) Авторы sled пускаются во все тяжкие с lockfree, rw-локами и atomic-операциями ради более-менее параллельного выполнения читающих и пишущих транзакций..., и всё это поверх смеси b-tree с lsm, приправленное массой дополнительных фишек и фичей.
Теоретически такое можно отладить, довести до production стабильность и производительность.
На практике же буду баги, время воспроизведения которых в разы больше времени жизни соответствующей версии кода.
Другими словами, sled = концептуально интересно и действительно может дать существенный "выхлоп", но есть существенные риски что проект никогда не дойдет до production-готовности (см https://github.com/spacejam/sled/issues).
| | |
|
| 1.28, Аноним (28), 08:06, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.
GitHub еще не заблокировали?... недоработка...
| | |
| 1.42, Lefsha (ok), 13:40, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Не совсем в тему, но...
git clone https://abf.io/erthink/ReOpenLDAP.git reopenldap
Cloning into 'reopenldap'...
remote: Enumerating objects: 43000, done.
remote: Counting objects: 100% (43000/43000), done.
remote: Compressing objects: 100% (10332/10332), done.
remote: Total 43000 (delta 33292), reused 42174 (delta 32471)
Receiving objects: 100% (43000/43000), 19.13 MiB | 8.62 MiB/s, done.
Resolving deltas: 100% (33292/33292), done.
fatal: bad object 00000000000000007c000000770000006e000000
fatal: remote did not send all necessary objects
| | |
| |
| |
| 3.47, erthink (ok), 14:01, 10/05/2021 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Тоже самое на github
$ git clone https://github.com/erthink/ReOpenLDAP.git
Клонирование в «ReOpenLDAP»…
remote: Enumerating objects: 43000, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 43000 (delta 0), reused 1 (delta 0), pack-reused 42997
Получение объектов: 100% (43000/43000), 24.88 MiB | 2.04 MiB/s, готово.
Определение изменений: 100% (32830/32830), готово.
$ cd ReOpenLDAP/
$ git fsck
Проверка каталогов объектов: 100% (256/256), готово.
Проверка объектов: 100% (43000/43000), готово.
$ git --version
git version 2.27.0
Аналогично с https://abf.io/erthink/ReOpenLDAP.git и git 2.31.1
---
На всякий: я не занимался ReOpenLDAP-ом два года, в частности туда не портировались важные правки из OpenLDAP, и также движок хранения там совсем старый.
| | |
| |
| 4.49, Lefsha (ok), 17:39, 10/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Кажется выяснилось. проблема проявляется в следущих версиях GIT
=dev-vcs/git-2.31.1
=dev-vcs/git-2.31.0-r1
Откат на 2.30.2 устранил проблему.
| | |
|
|
|
| 1.52, Аноним (48), 19:01, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я так понимаю ACID работает для многопоточности.
А как быть с многопроцессорностью - например когда запускается два экземпляра одного приложения (GUI)? И оба, естественно, полезут в одну БД (по одному пути)
| | |
| |
| 2.53, erthink (ok), 19:30, 10/05/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Я так понимаю ACID работает для многопоточности.
> А как быть с многопроцессорностью - например когда запускается два экземпляра
> одного приложения (GUI)? И оба, естественно, полезут в одну БД (по
> одному пути)
RTFM https://github.com/erthink/libmdbx/blob/master/README.md#libmdbx
- в 1-ов пункте: "Allows a swarm of multi-threaded processes to ACIDly read and update several key-value maps and multimaps in a locally-shared database.", т.е. с много-процессностью всё также хорошо как и с много-поточностью.
- в 5-ом пункте: "Enforces serializability for writers... affords wait-free for parallel readers without atomic/interlocked operations, while writing and reading transactions do not block each other", т.е. все пишущие транзакции выполняются строго последовательно, а читающие не блокируются.
| | |
|
| |
| |
| 3.65, adolfus (ok), 10:45, 11/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Нет руководства по программированию с использованием этого ПО
Также настораживает:
> Операции изменения данных никак не блокируют читателей.
Это не очень понятно. Что прочитает "читатель" если "писатель" не завершит изменение? Запись в объект должна блокировать чтение из объекта на время исполнения записи. Тем более, если, как Вы говорите, имеется поддержка вторичных ключей.
| | |
| |
| 4.66, erthink (ok), 12:06, 11/05/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> Нет руководства по программированию с использованием этого ПО.
RTFM https://erthink.github.io/libmdbx/usage.html#starting
> Также настораживает:
> > Операции изменения данных никак не блокируют читателей.
RTFM https://github.com/erthink/libmdbx/blob/master/README.md#features, среди прочего, там есть строки:
- Fully ACID-compliant, through to MVCC and CoW.
- Readers are non-blocking, notwithstanding snapshot isolation.
Со ссылками на пояснения что такое ACID, MVCC, CoW и snapshot isolation.
Кроме этого, см. https://ru.bmstu.wiki/LMDB_(Lightning_Memory-Mapped_Database) - вся эта информация в принципе применима к libmdbx, ибо "Historically, libmdbx is a deeply revised and extended descendant of the Lightning Memory-Mapped Database" (https://github.com/erthink/libmdbx/blob/master/README.md#history).
> Это не очень понятно. Что прочитает "читатель" если "писатель" не завершит изменение?
RTFM: ACID предполагает транзакции с изоляцией, т.е. читатели видят результаты только успешно завершенных транзакций.
> Запись в объект должна блокировать чтение из объекта на время исполнения записи.
RTFM: MVCC, snapshot isolation, page shadowing and CoW.
До фиксации транзакции писатель изменяет копию данных, которая не видна читателям.
Примерно как https://ru.wikipedia.org/wiki/Read-copy-update
> Тем более, если, как Вы говорите, имеется поддержка вторичных ключей.
Еще раз:
- в key-value не может быть вторичны ключей, ибо тогда это не key-value просто по определению.
- типизированные колонки, nullable, вторичные ключи, составные индексы - реализованы в https://github.com/PositiveTechnologies/libfpta поверх libmdbx.
| | |
|
|
|
| 1.58, Аноним (58), 22:10, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
>а введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.
Ну это пока ... В уважаемых транснациональных компаниях давно уже требуют перед заключением договора заявления, что сама фирма не внесена ни в один санкционный список, и что продукция и услуги, поставленные по договорам, не будут переданы в руки лиц и компаний, находящихся в санкционных списках. Так что вангую, что с GH вас рано или поздно выкинут, а вместо врнды придётся довольствоваться реактосью. В прочем это к лучшему, наконец-то реактось до юзабельного состояния допилят.
P. S. Не брат ты мне.
| | |
| |
| 2.59, erthink (ok), 22:46, 10/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
>>а введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.
> Ну это пока ... В уважаемых транснациональных компаниях давно уже требуют перед
> заключением договора заявления, что сама фирма не внесена ни в один
> санкционный список, и что продукция и услуги, поставленные по договорам, не
> будут переданы в руки лиц и компаний, находящихся в санкционных списках.
Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".
> Так что вангую, что с GH вас рано или поздно выкинут,
> а вместо врнды придётся довольствоваться реактосью. В прочем это к лучшему,
> наконец-то реактось до юзабельного состояния допилят.
Обязательно, ведь каждый украинский хомячок - лев, и племянник Ванги, ибо еще не гриб, пока выкапывает черное море!
Ну и в завтрашний день не все могут смотреть.
Вернее смотреть могут не только лишь все, мало кто может это делать!
;)
| | |
| |
| 3.62, Аноним (58), 23:25, 10/05/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".
Ну верно, це Європа ведь, соответственно и глобус с Европой и Гермашкой. Не то что глобус Великой прекрасной России с Нашим Севером.
| | |
|
| |
| 3.61, Аноним (58), 23:19, 10/05/2021 [^] [^^] [^^^] [ответить]
| +/– | |
>Some results may have been delisted consistent with local laws
А телек я не смотрю ни в каком виде.
| | |
| |
| 4.64, bOOster (ok), 09:38, 11/05/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Поведение в стиле одноименного действия страуса никогда никого к добру не приводило.
| | |
| |
| |
| 6.72, bOOster (ok), 06:44, 12/05/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> А, ну смотрите регулярно шоу Соловьёва, станете добрее.
Ну и зачем нам врать про "не смотрю ТВ ни в каком виде" если в курсе за такие ШОУ? Я, например, смотрю ТВ, но ниразу не в курсе за такие ШОУ.
| | |
|
|
|
|
|
|
