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

Question

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

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

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

#database #programming #russian #software #tarantool

0

26.03.2021

5 ответов

20 просмотров

Леонид Юрьев (Leonid Yuriev) Автор вопроса

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

0

26.03.2021

Timur Safin

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

0

26.03.2021

Леонид Юрьев (Leonid Yuriev) Автор вопроса

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

0

26.03.2021

Леонид Юрьев (Leonid Yuriev) Автор вопроса

Up с небольшими добавлениями: - выше была пара вопросов от @tsafin и мои ответы. - дальше обсуждать можно в https://t.me/libmdbx, либо в личке. - забыл упомянуть, что в MithrilDB обязательно будет Merkle tree, соответственно также неплохо будет работать по-страничная репликация (должно быть лучше чем в PG).

0

30.03.2021

Timur Safin · Accepted Answer

Timur Safin

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

0

26.03.2021

215 похожих чатов

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

5 ответов

Похожие вопросы