открывать итератор каждый раз  заново дорого

do 
   box.cfg{ wal_mode = 'none' }
   box.schema.space.create('test'):create_index('pri')
   iter = box.space.test:pairs({1}, { iterator = box.index.GT })
   for i = 1, 5 do box.space.test:replace{i} end
   return iter:totable()
end

да , при любом порядке предыдущиз строк totable выведет все как будто итератор  только здесь объявлен

для gc, наверное, да. На самом деле разницу видно только на очень больших спейсах, типа 100м+. Мы бенчили, не помню точно где прошел трешхолд, но 10к+ это бессмысленно

да хотябы тупо из за того чтобы не создавать его заново, а не про то что индекш широкий и долго искать

он почти 500k/s рандом сиков тащит, на 10М индексе, точно ли стоит оптимизировать (ща чекнул на 1.10.6)?

А есть с кем обсудить желаемое относительно b+tree (GSoC) ?

Даже чуть конкретнее:
- так или иначе я буду делать MithrilDB ("следующую" версию libmdbx);
- поэтому есть смысл понять что хочется видеть в Тарантуле;
- MithrilDB это как-бы переписанная и улучшенная LMDB/MDBX с устранением ряда архитектурных проблем.

+Да, и видимо не-PoC будет на Rust, но решение пока не принято.

ну у вас же опять это будет block-based как в lmdb, в невозможностью эффективной репликации? или вы таки решите эту проблему?

(хотел пригласить в чат со студентами, но потом увидел кто написал)

Про репликацию я как-то уже говорил - буду делать по мотивам RFC-4533 (в 14-16 годах мне пришлось "собаку съесть" по этой теме).
Само RFC достаточно мутное, но вкратце там возможны варианты:
- на основе changelog, т.е. повтор транзакций;
- синхронизация наборов (GUID у каждой ROW);
- fallback с первого на второе, включая полное копирование БД.
+ multi-master с вариантами (репликация в каждом направлении настраивается отдельно, хоть до fullmesh).

При этом движок будет слоеным и репликация будет относительно независима от b+tree.
Можно сказать что MithrilDB будет объединять в себе следующие версии libmdbx + libfptu (линейные кортежи) + libfpta (таблички с колонками и вторичными индексами), c добавлением репликации на уровне libfpta.

интересно! И ведь RFC-4533 это же про LDAP и очевидно к LMDB уже приделана вся эта машинерия? Оно там работает с какими-нибудь гарантиями целостности?
И, самое интересное, как в случае многослойности движков делать транзакции?

RFC-4533 я упомянул только потому, что это (пожалуй) единственное максимально близкое и готовое описание той "репликации", которую я сделаю.
Больше никакого отношения к LDAP это не имеет.

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

Решаются эти проблемы компромиссами/ограничениями и возможностями/фичами движка хранения.
Тут стоит пояснить, что в MithrilDB будут устранены две "Ахилесовы пяты" LMDB/MDBX:
- долгие читающие транзакции не будут приостанавливать сборку мусора (в LMDB/MDBX линейный сборщик мусора, который не может перешагнуть используемый MVCC-снимок).
- огромные пишущие транзакции не будут лихорадить БД (в LMDB/MDBX это проблема, так как требует последовательностей свободных страниц).

Остальные компромиссы/ограничения сводятся к выбору/настройкам:
- для каждого писателя: разрешить/запретить локальные апдейты пока нода не синхронизирована и/или в процессе синхронизации;
- для каждого читателя: выбрать что видеть (упрощенно): синхронизированный MVCC-снимок, не-синхронизированный MVCC-снимок, грязный/неперсистентный MVCC-снимок.

Если опорный движок хранения не умеет MVCC (или имеет какие-то ограничения), то это делает недоступные отдельные координаты на сетке компромиссов.
Как-то так...

Привет! Подскажите, пожалуйста, использую net.box, пытаюсь подключиться на хост под фаерволом. Через опции передаю connect_timeout = 1, в логе вижу (net.box) net_box.lua:1026 W> <host:port>: Connection timed out, но net_box.connect управление не возвращает. Почему так? Выглядит как баг

wait_connected

Спасибо, увидел

подскажите пожалуйста есть мемкеш на тарантуле 1.10
почистить его записи по времени истечения например можно так:

box.space.__mc_sessions:pairs():filter(function(x) return x.expired < 1598811245964110 end):each(function(x) box.space.__mc_sessions:delete(x.key) end)

а вот как удалить записи с определенным префиксом в key?
TestSession_* например?

но не особо быстро

Рац. предложение в ночи. Оставлю здесь, чтобы не забыть (вы спите, спите 😌)
Короче... у многих СУБД есть возможность комментировать почти любые объекты - начиная от самой бд, заканчивая колонками таблиц и функциями. У меня даже документация по БД в postgresql автоматически генерируется в маркдауне по метаданным и комментариям. Вот сейчас полез в базу тарантула и осознал, насколько ценна была бы такая возможность. Кажется, что реализация не должна быть сложной. Это прямо таки недооцененная, наверное, случайно упущенная из виду супер-фича.

есть для doxygen плагин для луа

для луа есть луадок