URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 125492
[ Назад ]

Исходное сообщение
"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10.4 и libfpta 0.3.9"

Отправлено opennews , 11-Окт-21 20:54 
Состоялся выпуск библиотек libmdbx 0.10.4 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение, и связанной библиотеки libfpta 0.3.9 (FPTA), реализующей поверх MDBX табличное представление данных с вторичными и составными индексами. Обе библиотеки распространяются под лицензиями одобренными OSI. Поддерживаются все актуальные операционные системы и архитектуры, включая российский Эльбрус...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=55949


Содержание

Сообщения в этом обсуждении
"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 20:54 
Опять не на расте)

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Enamel , 11-Окт-21 21:11 
Раст стал действительно интересным выбором последние несколько лет, а проект с 2015 развивается.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:23 
Так ржавые биндинги есть!

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:09 
Господа профессионалы в GNU/Linux и им сочувствующие. Нашел тут интересную для  информацию из первоисточника:

Not unlawfully discriminate or knowingly permit unlawful discrimination on the basis of race, national origin, sex, sexual orientation, religion, age or disability in: (1) hiring, promoting, discharging, or otherwise determining the conditions of employment of any person; or (2) accepting or terminating representation of any client.

Перевод для тех, кто не осилил в мову:

• Не допускать дискриминации по признаку расы, национального происхождения, пола, сексуальной ориентации, религии, возраста или инвалидности в: (1) приёме на работу, продвижении по службе, увольнении или ином изменении статуса занятости любого лица; или (2) принятии или прекращении предоставления услуг любому клиенту.


https://docs.linuxfoundation.org/tc-docs/certification/lf-ca...

То есть все те, кто сдает на сертификат и/или собирается, а в какой-то степени и просто пользуется дистрибутивом, должен впустить в себя немного толерантности. И даже если клиент с нетрадиционной ориентацией к вам обратится,  вы обязуетесь его потребности удовлетворить.

Такие дела.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:14 
> И даже если клиент с нетрадиционной ориентацией к вам обратится,  вы обязуетесь его потребности удовлетворить.

А ты нет?


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:21 
Я слава Патрегу не профессионал. Мне можно и на йух послать. :)

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:26 
А чем деньги зарабатываете?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:31 
Силой мысли. Я думал в наш век умных денег - это уже не проблема.
А смотрю соседние треды, так выясняется, что кто-то еще по старинке. И душу и спо и идею за шекель отдают. И даже собственный моральный облик. Печаль.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено pansa3 , 11-Окт-21 22:09 
тов. Милонов перелогиньтесь, вас раскусили. А то джигурдууу позовём!

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:15 
Да меня сегодня тут кто только не пытался покусать)
У милонова есть здесь акк?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено еуые , 11-Окт-21 22:04 
> И даже если клиент с нетрадиционной ориентацией к вам обратится,  вы обязуетесь его потребности удовлетворить.

И как сексуальные предпочтения клиента повлияют на разработку/доработку для него ПО.

Или вы в публичном доме работаете?


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:08 
А где гарантии, что ты не приглянешься заказчику и он не шлепнет тебя скажем по пятой точке? Ну или просто оказывать тебе богомерзкие знаки внимания. А ты по кодексу получается должен стоять и улыбаться. И продолжать выполнять работу.

В публичном доме проще. Там и у жриц оклад почасовой иной раз посолиднее. И отказаться от конкретного клиента они вполнн себе могут. В приличных заведениях.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено n00by , 12-Окт-21 09:50 
А ты не проецируй свой печальный опыт и проблемы на него. Он справится. Это ты ничего не смог сделать с напрашивающимся к тебе в "папики" https://www.opennet.me/~%F3%C5%CD%C5...
то ли предлагаемый сладкий шекель затмил разум, то ли кроме работы языком ничего не умеешь, то ли "Легион" в черепной коробке помешал.
Пришлось за тебя, активиста Rosa Tresh, впрягаться и ставить п-са на место.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:28 
И заметь - это линуес фонд глобальной сертификации. То есть как я понимаю, если ты придешь в рф или любой другой стране получить серт линукс специалиста, ты обязуешься это принять.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:27 
И насколько более лояльно это отражено в аналогичной доке бсдей

https://www.freebsd.org/internal/code-of-conduct/

Да. Вот где истинная свобода!


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено QwertyReg , 11-Окт-21 21:59 
И к чему этот спич? Америку открыли?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:05 
Лично я для себя да. Так чтобы на уровне официального требования при получении сертификата, ака клятвы гиппократа у медиков, я лично узнал сегодня только.

А вот в фрибсд такого нет. Удоляю дженту из дуалбута к такому-то жпл. Раньше думал снести как ядро поржавеет, но нет. Это уже перебор, как по мне.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено kusb , 11-Окт-21 22:04 
erthink/libmdbx
Github/Леонид Юрьев (Leonid Yuriev) erthink
Please don't use my work, if you are associated with Adolf Hitler, Stepan Bandera, George Soros, Michael Hodorkovsky, either support an actions of these felons.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:13 
Намано он так вжарил список. Интересно как он сороса с ходорковским обосновывает)
Если обоснования по кондакту нет, нарушает...

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:44 
А что нарушает? Это просто просьба. Если бы это было требование, противоречащее лицензии, тогда было бы ой.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:58 
Это пока юризды из этих не увидели. Там я уверен найдут как вывернуть просьбу в лютый скандал. Если им это потребуется исесн...

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 11-Окт-21 23:39 
> Это пока юризды из этих не увидели. Там я уверен найдут как
> вывернуть просьбу в лютый скандал. Если им это потребуется исесн...

Не та юрисдикция.

Да, жалобы в github уже писали, но де-факто там не нашли их обоснованными (иначе бы предупредили и/или заблокировали).


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено kusb , 12-Окт-21 07:45 
О, привет. А почему Ходорковский? А по Бандере - он же умер, так наоборот можно поссорить людей, учитывая, что бандеровцами иногда называют совсем не тех и это просто не связанная, но жутко политически нагруженная обзывалка.
Всё-таки война в Украине, этим текстом можно её подстегнуть, а там людей убивают.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:46 
Это линуксфоундешн, там все такие https://www.linuxfoundation.org/join/members/.
но линуксфоундешн != линукс. Это как россия и правительство, например.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 23:02 
Ага. И внезапно и русбиттех в членах))

А сам Линус в ключевых. Мдеее


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 21:59 
>поддерживаемые энтузиастками

фото энтузиасток в студию


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 11-Окт-21 22:11 
Ща поищу :)

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено pashev.me , 11-Окт-21 22:16 
> превосходит своего прародителя по надёжности, набору возможностей и производительности

В наше время за такое сразу в нос. Где пруфы?


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 11-Окт-21 22:26 
1. производительность: git clone libmdbx; git clone ioarena; make bench-couple
https://t.me/libmdbx/2236

2. надежность: В частности, Erigon перешел с LMDB на MDBX, так как падало...
https://github.com/ledgerwatch/erigon/wiki/Criteria-for-tran...

3. набор возможностей: https://github.com/erthink/libmdbx#improvements-beyond-lmdb

Но остальное и в следующий раз, пожалуйста, гуглите самостоятельно.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено pashev.me , 11-Окт-21 23:39 
По первому пункту - только воздух сотрясать:

Some simple benchmark which I done within /dev/shm on an old laptop with an Intel i7-4600U @ fixed 2GHz.

$ make bench-mdbx_25000000.txt
// TIP: Use `make V=1` for verbose.
  RUNNING ioarena for mdbx/25000000...
throughput: 124.021Kops/s
throughput:  13.570Mops/s
throughput:   1.138Mops/s

$ make bench-lmdb_25000000.txt
// TIP: Use `make V=1` for verbose.
  RUNNING ioarena for lmdb/25000000...
throughput: 108.858Kops/s
throughput:  14.758Mops/s
throughput:   1.211Mops/s

So, by this benchmark:

1) libmdbx is ~14% faster than LMDB in CRUD cases.
Such acceleration should be expected in most use cases (without taking into account the waiting time for disk operations).

2) libmdbx is ~8% slower than LMDB when iterating records sequentially.
This is expected, since libmdbx has more checks (for the correctness of arguments and database structure) and in this scenario, these overhead costs become noticeable because the engine performs significantly less other actions.

However, in most real-world scenarios, a difference will most likely be less noticeable, since most of time will taken the waiting for disk operations.

По второму: как часто падало? А теперь?

Пл третьему - вообще субъективно, кому что нужно.

Итого: профов нет, есть подлог.


Нас, после рекомендации ВОЗ по маскам, не проведёшь!


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 11-Окт-21 23:42 
Всё четко, ясно и понятно.

А с вашей демагогией - в лес, пожалуйста.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 27-Окт-21 14:33 
вы что-то имеете против масок?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 11-Окт-21 22:53 
Про ReOpenLdap новостей нет?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 11-Окт-21 23:35 
> Про ReOpenLdap новостей нет?

Нет, и видимо уже не будет.

Софтверное решение, которое работало с использованием ReOpenLDAP внутри МегаФона, примерно в 2017 было заменено на tarantool (что архитектурно правильно).
Со своей стороны я поддерживал subj еще три года, но постепенно это потеряло смысл:
- не было явно заинтересованных пользователей.
- сам я не пользуюсь ReOpenLDAP и не использую в production, поэтому разработка и тестирование стали сильно отнимать время.
- для принципиального повышения качества и поддерживаемости его нужно переписать (собственно я всегда это говорил).

Если кому-то нужен LDAP-сервер с мульти-мастер репликацией, то "стюардессу" можно реанимировать.
Ну а "родительский" OpenLDAP лучше вообще не использовать, тем более в режиме мульти-мастер репликации.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 00:51 
Спасибо.

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено mos87 , 12-Окт-21 06:53 
Ясно.

Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить? Как там вообще с созданием собственных схем, а так же их изменением "на лету"?
Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно в форме файлов, обычно XMLек (но чем меньше работы с этим чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 08:40 
> Ясно.
> Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать
> с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль
> перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему
> прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить?
> Как там вообще с созданием собственных схем, а так же их
> изменением "на лету"?
> Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно
> в форме файлов, обычно XMLек (но чем меньше работы с этим
> чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).

Схемы в LDAP достаточно просты - по сути два списка: что может быть и что должно быть.
Менять их "на лету", если где-то и можно, то только так, чтобы не было конфликтов с уже записанными данными (т.е. примерно только добавлять список необязательных атрибутов).

Во всех LDAP-ах внутри линейная схема хранения, т.е. для каждого элемента формируется ключ по его пути в иерархии.
Если вы представляете как эффективно сделать такой маппинг в вашем случае, то вероятно сможете реализовать необходимое поверх любого более-менее приличного key-value (я бы взял libfpta, либо тарантул).


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено mos87 , 12-Окт-21 09:00 
Спасибо.

SQL СУБД предоставляет определённые привычные возможности, но хочется применять её не как единое монструозное решение для всего (в принципе там и XML хранить можно), а для чего наиболее подходит.

Но я просто не работал со всеми этими тарантулами, монгами, и редисками (как кстати первый по сравн. с последними?).
Насколько сложно выстроить свою БД на них, куда бы мы складывали входящие данные, хранили расчётные, а для аналитики и отчетов сливали в SQL?
С правами доступа и т.д. Почему в сторону LDAP сначала посмотрел, там это уже всё есть (включая формат обмена данными). Даже слишком много всего. Или плюнуть на использование LDAP в таком контексте? SQL конечно гибче в плане прихотей типа "поменять тип столбца, добавить, переименовать"...


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 10:13 
Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то отсутствующее в тарантуле.
Но с учетом всех возможностей тарантула я бы на редиску даже не смотрел.

Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил" и SQL.
Но если аналитики много, то clickhouse.

Более-менее гибкие права доступа есть только в SQL.
В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики приложения, хотя всегда есть исключения...

LDAP для другого - это прежде всего справочник пользователей, который редко меняется и много читается.
Но относительно подходит, так как в принципе это key-value ("путь в иерархии" -> "набор атрибутов").
Причем чем больше вам подходит key-value, тем больше подходит и LDAP.
Сам бы я не смотрел на LDAP при наличие тарантула, с одним исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация) без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно как replay транзакций).

Думаю вам надо пробовать - потратить неделю на тарантул.
Принципиально более полного ответа вам никто не даст, только вы сами.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено mos87 , 12-Окт-21 14:04 
> Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то
> отсутствующее в тарантуле.
> Но с учетом всех возможностей тарантула я бы на редиску даже не
> смотрел.

Думаю как раз суперпродвинутые и не нужны будут. Хотя я теперь понял что все эти редиски про in-memory т.е. для горячих данных которые злым клиентам надо быстро отдавать - у нас такой задачи по большому счёту нет.

> Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил"
> и SQL.
> Но если аналитики много, то clickhouse.

Для аналитики вполне хватает SQL, там в основном отчеты.

> Более-менее гибкие права доступа есть только в SQL.
> В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики
> приложения, хотя всегда есть исключения...

Да, аутентификацию/авторизацию всегда можно возложить на тот же LDAP в приложениях.

> LDAP для другого - это прежде всего справочник пользователей, который редко меняется
> и много читается.

Нет, я знаю, где обычно применяются сервера справочников. Я сам для интереса поднимал openldap с другими службами.
Но знаю, что применяется и как БД (более) общего назначения.

> Но относительно подходит, так как в принципе это key-value ("путь в иерархии"
> -> "набор атрибутов").

Вот на это расчет и есть, что может зайдёт. Опасения именно что привычного из SQL будет не хватать, вроде тех же изменений схемы.

> Причем чем больше вам подходит key-value, тем больше подходит и LDAP.
> Сам бы я не смотрел на LDAP при наличие тарантула, с одним
> исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация)
> без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно
> как replay транзакций).

Дело в том, что у нас нет задачи сделать высоконагруженно-доступно-быстро. И хранить в памяти входящие данные точно не надо.
Мульти-мастер точно не нужен, мастер один в текущей БД (ораклЪ) и менять этот факт ничто не заставляет.

> Думаю вам надо пробовать - потратить неделю на тарантул.
> Принципиально более полного ответа вам никто не даст, только вы сами.

Спасибо, пока это всё даже не планы, а ранние прикидки. Чую, что свалят опять всё в SQL, чтобы не разбираться.
По правде может это и не столь плохо, ибо никого высоконагруза так-то нет, просто данных иерархических много...


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Виталий , 12-Окт-21 00:28 
А кто может сказать какая область применения ее?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 02:12 
Btrfs все так же теряет данные))) сколько лет прошло

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 04:37 
Истину глаголишь

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 07:32 
может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value с multimap но все данные переменной длины? Из доки не понятно, в примере только фиксированный размер..

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 07:53 
и может ли value превышать размер страницы?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 08:22 
> и может ли value превышать размер страницы?

Значения в multimap ограничены по длине примерно половиной страницы (хранятся как ключи во вложенном дереве).

Точные значения = https://github.com/erthink/libmdbx#limitations


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 08:56 
спасибо, но этого маловато будет, да и вложенных баз вроде 32к только

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 09:16 
> спасибо, но этого маловато будет, да и вложенных баз вроде 32к только

Вложенные b-tree для значений в multimap создаются автоматически и прозрачно для пользователя, когда одному ключу соответствует много значений.
Кол-во таких вложенных b-tree ограниченно размером БД.

А 32765 - это вложенные именованные key-value пространства, которые вы явно создаете для размещения данных.
Использование термина "subdatabase" сюда пришло из BDB, хотя "space" тарантуле подходит больше.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 09:36 
тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип данных и номер в серии, В+ будет сортировать их всегда последовательно и все эти данные будут привязаны на один ключ, который будет в единственном числе в индексе? все это будет жить? (не хотелось бы кучу одинаковых ключей, ключи нужно уникальные)

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 09:54 
> тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип
> данных и номер в серии, В+ будет сортировать их всегда последовательно
> и все эти данные будут привязаны на один ключ, который будет
> в единственном числе в индексе? все это будет жить? (не хотелось
> бы кучу одинаковых ключей, ключи нужно уникальные)

Да, будет жить.

И то что ключ будет в одном экземпляре для миллионов значений - является одной из важных фишек для построения вторичных индексов.

---

В LMDB теоретически это тоже должно работать, но практически - длина ключей сильно меньше, а если попробовать изменить #define в коде, то LMDB может тихо потерять данные и/или поломать БД.

MDBX же либо не примет слишком длинные значения, либо будет работать корректно.
Но увлекаться ключами (для multimap также и значениями) предельной длины не стоит, ибо эффективность b-tree при этом существенно ниже.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 10:08 
напрашивается ввести переменную в options, если она отлична от 0, в data дереве сравнивать нужное число байт, тогда деградации не будет

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 10:21 
> напрашивается ввести переменную в options, если она отлична от 0, в data
> дереве сравнивать нужное число байт, тогда деградации не будет

Деградация не из-за сравнений, а из-за роста высоты b-tree (и как следствие) многократное хранение значений ключей и увеличение размера индексной части b-tree (branch-страниц), т.е. увеличение размера БД больше чем линейно от размера данных.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 10:32 
А "нужно" кол-во байт можно сравнивать уже сейчас, задав собственный компаратор для ключей и/или значений.

Однако, использование таких "кастомных компараторов" не рекомендуется, ибо структуру такой БД невозможно полностью проверить отдельной утилитой mdbx_chk (ибо не будет доступа к пользовательским функциям сравнения).


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено Аноним , 12-Окт-21 11:11 
та не, этот счетчик лишний, не сильно думал. Тут баланс надо искать не очевидный, для достаточного числа ключей на страницу и не слишком мелкие чанки. Если припрет в крайнем случае наверно бенчмарк сделать, оценить размер чанка, скорость, компактность

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 12-Окт-21 08:22 
> может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value
> с multimap но все данные переменной длины? Из доки не понятно,
> в примере только фиксированный размер..

Да, так можно.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено data man , 17-Окт-21 10:21 
Недавно в Microsoft/FASTER добавили возможность использования liburing.
Не планируете тоже использовать?
Или профит невелик?

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено erthink , 17-Окт-21 14:28 
В libmdbx файл БД разшарен в памяти, нет выделенного сервера и есть поддержка WRITEMAP:
- в режиме MDBX_WRITEMAP очереди не нужны, данные и так не копируются и ядро само пишет их как удобно.
- без MDBX_WRITEMAP всё равно потребуется копирование в unified page cache, данные которого составляют маппинг файла и могут быть использованы внутри ядра для избавления от лишнего копирования в DMA-буфера.

Поэтому профит примерно только от сокращения системных вызовов pwritev() при коммите транзакций, и только в режиме без MDBX_WRITEMAP.
В текущем понимании это не стоит усложнения кода, риска регрессов и затрат времени.


"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."
Отправлено data man , 17-Окт-21 15:07 
Спасибо!
А MithrilDB уже скоро? :)