The OpenNET Project / Index page

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



"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10.4 и libfpta 0.3.9"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск высокопроизводительной встраиваемой СУБД 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.dev/opennews/art.shtml?num=55949

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. Скрыто модератором  –4 +/
Сообщение от Аноним (1), 11-Окт-21, 20:54 
Ответить | Правка | Наверх | Cообщить модератору

4. Скрыто модератором  +2 +/
Сообщение от Enamel (ok), 11-Окт-21, 21:11 
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  +1 +/
Сообщение от Аноним (7), 11-Окт-21, 21:23 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. Скрыто модератором  –5 +/
Сообщение от Аноним (7), 11-Окт-21, 21:09 
Ответить | Правка | Наверх | Cообщить модератору

5. Скрыто модератором  +1 +/
Сообщение от Аноним (5), 11-Окт-21, 21:14 
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 21:21 
Ответить | Правка | Наверх | Cообщить модератору

8. Скрыто модератором  +/
Сообщение от Аноним (5), 11-Окт-21, 21:26 
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  –1 +/
Сообщение от Аноним (7), 11-Окт-21, 21:31 
Ответить | Правка | Наверх | Cообщить модератору

17. Скрыто модератором  +1 +/
Сообщение от pansa3 (?), 11-Окт-21, 22:09 
Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором  +1 +/
Сообщение от Аноним (7), 11-Окт-21, 22:15 
Ответить | Правка | Наверх | Cообщить модератору

14. Скрыто модератором  +/
Сообщение от еуые (?), 11-Окт-21, 22:04 
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

16. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 22:08 
Ответить | Правка | Наверх | Cообщить модератору

55. Скрыто модератором  +/
Сообщение от n00by (ok), 12-Окт-21, 09:50 
Ответить | Правка | Наверх | Cообщить модератору

25. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 22:28 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

9. Скрыто модератором  +1 +/
Сообщение от Аноним (7), 11-Окт-21, 21:27 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

11. Скрыто модератором  –1 +/
Сообщение от QwertyReg (ok), 11-Окт-21, 21:59 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

15. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 22:05 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  +/
Сообщение от kusb (?), 11-Окт-21, 22:04 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

19. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 22:13 
Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором  +2 +/
Сообщение от Аноним (27), 11-Окт-21, 22:44 
Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором  –1 +/
Сообщение от Аноним (7), 11-Окт-21, 22:58 
Ответить | Правка | Наверх | Cообщить модератору

35. Скрыто модератором  +/
Сообщение от erthink (ok), 11-Окт-21, 23:39 
Ответить | Правка | Наверх | Cообщить модератору

45. Скрыто модератором  +/
Сообщение от kusb (?), 12-Окт-21, 07:45 
Ответить | Правка | Наверх | Cообщить модератору

28. Скрыто модератором  +/
Сообщение от Аноним (28), 11-Окт-21, 22:46 
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

31. Скрыто модератором  +/
Сообщение от Аноним (7), 11-Окт-21, 23:02 
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от erthink (ok), 11-Окт-21, 22:11 
Ща поищу :)
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +4 +/
Сообщение от erthink (ok), 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

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  –2 +/
Сообщение от 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.

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

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

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


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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от Аноним (77), 27-Окт-21, 14:33 
вы что-то имеете против масок?
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

29. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от Аноним (29), 11-Окт-21, 22:53 
Про ReOpenLdap новостей нет?
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +1 +/
Сообщение от Аноним (29), 12-Окт-21, 00:51 
Спасибо.
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от mos87 (ok), 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, чтобы не разбираться.
По правде может это и не столь плохо, ибо никого высоконагруза так-то нет, просто данных иерархических много...

Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +1 +/
Сообщение от Виталий (??), 12-Окт-21, 00:28 
А кто может сказать какая область применения ее?
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +1 +/
Сообщение от Аноним (1), 12-Окт-21, 02:12 
Btrfs все так же теряет данные))) сколько лет прошло
Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  –1 +/
Сообщение от Аноним (42), 12-Окт-21, 04:37 
Истину глаголишь
Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +1 +/
Сообщение от Аноним (44), 12-Окт-21, 07:32 
может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value с multimap но все данные переменной длины? Из доки не понятно, в примере только фиксированный размер..
Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от Аноним (44), 12-Окт-21, 07:53 
и может ли value превышать размер страницы?
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от Аноним (44), 12-Окт-21, 08:56 
спасибо, но этого маловато будет, да и вложенных баз вроде 32к только
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

---

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

62. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +/
Сообщение от Аноним (44), 12-Окт-21, 11:11 
та не, этот счетчик лишний, не сильно думал. Тут баланс надо искать не очевидный, для достаточного числа ключей на страницу и не слишком мелкие чанки. Если припрет в крайнем случае наверно бенчмарк сделать, оценить размер чанка, скорость, компактность
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..."  +1 +/
Сообщение от data man (ok), 17-Окт-21, 15:07 
Спасибо!
А MithrilDB уже скоро? :)
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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