Ephemeral vs temporary vs local spaces

Для фичи compare and swap нужны т.н. эфемерные спейсы — это такие спейсы, которые существуют как объект в памяти, но не оставляют следов ни в системных спейсах ни в репликации. Они немного похожи на темпорари спейсы, только без имени и без айдишника, и даже факт их создания нигде не персистится (в отличие от темпорари).

https://docs.google.com/document/d/14LfBp98Kdz4WlpzYxV9DqrMaIa_LfZL-VVQZQwwHx7I

В CaS эфемерные спейсы нужны для реализации "лимба" — копии кластерного храниища, но с еще незакоммиченными записями. Эти спейсы создает лидер в начале терма, поэтому невозможность создавать темпорари спейсы на ридонли инстансе делает их непригодными в текущем виде.

Немного по-другому дела обстоят с "обычными" кластерными спейсами (с закоммиченными данными). Эти спейсы должны персиститься, поэтому ни темпорари ни эфемерные здесь не подходят. Так как данные в них реплицируются через рафт, то тарантульная репликация здесь тоже не нужна. Остается единственный вариант - локальные спейсы.

Проблема состоит в том, что локальные спейсы тоже нельзя создавать на ридонли реплике. А значит применение рафт журнала с записью в такой спейс на ридонли инстансе залипнет в ожидании тарантульной репликации.

Я предлагаю решить обе проблемы (и с эфемерными, и с локальыми спейсами) кардинально:

1. Создание локального спейса должно быть локальным.
2. Создание темпорари спейса должно быть темпорари.
3. Тогда и никакие эфемерные не нужны будут

Первый шаг на пути к цели — вместо одного box.space._space завести три системных спейса:

• _space
• _space_local (is_local = true)
• _space_temp (temporary = true)

С индексами поступить аналогичным образом.

Правда это порождает пару новых загадок:

• Как избежать коллизии имен и айдишников?

Как избежать коллизии имен и айдишников?

Проблему с именами можно решить административными средствами:

• От темпорари и локальных спейсов требовать название с префиксом temp_ и local_ соответственно.
• Обычные реплицируемые спейсы запрещено созавать с префиксом temp_ и local_.

А айдишники можно разделить на 3 диапазона - пару старших бит под это дело выделить.

Создание локального спейса должно быть локальным.

Развивая тему свойств разных системных спейсов:

• box.space._func надо разделить на две части. Персистентные функции (для функциональных индексов) реплицироваться должны, а сишные и луашные хранимки должны быть темпорари. Они завязаны на символы в бинаре (или в луа скрипте), и должна быть возможность инициализировать их на старте даже в ридонли.

А что делать с этими?

• box.space._user и box.space._priv
• box.space._truncate

changed title from Ephemeral and temporary spaces to Ephemeral vs temporary vs local spaces

Звучит логично, но кажется что реализовать это будет довольно сложно, плюс скорее всего вызовет проблемы в будущем при ребейзе на новые версии коры. Я сейчас уже на пол пути к вынесению эфемерных спейсов.

mentioned in issue picodata/picodata/sbroad#314

@kostja Приглашаю к обсуждению

КЯП проблема с эфемерными спейсами в том, что они безымянные и не лежат в _space, из-за чего с ними не работает некоторые sql юзкейсы. Поэтому апи эфемерных спейсов отменяется, вместо этого:

• Нам надо закостылить добавить возможность существующим temporary спейсам создаваться с добавлением в _space но без попадания этой записи в wal и следовательно без репликации этой записи.

• Из-за отсутствия репликации у нас пропадёт механизм защиты от коллизий айдишников, для этого надо будет нашим temporary+ спейсам выдавать айдишники из эксклюзивно выданного диапазона (в который не будут попадать реплицируемые спейсы).

• Плюс нужно будет убедиться в том, что temporary+ спейсы могут создаваться на readonly реплике

Итоги встречи 9.01.2023.

• Возню с апишкой box_ephemeral_space_new прекращаем. Сброду нужна возможность работать с этими спейсами через локальный sql, а локальному sql нужно имя (FROM "foo" SELECT *). Пикодате эфемерных спейсов тоже мало, ей нужны еще персистентные нереплицируемые (локальные) спейсы. Так что вместо доработки эфемерных спейсов мы пробуем починить правила создания темпорари и локал спейсов и смотрим что из этого получится.

• Разделение _space на три части таит свои опасности - так мы лишимся структурной связности. Грубо говоря, найти спейс по айдишнику будет совсем не тривиальной задачей.

• Чтобы не терять структурную связность можно попробовать сделать row-based репликацию записей в _space, т.е. реплицироваться будет только часть таплов. В таком случае появится еще одна задачка — проследить чтобы нереплицируемые персистентные (локальные) записи не попали на реплику вместе со снапшотом при бутстрапе.

Чтобы выровнять терминологию повторюсь, мы пытаемся сделать три вида спейсов:

1. "обычные" - персистентные, реплицирумые. Создаются и пишутся только на rw инстансе.
2. "локальные" - факт создания и все данные персистятся, но не реплицируются. И создавать, и писать в такие можно на ro реплике.
3. "темпорари" - даже не персистятся (в wal не попадают), и тем более не реплицируются. И создавать, и писать в такие можно на ro реплике.

mentioned in merge request !34 (merged)

темпорари плохое имя, т.к. такие уже есть. надо назвать их как-то иначе. например volatile

mentioned in issue picodata/picodata/sbroad#315

changed the description

assigned to @k.derevtsov

mentioned in merge request picodata/picodata/picodata!633

mentioned in issue picodata/picodata/picodata#368

Реализация успешно вмержена в апстрим, но с некоторыми отличиями в деталях: https://github.com/tarantool/tarantool/pull/8322

closed

mentioned in merge request !223 (merged)