The OpenNET Project / Index page

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

Выпуск компактной встраиваемой СУБД libmdbx 0.9.1

30.09.2020 20:32

Выпущена версия 0.9.1 библиотеки libmdbx (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License.

Текущая версия является компромиссом между намерением выпустить долговременную стабильную версию 1.0 с полноценной поддержкой C++ и нежеланием откладывать релизы из-за неготовности к заморозке нового C++ API. Представленный релиз является результатом 9 месяцев работы направленной на стабилизацию библиотеки и повышения удобства её использования, а также включает предварительную версию C++ API.

Библиотека libmdbx является не просто «форком», а кардинально переработанным потомком LMDB - транзакционной встраиваемой СУБД класса «ключ-значение» на основе дерева B+ без упреждающей журнализации, которая позволяет многопоточным процессам конкурентно и эффективно работать с локально-разделяемой (не сетевой) БД без выделенного серверного процесса. Libmdbx принципиально расширяет возможности своего прародителя, одновременно устраняя, либо смягчая недостатки. При этом, по убеждению разработчиков, libmdbx немного быстрее и существенно надежнее LMDB.

libmdbx предлагает ACID, строгую сериализацию изменений и неблокирующее чтение с линейным масштабированием по ядрам CPU. Результаты тестирования производительности (отправка параллельных запросов на чтение/поиск в 1-2-4-8 потоках на CPU i7-4600U c 2-я физическими ядрами в режиме 4-х потоков HyperThread):

Самые важные отличия MDBX, относительно LMDB:

  • Принципиально больше внимания уделяется качеству кода, стабильной работе API, тестированию и автоматическим проверкам.
  • Существенно больше контроля во время работы, начиная от проверки параметров, до внутреннего аудита структур базы данных.
  • Автокомпактификация и автоматическое управление размером БД.
  • Единый формат БД для 32-битных и 64-битных сборок.
  • Оценка объёма выборок по диапазонам (range query estimation).
  • Поддержка ключей вдвое большей длины и выбираемый пользователем размер страницы БД.
  • Утилита проверки целостности структуры БД с некоторыми возможностями восстановления.



Основные новшества и доработки после предыдущей новости с представлением версии 0.5 в январе 2020:

  • Для оперативной поддержки и ответов на вопросы создана открытая группа в Telegram.
  • Устранено более десятка ошибок и недочетов (см. журнал изменений).
  • Исправлена масса опечаток и орфографических ошибок, множественные косметические улучшения.
  • Расширены тестовые сценарии.
  • Реализована поддержка iOS, Android, buildroot, Musl, uClibc, WSL1 и Wine.
  • Представлена предварительная версия C++ API в одном заголовочном файле.
  • Оформлена встроенная документация в формате Doxygen и автоматическая генерация Online документации.
  • Обеспечено автоматическое формирование архивов с амальгамированными исходными текстами.
  • Добавлена поддержка подготовки транзакций и курсоров, пользовательских контекстов для транзакций и курсоров.
  • Реализованы дополнительные методы контроля ссылочной целостности в MVCC-снимках B+tree.
  • Добавлена поддержка проверки MVCC-снимка БД, доступного через любую мета-страницу с возможностью переключения для восстановления.
  • Реализована поддержка повторного открытия БД из одного процесса в целях тестирования и т.п.
  • Реализована автоматическая обработка опции MDBX_NOSUBDIR при открытии БД.
  • Добавлены функции формирования целочисленных ключей из значений плавающей точки и «универсальных» чисел JavaScript.
  • Суммарно внесено 430 изменений, затронувших 93 файла, добавлено более 25 тысяч строк, более 8.5 тысяч строк удалено.

Последующая разработка libmdbx будет сосредоточена на формировании финального C++ API, дальнейшей стабилизации базового кода, повышению удобства использования библиотеки, а также формирования пакетов для популярных дистрибутивов Linux. Из предполагаемых доработок стоит отметить поддержку ключей в формате MessagePack.

  1. Главная ссылка к новости (https://github.com/erthink/lib...)
  2. OpenNews: Опубликован второй кандидат в релизы встраиваемой СУБД libmdbx 1.0
  3. OpenNews: Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP
  4. OpenNews: Первый стабильный выпуск графо-ориентированной СУБД Nebula Graph
  5. OpenNews: Стабильный релиз СУБД FoundationDB 6.0, развиваемой компанией Apple
  6. OpenNews: Выпуск СУБД Redis 6.0
Автор новости: Леонид Юрьев
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53812-libmdbx
Ключевые слова: libmdbx, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, JL2001 (ok), 21:18, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    баги в miranda с mdbx под wine все починили уже?
     
     
  • 2.2, erthink (ok), 21:38, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В Wine не реализованы некоторые принципиальные вещи, без которых libmdbx не может динамически менять размер БД. Это нельзя починить в libmdbx, максимум - чтобы не падало внутри Wine, и это сделано ещё весной.

    Тем не менее, Миранда сможет работать с libmdbx под Wine если сделать соответствующие доработки в самой Миранде (например, задавать достаточный, но фиксированный размер БД).

     
     
  • 3.27, _hide_ (ok), 10:55, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользуйтесь Dbx_sqlite.dll, если приспичило вайнить миранду
     
     
  • 4.28, erthink (ok), 11:15, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На всякий

    1) sqlite не работает под Wine по схожим причинам, см https://github.com/miranda-ng/miranda-ng/issues/2323

    2) С плагином dbx_sqlite связано 8 багов (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is:issue+label:Dbx_s), а с плагином libmdbx по-сути ни одного (https://github.com/miranda-ng/miranda-ng/issues?q=is:open+is:issue+label:Dbx_m): из двух один баг является напоминалкой об упомянутой выше доработке, а второй про роспись памяти где-то в миранде (вовсе не факт что в плагине).

    3) C sqlite будет несколько медленнее (см https://www.opennet.dev/openforum/vsluhforumID3/121987.html#9), но впрочем очень сильно зависит от реализации самих "плагинов".

     
     
  • 5.34, _hide_ (ok), 19:16, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > На всякий
    > 1) sqlite не работает под Wine по схожим причинам, см https://github.com/miranda-ng/miranda-ng/issues/2323

    У меня работает, что я сделал неправильно? Правда под x32. И да, плагин контакт листа я тоже поменял.

     
     
  • 6.35, _ (??), 21:28, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Может у dartraiden-а спросить нафига он завел эту багу, если всё работает?
     
     
  • 7.40, dartraiden (?), 14:11, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не работает оно (убунта 20.04 + последний стабильный/тестовый вайн). На 32-битных дистрах не пробовал, да.
     
     
  • 8.49, _hide_ (ok), 12:55, 05/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    О да, дистр тут не важен - важно, чтобы Миранда и Вайн был под x32 настраиваетс... текст свёрнут, показать
     

  • 1.3, x3who (?), 21:44, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Почитал mdbx.h, просто грустно во что превратился язык ц++

      /// \brief Returns the number of bytes.
      MDBX_NOTHROW_PURE_FUNCTION MDBX_CXX20_CONSTEXPR size_t size() const noexcept {
        return length();
      }

    Сколько лишних букв! Программирование ради программирования кокое-то :-/

     
     
  • 2.4, Аноним (4), 21:46, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    просто имя у функции длинное
     
  • 2.5, Аноним (5), 21:56, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    как будто до "превращения" ц++ в нем и в ц таких конструкций никто не делал
     
     
  • 3.6, IRASoldier_registered (ok), 22:52, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нормальная конструкция. Зато не надо писать лишних комментариев.
     
     
  • 4.11, x3who (?), 00:07, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен в общем случае.. но тут враппер тупой. пролог хидера ввобще жжет напалмом - там и проверки на микрософтовский mad конпелятор, и объявления для специфической системы документировпния кода. Собственно функцонал занимает меньше чем все эти приседания.
     
     
  • 5.21, IRASoldier_registered (ok), 02:00, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А чем плоха амальгамация?

     
  • 4.26, Аноним (26), 09:46, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    я вроде не говорил, что ненормальная. А как помогут комментарии с танцами вокруг разных версий разных компиляторов с разными хаками?
     
  • 2.8, Аноним (8), 23:06, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну в любом активно развивающимся языке с достаточной историей будут новые фичи к... большой текст свёрнут, показать
     
     
  • 3.12, x3who (?), 00:10, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если будешь писать библиотеку, тебя никто так делать не заставляет - ставь в требования C++20 и юзай последние фичи без макросового говна.

    Вообще у них так и сделано - только Ц++11

     
  • 2.31, Аноним (31), 12:14, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тут дело не в языке, а в количестве компиляторов и их версий и желании разработчиков поддерживать продукт для большого количества платформ.
    Фактически тут все идентификаторы в верхнем регистре - это макроподставновки препроцессора, которые определены где-то выше и имеют значения в зависимости от выбранного компилятора для сборки

    По факту это можно для типовых современных компиляторов заменить на :
    constexpr size_t size() const noexcept {
      return length ();
    }

     

  • 1.7, Аноним (7), 22:59, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Почему релизы теперь опять на GitHubе и куда же подевались ваши позиция и принципиальность? Вопрос - риторический, можете не отвечать ;)
     
     
  • 2.10, erthink (ok), 23:56, 30/09/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "теперь опять" см. последнюю строчку readme.
     
     
  • 3.13, x3who (?), 00:17, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  см. последнюю строчку readme

    Я вот лично до последней строчки не добрался, плюнул читать дальше на этом месте: "The next version is under active non-public development from scratch and will be released as MithrilDB"

     
     
  • 4.20, erthink (ok), 01:58, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Исходный код LMDB - изначально ребус (гляньте https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c), а многие около-архитектурные решения там сделаны по принципу "ХХивП".

    Поэтому кроме как "from scratch" пути нет, при этом также снимается вопрос с "не-своей" лицензией и появляется возможность избавиться от многих проблем/слабостей (что впрочем требует неслабого research-а).

    А допиливание libmdbx - это потому что "мы в ответе за тех, кого приручили", в том числе для актуального production.

     
     
  • 5.33, Аноним (33), 15:51, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Исходный код LMDB - изначально ребус, а многие около-архитектурные решения там сделаны по принципу "ХХивП".

    Надо эту цитату вставлять в каждую новость про LMDB. Сразу отпадёт много вопросов.

     
  • 5.36, _ (??), 21:38, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ревьюверы кода LMDB иного мнения: "impressive codebase", "the implementation is really quite brilliant".
     
     
  • 6.39, mos87 (ok), 00:48, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Формулировки похожи на то как бы описывал своё творение Говард
     
  • 3.25, Аноним (7), 09:10, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >This is a mirror

    Да и не совсем это "зеркало". Потому что вы создаёте issue на баг-трекере этого проекта в GitHub, и вообще им пользуетесь, потому что если закрыть баг-трекер на GitHub, как обычно делают, если github - всего лишь зеркало, то на росоподелку никто не пойдёт регаться.


    Учитывая
    >  1 contribution in private repositories Oct 1
    > 189 contributions in private repositories Sep 1 – Sep 30

    очень не похоже на бойкотирование GitHub.


    P.S. Зачем такое в ReadMe пихать? В таком случае, если тот же исходник засунуть на "оригинал", то сообщение будет не очень верно.

     
  • 3.32, andy (??), 15:51, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Поглядел. Крым не российский, да. Какие проблемы-то?
     

  • 1.9, erthink (ok), 23:51, 30/09/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Как-то кто-то просил сравнить производительность libmdbx, LMDB и sqlite Для это... большой текст свёрнут, показать
     
     
  • 2.14, x3who (?), 00:25, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Были случаи использования этого в микроконтроллерах? Ну там дейталоггеры какие-нибудь? В таких применениях производительность критична даже не потому, что это время, а потому, что это микроватты-милли-ватты, от которых зависит самый дорогой на Земле ресурс - батарейка, или самый дорргой в космосе - охлаждение.
     
     
  • 3.15, erthink (ok), 00:40, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Половина (связанных с производительностью) бонусов libmdbx происходит от отображения файла БД в память и последующего совместного использования несколькими процессами. Такие сценарии достаточно далеки от среднего микроконтроллера, у большинства из которых нет MMU.

    Тем не менее, если взять некий "микроконтроллер" где работает buildroot, то (скорее всего) libmdbx будет там работать. Но мне о таких запусках ничего не известно, и в целом "СУБД" и "микроконтроллер" не выглядят рациональной парой.

     
     
  • 4.16, x3who (?), 00:50, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это для чтения, писатель, как я понимаю, там предполагается один. Или в варианте с ограниченной RAM выигрыш в производятельно
    сти пропадает?
     
     
  • 5.17, erthink (ok), 01:01, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это для чтения, писатель, как я понимаю, там предполагается один. Или в
    > варианте с ограниченной RAM выигрыш в производятельно
    > сти пропадает?

    Если ОЗУ мало, то БД просто некуда mmap-ить.
    Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
    И это при условии что есть MMU для управления виртуальной памятью.

    Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит от ОС, включая наличие/отсутствие unified page cache).

    Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только некий минимум для загрузки и обновления прошивки на флешке.

     
     
  • 6.42, x3who (?), 01:13, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это для чтения, писатель, как я понимаю, там предполагается один. Или в
    >> варианте с ограниченной RAM выигрыш в производятельно
    >> сти пропадает?
    > Если ОЗУ мало, то БД просто некуда mmap-ить.
    > Т.е. если ОЗУ недостаточно, то будут постоянные page faults.
    > И это при условии что есть MMU для управления виртуальной памятью.
    > Если же ОЗУ достаточно, то будет работать и без MMU (собственно зависит
    > от ОС, включая наличие/отсутствие unified page cache).
    > Но в половине микроконтроллеров вообще нет "дисков" и полноценной файловой системы, только
    > некий минимум для загрузки и обновления прошивки на флешке.

    Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски не знает, как и персональный компъютер или мобилка или сервер какой. Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту БД к логгингу, и если можно - то какие требования к железу.

     
     
  • 7.44, erthink (ok), 15:19, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Диск - это абстракция более высокого уровня. Сам микроконтроллер ничего про диски
    > не знает, как и персональный компъютер или мобилка или сервер какой.
    > Но у людей регулярно встречаются задачи записывать куда-то какую-то структурированную
    > информацию. Поэтому логично возникает вопрос - а нельзя ли присобачить эту
    > БД к логгингу, и если можно - то какие требования к
    > железу.

    Чтобы использовать libmdbx как есть, без каких-либо доработок, то от системы требуется поддержка mmap() и PTHREAD_MUTEX_ROBUST. Проще говоря, если на микроконтроллере есть MMU и можно запустить linux (buildroot и т.п.).

    При необходимости, конечно, можно портировать libmdbx на более слабые платформы, в том числе на "голое железо". Требуется не так уж много (32-битный процессор, мегабайт ОЗУ и блочный обмен с "диском"). Грубо говоря, достаточно реализовать соответствующие функции libc.

     
     
  • 8.46, x3who (?), 01:49, 04/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не, мегабайт жирновато для _микро_-контроллера Но вообще код интересный, наш... текст свёрнут, показать
     
  • 4.48, n80 (?), 03:19, 04/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    offtop/2: если что, в sqlite3 есть PRAGMA mmap_size=x. Насколько помню, по умолчанию там 0, т.е. mmap не используется. Как-то раз удавалось за счёт включения этой настройки немного ускорить существующую базу. В репозитории ioarena не нашёл упоминания mmap_size, т.е. возможно что этот момент был упущен.
     
     
  • 5.50, erthink (ok), 15:09, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    mmap в sqlite будет немного ускорять чтение, за счет потенциального расширения ... большой текст свёрнут, показать
     
     
  • 6.51, n80 (?), 15:16, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    О как. У меня было по большей части чтение, поэтому и получилось некоторое ускорение.

    Понятно, что специализированное хранилище в разы быстрее, но было интересно понять, насколько удалось выжать всё из sqlite3 (и не только понять, какие опции используются, но и почему). Опять же, момент с замедлением записи при включении mmap оказался неожиданностью.

    Премного благодарю за информацию!

     
     
  • 7.52, erthink (ok), 17:59, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На всякий, для информации 1 Заметил что при 25M итераций размер БД в sqlite по... большой текст свёрнут, показать
     
  • 2.18, Аноним (18), 01:18, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там разница идёт на порядки в зависимости от объёма данных, собственно, потому они и существуют. Некорректно так сравнивать -- они не универсальны.
     
     
  • 3.19, erthink (ok), 01:43, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Там разница идёт на порядки в зависимости от объёма данных, собственно, потому
    > они и существуют. Некорректно так сравнивать -- они не универсальны.

    Не совсем понятно что именно вы хотели сказать в контексте бенчмарков ioarena. Поэтому я дам некоторые пояснения:

    1) Разницы "на порядки в зависимости от объёма данных" не будет, поскольку и libmdbx и sqlite основываются на B-Tree (в обоих случаях зависимость логарифмическая). Но разница будет в тех сценариях, где будет "играть" наличие WAL в sqlite и отсутствие WAL в libmdbx.

    2) Сравнивать libmdbx (встраиваемый key-value) и sqlite (встраиваемый sql) конечно некорректно, но всё-таки (если сильно хочется) можно сравнить некоторое подмножество сценариев (эмулировать key-value средствами sql). Что и было сделано.

    3) Конечно, корректнее было-бы сравнивать sqlite с https://github.com/PositiveTechnologies/libfpta (где есть "таблички" и вторичные индексы реализованные поверх libmdbx), но готовых инструментов для этого сейчас нет, а зная внутреннее устройство, я могу поспорить что соотношений производительности сохранится.

     
     
  • 4.22, Аноним (18), 02:46, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В контексте данного бенчмарка в наличии key size и value size, и, если я правильно предполагаю их назначение, они будут влиять на результат и WAL тут ни при чём. Это не универсальные дб, все они разрабатываются с оптимизацией под определённые кейсы.
     
     
  • 5.23, erthink (ok), 03:17, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    1) Пока размеры будут "в пределах разумного", существенно разницы не будет.

    2) При длинных значениях sqlite будет проигрывать сильнее из-за больших накладных расходах. А libmdbx будет "огурцом" и при гигабайтных размерах, лишь-бы памяти хватило.

    3) С длинными ключами несколько сложнее.

    - В libmdbx есть ограничения на максимальную длину ключа, которое зависит от размера страницы. Проще говоря, libmdbx не предусматривает поддержку длинных ключей, из-за которых сильно деградирует производительность.

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


    Таким образом, libmdbx будет быстрее (думаю, в обозначенных пропорциях или лучше) пока размеры ключей и данных будут в поддерживаемых пределах.
    А если эти пределы будут превышены, то сравнивать sqlite по скорости уже будет как-бы не с чем.

     
  • 2.41, phprus (ok), 20:47, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Скажите, пожалуйста, а насколько хорошо libmdbx подойдет для хранения счетчиков, если данные - это ключ 16 байт и счетчик, которому надо делать инкремент/декремент и удаление? Время жизни отдельного ключа небольшое (от секунд до часов и порядка десятков операций ++/--, но редко бывают и десятки тысяч операций). Одновременно существующих ключей/счетчиков - тысячи, редко десятки тысяч. Вероятность конкурентных операций на один ключ мала. Пожелание - не пухнуть базой, те иметь предсказуемое ограничение на размер файлов на диске сверху.

    Или может быть вы можете порекомендовать что-то другое готовое для хранения короткоживущих счетчиков?

     
     
  • 3.43, erthink (ok), 14:54, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для короткоживущих данных, как правило, лучше подходят БД на основе LSM (https://ru.wikipedia.org/wiki/LSM-п╢п╣я─п╣п╡п╬).
    Бонус там в том, что при слиянии внутри LSM удаление данных почти бесплатно.
    Вам стоит попробовать/посмотреть на tarantool и rocksdb.

    Однако, однозначного универсального ответа нет. В конкретных случаях отдельные нюансы могут сделать использование LSM не рациональным или невозможным. В частности, реальная эффективность LSM непосредственно зависит от того насколько хорошо в конкретной ОС и конкретной файловой системе работает APPEND режим для файлов. Т.е. в вашем случае, при использовании LSM, скорее всего всё будет хорошо в Linux, а в Windows может быть значительно хуже.

    Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный доступ и какова пропорция по объему операций чтения и записи.

    Если много операций чтения или нужен доступ к БД из нескольких процессов, то libmdbx однозначно выиграет - не будет НИКАКИХ накладных расходов.

    Если в основном будут операции изменения данных и нужны транзакции, то (думаю) лучше взять tarantool.


    Если не важна стабильность по времени выполнения отдельных операций и не важны транзакции, то rockdb.

    И т.д., таких "если" наберется еще пара десятков.

     
     
  • 4.45, phprus (ok), 17:06, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ответ!
    Буду тестировать.

    > Далее, принципиально важно насколько вам нужны транзакции, многопроцессорный/многопоточный
    > доступ и какова пропорция по объему операций чтения и записи.

    Чтение/запись почти одинаково с маленьким перевесом чтения. Так как это счетчики, то транзакции нужны (отдельные операции в основном имеют вид: прочитали, изменили значение, записали значение или удалили ключ).
    Многопоточный доступ и на чтение, и на изменение нужен.

     

  • 1.24, Андрей (??), 04:34, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Для оперативной поддержки и ответов на вопросы создана открытая группа в Телеграм.

    Оперативно? Вроде же, люди не любят регистрироваться. А там даже зарегистрироваться-то нельзя. Номер телефон требует и нет опции "пропустить". Не попасть в этот телеграм. Вообще.

     
     
  • 2.29, erthink (ok), 11:20, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    /trolling mode on

    Для перехода на Миранду осталось переписать её на Rust и сделать переносимой (отвязать от Windows).

    /trolling mode off

     
     
  • 3.30, llolik (ok), 11:51, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и сделать переносимой (отвязать от Windows).

    Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к. GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).

     
     
  • 4.37, мяя (?), 22:28, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> и сделать переносимой (отвязать от Windows).
    > Там же голимый WinAPI вроде используют во всех местах. ИМХО проще переписать
    > совсем начисто сохранив архитектуру, чем пытаться там что-то портировать. Ну или
    > писать колоссальный OSAL (в том числе и над каким-нибудь GTK/Qt/Wx, т.к.
    > GUI там тоже ЕМНИП свой мини-фреймворк над WinAPI).

    Ядро уже собирается на Linux насколько я знаю. А винапи там по большей части только в GUI у плагинов. Со временем отвяжут его и всё будет работать везде.

     
  • 4.47, n80 (?), 03:04, 04/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    FYI: как-то я встречал /похожий/ OSAL, называется WinPR и используется в FreeRDP (замена rdesktop). Ну и libwine, куда ж без него. Вроде, что-то ещё вспоминается, но уже более смутно.
     

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



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

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