| 1.21, pashev.me (?), 22:16, 11/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> превосходит своего прародителя по надёжности, набору возможностей и производительности
В наше время за такое сразу в нос. Где пруфы?
| | |
| |
| |
| 3.34, pashev.me (?), 23:39, 11/10/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
По первому пункту - только воздух сотрясать:
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.
По второму: как часто падало? А теперь?
Пл третьему - вообще субъективно, кому что нужно.
Итого: профов нет, есть подлог.
Нас, после рекомендации ВОЗ по маскам, не проведёшь!
| | |
| |
| 4.36, erthink (ok), 23:42, 11/10/2021 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Всё четко, ясно и понятно.
А с вашей демагогией - в лес, пожалуйста.
| | |
|
|
|
| |
| 2.33, erthink (ok), 23:35, 11/10/2021 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Про ReOpenLdap новостей нет?
Нет, и видимо уже не будет.
Софтверное решение, которое работало с использованием ReOpenLDAP внутри МегаФона, примерно в 2017 было заменено на tarantool (что архитектурно правильно).
Со своей стороны я поддерживал subj еще три года, но постепенно это потеряло смысл:
- не было явно заинтересованных пользователей.
- сам я не пользуюсь ReOpenLDAP и не использую в production, поэтому разработка и тестирование стали сильно отнимать время.
- для принципиального повышения качества и поддерживаемости его нужно переписать (собственно я всегда это говорил).
Если кому-то нужен LDAP-сервер с мульти-мастер репликацией, то "стюардессу" можно реанимировать.
Ну а "родительский" OpenLDAP лучше вообще не использовать, тем более в режиме мульти-мастер репликации.
| | |
| |
| 3.43, mos87 (ok), 06:53, 12/10/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Ясно.
Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить? Как там вообще с созданием собственных схем, а так же их изменением "на лету"?
Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно в форме файлов, обычно XMLек (но чем меньше работы с этим чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).
| | |
| |
| 4.49, erthink (ok), 08:40, 12/10/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ясно.
> Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать
> с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль
> перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему
> прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить?
> Как там вообще с созданием собственных схем, а так же их
> изменением "на лету"?
> Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно
> в форме файлов, обычно XMLек (но чем меньше работы с этим
> чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать).
Схемы в LDAP достаточно просты - по сути два списка: что может быть и что должно быть.
Менять их "на лету", если где-то и можно, то только так, чтобы не было конфликтов с уже записанными данными (т.е. примерно только добавлять список необязательных атрибутов).
Во всех LDAP-ах внутри линейная схема хранения, т.е. для каждого элемента формируется ключ по его пути в иерархии.
Если вы представляете как эффективно сделать такой маппинг в вашем случае, то вероятно сможете реализовать необходимое поверх любого более-менее приличного key-value (я бы взял libfpta, либо тарантул).
| | |
| |
| 5.51, mos87 (ok), 09:00, 12/10/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Спасибо.
SQL СУБД предоставляет определённые привычные возможности, но хочется применять её не как единое монструозное решение для всего (в принципе там и XML хранить можно), а для чего наиболее подходит.
Но я просто не работал со всеми этими тарантулами, монгами, и редисками (как кстати первый по сравн. с последними?).
Насколько сложно выстроить свою БД на них, куда бы мы складывали входящие данные, хранили расчётные, а для аналитики и отчетов сливали в SQL?
С правами доступа и т.д. Почему в сторону LDAP сначала посмотрел, там это уже всё есть (включая формат обмена данными). Даже слишком много всего. Или плюнуть на использование LDAP в таком контексте? SQL конечно гибче в плане прихотей типа "поменять тип столбца, добавить, переименовать"...
| | |
| |
| 6.59, erthink (ok), 10:13, 12/10/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то отсутствующее в тарантуле.
Но с учетом всех возможностей тарантула я бы на редиску даже не смотрел.
Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил" и SQL.
Но если аналитики много, то clickhouse.
Более-менее гибкие права доступа есть только в SQL.
В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики приложения, хотя всегда есть исключения...
LDAP для другого - это прежде всего справочник пользователей, который редко меняется и много читается.
Но относительно подходит, так как в принципе это key-value ("путь в иерархии" -> "набор атрибутов").
Причем чем больше вам подходит key-value, тем больше подходит и LDAP.
Сам бы я не смотрел на LDAP при наличие тарантула, с одним исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация) без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно как replay транзакций).
Думаю вам надо пробовать - потратить неделю на тарантул.
Принципиально более полного ответа вам никто не даст, только вы сами.
| | |
| |
| 7.64, mos87 (ok), 14:04, 12/10/2021 [^] [^^] [^^^] [ответить] | +/– | Думаю как раз суперпродвинутые и не нужны будут Хотя я теперь понял что все эти... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 1.44, Аноним (44), 07:32, 12/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value с multimap но все данные переменной длины? Из доки не понятно, в примере только фиксированный размер..
| | |
| |
| |
| |
| 4.50, Аноним (44), 08:56, 12/10/2021 [^] [^^] [^^^] [ответить]
| +/– |
спасибо, но этого маловато будет, да и вложенных баз вроде 32к только
| | |
| |
| 5.52, erthink (ok), 09:16, 12/10/2021 [^] [^^] [^^^] [ответить]
| +/– | |
> спасибо, но этого маловато будет, да и вложенных баз вроде 32к только
Вложенные b-tree для значений в multimap создаются автоматически и прозрачно для пользователя, когда одному ключу соответствует много значений.
Кол-во таких вложенных b-tree ограниченно размером БД.
А 32765 - это вложенные именованные key-value пространства, которые вы явно создаете для размещения данных.
Использование термина "subdatabase" сюда пришло из BDB, хотя "space" тарантуле подходит больше.
| | |
| |
| 6.54, Аноним (44), 09:36, 12/10/2021 [^] [^^] [^^^] [ответить]
| +/– |
тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип данных и номер в серии, В+ будет сортировать их всегда последовательно и все эти данные будут привязаны на один ключ, который будет в единственном числе в индексе? все это будет жить? (не хотелось бы кучу одинаковых ключей, ключи нужно уникальные)
| | |
| |
| 7.57, erthink (ok), 09:54, 12/10/2021 [^] [^^] [^^^] [ответить]
| +/– |
> тоесть получается, если данные порезать на чанки в полстраницы с префиксом: тип
> данных и номер в серии, В+ будет сортировать их всегда последовательно
> и все эти данные будут привязаны на один ключ, который будет
> в единственном числе в индексе? все это будет жить? (не хотелось
> бы кучу одинаковых ключей, ключи нужно уникальные)
Да, будет жить.
И то что ключ будет в одном экземпляре для миллионов значений - является одной из важных фишек для построения вторичных индексов.
---
В LMDB теоретически это тоже должно работать, но практически - длина ключей сильно меньше, а если попробовать изменить #define в коде, то LMDB может тихо потерять данные и/или поломать БД.
MDBX же либо не примет слишком длинные значения, либо будет работать корректно.
Но увлекаться ключами (для multimap также и значениями) предельной длины не стоит, ибо эффективность b-tree при этом существенно ниже.
| | |
| |
| 8.58, Аноним (44), 10:08, 12/10/2021 [^] [^^] [^^^] [ответить] | +/– | напрашивается ввести переменную в options, если она отлична от 0, в data дереве ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.48, erthink (ok), 08:22, 12/10/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> может кто знает? Можно ли использовать для задачи: ключ фиксированного размера, value
> с multimap но все данные переменной длины? Из доки не понятно,
> в примере только фиксированный размер..
Да, так можно.
| | |
|
| 1.74, data man (ok), 10:21, 17/10/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Недавно в Microsoft/FASTER добавили возможность использования liburing.
Не планируете тоже использовать?
Или профит невелик?
| | |
| |
| 2.75, erthink (ok), 14:28, 17/10/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
В libmdbx файл БД разшарен в памяти, нет выделенного сервера и есть поддержка WRITEMAP:
- в режиме MDBX_WRITEMAP очереди не нужны, данные и так не копируются и ядро само пишет их как удобно.
- без MDBX_WRITEMAP всё равно потребуется копирование в unified page cache, данные которого составляют маппинг файла и могут быть использованы внутри ядра для избавления от лишнего копирования в DMA-буфера.
Поэтому профит примерно только от сокращения системных вызовов pwritev() при коммите транзакций, и только в режиме без MDBX_WRITEMAP.
В текущем понимании это не стоит усложнения кода, риска регрессов и затрат времени.
| | |
|
|
