The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10

09.05.2021 18:04

После трех месяцев разработки состоялся выпуск библиотеки libmdbx 0.10.0 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License. libmdbx является глубокой переработкой СУБД LMDB и по заявлению разработчиков превосходит своего прародителя по надежности, набору возможностей и производительности. Заявляется, что libmdbx до 20% быстрее LMDB в CRUD сценариях и до 30% быстрее, если при сборке libmdbx отключить внутренний контроль до сопоставимого с LMDB уровня.

Libmdbx предлагает ACID, строгую сериализацию изменений и неблокирующее чтение с линейным масштабированием по ядрам CPU. В libmdbx большое внимание уделяется качеству кода, стабильной работе API, тестированию и автоматическим проверкам. Поддерживается автокомпактификация, автоматическое управление размером БД, единый формат БД для 32-битных и 64-битных сборок, оценка объёма выборок по диапазонам (range query estimation). Поставляется утилита проверки целостности структуры БД с некоторыми возможностями восстановления. C 2016 года проект финансируется компанией Positive Technologies и c 2017 года используется в её продуктах, а введённые правительством США санкции против Positive Technologies не оказывают какого-либо заметного влияния.

Основные новшества, доработки и исправления, добавленные после прошлого выпуска:

  • Доступны привязка для Ruby от Mahlon E. Smith и пробная версия привязок для Python от Noel Kuntze, обновлены привязки для GoLang от Алексея Шарова.
  • Для режима "MDBX_WRITEMAP", когда данные БД изменяются непосредственно в ОЗУ, реализовано "прозрачное сохранение" на диск измененных страниц БД. Теперь, после завершения каждой операции, такие страницы сразу полностью готовы для записи, и ядро ОС может самостоятельно сбрасывать их на диск, а фиксация транзакции не потребует их модификации. В результате в нагруженных сценариях с недостатком ОЗУ объем дисковых операций может сокращаться до 2 раз.
  • Реализовано вытеснение давно неиспользуемых теневых копий измененных страниц, с предпочтением вытеснения страниц с большими/длинными значениями, которые в подавляющем большинстве сценариев изменяются только один раз за транзакцию. В результате уменьшается объем обмена с диском и увеличивается производительность в сценариях с очень большими транзакциями.
  • Реализован "умный" режим разделения страниц при вставке ключей. Теперь при вставке упорядоченных последовательностей автоматически обеспечивается полное заполнение страниц, а в остальных случаях более оптимальная балансировка дерева. В результате, в среднем, страницы БД заполняются более оптимально, а B-дерево получается более сбалансированным, что положительно влияет на производительность.
  • Добавлена статистика операций со страницами, что позволяет точно оценивать стоимость модифицирующих операций с БД.
  • Устранено более десятка недочётов и ошибок, в том числе: решены проблемы со сборкой посредством MinGW, использования `std::filesystem::path` в iOS <= 13.0, сборка с таргетированием на старые версии Windows и т.д.
  • Суммарно внесено более 200 изменений в 66 файлах, добавлено ~6500 строк, удалено ~4500.

Отдельно хочется отметить выбор libmdbx проектом Erigon (турбо-форк Go-Ethereum) libmdbx в качестве нового бекэнда хранения, а также поблагодарить команду проекта (в особенности Алексея Шарова, Артёма Воротникова и Алексея Ахунова) за большую помощь в тестировании в экстремальных сценариях использования. В частности, так был обнаружен и устранен дефект в управлении упреждающим чтением/кэшированием, который приводил к деградации производительности в сложно-воспроизводимых сценариях с большими БД.

  1. Главная ссылка к новости (https://github.com/erthink/lib...)
  2. OpenNews: Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9.3
  3. OpenNews: Выпуск LDAP-сервера ReOpenLDAP 1.1.9
  4. OpenNews: Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP
  5. OpenNews: Выпуск библиотеки хэш-функций Fast Positive Hash 2.0.1
Автор новости: erthink
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/55114-mdbx
Ключевые слова: mdbx, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (62) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, data man (ok), 22:01, 09/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    mdbx.c++ -> mdbx.cpp
    mdbx.h++ -> mdbx.hpp

    Не буду пользоваться, пока так не сделаете. :-D

     
     
  • 2.2, erthink (ok), 22:06, 09/05/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    MithrilDB на Rust зарелизится раньше ;)
     
     
  • 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

     
     
  • 3.48, Аноним (48), 15:25, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Только после того как на Zig перепишут
     
  • 3.68, Аноним (68), 12:52, 11/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    mdbx.c++/h++ -> mdbx.js
     
  • 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 чтобы не вызывать отвращения.
     
     
  • 3.29, bergentroll (ok), 08:32, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    c××
     
     
  • 4.32, немосапиенс (?), 09:45, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    .сипп или .си++
     
  • 2.55, adolfus (ok), 21:13, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    с++ -- си-кросс-кросс
    а cpp -- это что?

     
     
  • 3.63, funny.falcon (?), 09:38, 11/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    p - в смайликах это высунутый язык. Типа, "беее".

    Т.о. cpp - сибеебее

     
  • 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кб хотя бы влезет?
     
     
  • 4.14, erthink (ok), 23:40, 09/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    см. https://github.com/erthink/libmdbx/blob/master/README.md#limitations

    Т.е. "немного лучше" чем у Oracle, см. https://blogs.oracle.com/sql/how-to-fix-ora-01450-maximum-key-length-6398-exce

     
     
  • 5.19, Аноним (6), 00:33, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько негативно скажется увеличение размера страницы, в частности, на производительности? 65к это вроде бы достаточно для большинства применений.
     
     
  • 6.20, Аноним (6), 00:36, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя всё равно ограничения, у левелдб хоть мегабайты пихай.
     
     
  • 7.22, erthink (ok), 01:36, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > у левелдб хоть мегабайты пихай.

    Ну засунуть-то можно, толку только мало.
    Этакий неуловимый джо наоборот ;)

     

  • 1.11, YetAnotherOnanym (ok), 23:20, 09/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А есть какий-нибудь носкуль сервер на сабже?
     
     
  • 2.13, Ilya Evseev (?), 23:34, 09/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А есть какий-нибудь носкуль сервер на сабже?

    ardb умеет использовать LMDB.
    Скорее всего, после небольшой доработки mdbx тоже сумеет.

     
     
  • 3.16, YetAnotherOnanym (ok), 23:54, 09/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо!
     
  • 2.15, erthink (ok), 23:54, 09/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Когда-то давно Ховард баловался с https://github.com/LMDB/sqlightning.
    Там что-то вполне рабочее, но много собственных тестов SQLite не проходит.

    Потом (вроде-бы) по мотивам этого PoC сделали https://github.com/LumoSQL/lumosql.
    Сам не пробовал, но теоретически оно рабочее и за пару дней можно пересадить с LMDB на MDBX.

    Еще есть https://github.com/PositiveTechnologies/libfpta с табличками, колонками, индексами..., но без SQL.

     
     
  • 3.17, YetAnotherOnanym (ok), 00:08, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо!
     

  • 1.23, Аноним (48), 05:48, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В чём отличие от RocksDB? Можно ли использовать как storage backend для SQL или Object базы данных?
     
     
  • 2.33, erthink (ok), 10:10, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В чём отличие от RocksDB?

    RocksDB - это ДЫЬ (https://ru.wikipedia.org/wiki/LSM-%D0%B4%D0%B5%D1 с дополнительними читами и фичами.

    MDBX - это B+Tree (https://ru.wikipedia.org/wiki/B%E2%81%BA-%D0%B4% со своими читами и фичами.
    Отличий как в плюс, так и в минус, очень много чтобы писать здесь, но в Сети есть масса информации.
    Можете начать с https://github.com/erthink/libmdbx#comparison-with-other-databases и https://www.opennet.ru/openforum/vsluhforumID3/121987.html#43

    > Можно ли использовать как storage backend для SQL или Object базы данных?

    Да можно, если что-то "прикрутить", см https://www.opennet.ru/openforum/vsluhforumID3/124185.html#15

     
     
  • 3.40, erthink (ok), 12:25, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    s/ДЫЬ/LSM-tree/
     

  • 1.24, Аноним (48), 06:50, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это, конечно, впечатляет https://www.github.com/lmdbjava/benchmarks/tree/master/results%2F20160710

    Интересно посмотреть что-нибудь посвежее и для SSD

     
     
  • 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 был добавлен давным-давно.

    А различных багов и недочетов куча, их можно перечислять очень долго.

     

  • 1.27, Аноним (48), 07:40, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что скажете про это https://github.com/spacejam/sled? Сравнивали, тестировали?
     
     
  • 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

     
     
  • 2.44, Урри (ok), 13:41, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя место на диске закончилось.
     
     
  • 3.46, Lefsha (ok), 13:48, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не похоже.
    Другие работают в этом же месте.
     
  • 2.45, Lefsha (ok), 13:44, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тоже самое на github
     
     
  • 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.54, Аноним (48), 20:00, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Беру! Спасибо за подробные ответы, очень полезно
     

  • 1.56, adolfus (ok), 21:15, 10/05/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    курсоры и вторичные ключи есть?

     
     
  • 2.57, erthink (ok), 21:22, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > курсоры и вторичные ключи есть?

    Курсоры есть, а вторичных ключей в key-value не бывает (для этого есть https://github.com/erthink/libfpta).

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >Воистину, причём все эти (само)уважаемые "транснациональные компании" целиком где-то на "глобусе украины".

    Ну верно, це Європа ведь, соответственно и глобус с Европой и Гермашкой. Не то что глобус Великой прекрасной России с Нашим Севером.

     
  • 2.60, erthink (ok), 22:50, 10/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А если серьезно, то см https://tv.rbc.ru/archive/ekskluziv/609155ee2ae596b067b3745b

    Юрий там очень хорошо всё рассказал.

     
     
  • 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 +/
    Поведение в стиле одноименного действия страуса никогда никого к добру не приводило.
     
     
  • 5.70, Аноним (68), 13:01, 11/05/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А, ну смотрите регулярно шоу Соловьёва, станете добрее.
     
     
  • 6.72, bOOster (ok), 06:44, 12/05/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А, ну смотрите регулярно шоу Соловьёва, станете добрее.

    Ну и зачем нам врать про "не смотрю ТВ ни в каком виде" если в курсе за такие ШОУ? Я, например, смотрю ТВ, но ниразу не в курсе за такие ШОУ.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру