https://opennet.ru/openforum/vsluhforumID3/125492.html Состоялся выпуск библиотек libmdbx 0.10.4 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение, и связанной библиотеки libfpta 0.3.9 (FPTA), реализующей поверх MDBX табличное представление данных с вторичными и составными индексами. Обе библиотеки распространяются под лицензиями одобренными OSI. Поддерживаются все актуальные операционные системы и архитектуры, включая российский Эльбрус...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55949<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#77 Wed, 27 Oct 2021 11:33:33 GMT вы что-то имеете против масок?<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#76 Sun, 17 Oct 2021 12:07:00 GMT Спасибо!<br>А MithrilDB уже скоро? :)<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#75 Sun, 17 Oct 2021 11:28:30 GMT В libmdbx файл БД разшарен в памяти, нет выделенного сервера и есть поддержка WRITEMAP:<br> - в режиме MDBX_WRITEMAP очереди не нужны, данные и так не копируются и ядро само пишет их как удобно.<br> - без MDBX_WRITEMAP всё равно потребуется копирование в unified page cache, данные которого составляют маппинг файла и могут быть использованы внутри ядра для избавления от лишнего копирования в DMA-буфера.<br><br>Поэтому профит примерно только от сокращения системных вызовов pwritev() при коммите транзакций, и только в режиме без MDBX_WRITEMAP.<br>В текущем понимании это не стоит усложнения кода, риска регрессов и затрат времени.<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#74 Sun, 17 Oct 2021 07:21:53 GMT Недавно в Microsoft/FASTER добавили возможность использования liburing.<br>Не планируете тоже использовать?<br>Или профит невелик?<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#64 Tue, 12 Oct 2021 11:04:01 GMT &gt; Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то <br>&gt; отсутствующее в тарантуле.<br>&gt; Но с учетом всех возможностей тарантула я бы на редиску даже не <br>&gt; смотрел.<br><br>Думаю как раз суперпродвинутые и не нужны будут. Хотя я теперь понял что все эти редиски про in-memory т.е. для горячих данных которые злым клиентам надо быстро отдавать - у нас такой задачи по большому счёту нет.<br><br>&gt; Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил" <br>&gt; и SQL.<br>&gt; Но если аналитики много, то clickhouse.<br><br>Для аналитики вполне хватает SQL, там в основном отчеты.<br><br>&gt; Более-менее гибкие права доступа есть только в SQL.<br>&gt; В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики <br>&gt; приложения, хотя всегда есть исключения...<br><br>Да, аутентификацию/авторизацию всегда можно возложить на тот же LDAP в приложениях.<br><br>&gt; LDAP для другого - это прежде всего справочник пользователей, который редко меняется <br>&gt; и много читается.<br><br>Нет, я знаю, где обычно применяются сервера https://opennet.ru/openforum/vsluhforumID3/125492.html#62 Tue, 12 Oct 2021 08:11:22 GMT та не, этот счетчик лишний, не сильно думал. Тут баланс надо искать не очевидный, для достаточного числа ключей на страницу и не слишком мелкие чанки. Если припрет в крайнем случае наверно бенчмарк сделать, оценить размер чанка, скорость, компактность <br> https://opennet.ru/openforum/vsluhforumID3/125492.html#61 Tue, 12 Oct 2021 07:32:40 GMT А "нужно" кол-во байт можно сравнивать уже сейчас, задав собственный компаратор для ключей и/или значений.<br><br>Однако, использование таких "кастомных компараторов" не рекомендуется, ибо структуру такой БД невозможно полностью проверить отдельной утилитой mdbx_chk (ибо не будет доступа к пользовательским функциям сравнения).<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#60 Tue, 12 Oct 2021 07:21:57 GMT &gt; напрашивается ввести переменную в options, если она отлична от 0, в data <br>&gt; дереве сравнивать нужное число байт, тогда деградации не будет <br><br>Деградация не из-за сравнений, а из-за роста высоты b-tree (и как следствие) многократное хранение значений ключей и увеличение размера индексной части b-tree (branch-страниц), т.е. увеличение размера БД больше чем линейно от размера данных.<br> https://opennet.ru/openforum/vsluhforumID3/125492.html#59 Tue, 12 Oct 2021 07:13:17 GMT Redis vs Tarantool - если поискать, то наверное у "редиски" есть что-то отсутствующее в тарантуле.<br>Но с учетом всех возможностей тарантула я бы на редиску даже не смотрел.<br><br>Скорее всего ваша задача полностью решается в тарантуле, ибо там есть "винил" и SQL.<br>Но если аналитики много, то clickhouse.<br><br>Более-менее гибкие права доступа есть только в SQL.<br>В мире NoSQL это не затребовано и (как-правило) реализуется на уровне логики приложения, хотя всегда есть исключения...<br><br>LDAP для другого - это прежде всего справочник пользователей, который редко меняется и много читается.<br>Но относительно подходит, так как в принципе это key-value ("путь в иерархии" -&gt; "набор атрибутов").<br>Причем чем больше вам подходит key-value, тем больше подходит и LDAP.<br>Сам бы я не смотрел на LDAP при наличие тарантула, с одним исключением - для LDAP возможна мульти-мастер синхронизация содержимого (aka репликация) без привязки к линейной истории транзакций, а таратнуле наоборот (репликация примерно как replay транзакций).<br><br>Думаю