Clusterwide spaces

Кластерные спейсы нужны в первую очередь для управления самим кластером, но могут применяться и для каких-нибудь справочников.

Идея кластерных спейсов заключается в том, что пикодата предоставляет основанный на raft журнале API доступа к данным. Содержимое этих спейсов одинаково на каждом инстансе.

ACID

• Atomic - что касается записи, пока можно и одной операцией ограничиться. Если надо будет - объединим несколько операций в одной raft entry. Куда более важно обеспечить атомарность чтения + записи.
• Consistent - обеспечивается автоматически, покуда никакие шаловливые ручки не трогают кластерные спейсы в обход рафт журнала.
• Isolation - самый животрепещущий вопрос. Какой уровень изоляции транзакци может и собрается предоставить пикодата? Я думаю, serializable.
• Durable - автоматически обеспечивается рафтом.

Onboarding

• Все "системные" спейсы (picodata_instance, picodata_replicaset, picodata_migration) не хардкодятся, а создаются через единый механизм clusterwide ddl.
• Все кластерные операции выполняются посредством этого clusterwide dml:
  • join
  • update peers target_grade
  • update peers current_grade (by governor)
  • add migration

changed milestone to %Picodata 2023-06

added 1 deleted label

marked this issue as related to #179 (closed)

mentioned in issue #143 (closed)

changed the description

Ради наглядности предлагаю сосредоточиться на гипотетической реализации обычного счетчика:

• На каждый запрос клиент должен получить уникальное значение счетчика.
• Никакие два запроса ни при каких обстоятельствах не должны получить одно и то же число в ответ.
• Реализация должна быть достаточно эффективной, обрабатывать запросы централизованно на лидере допустимо, блокировать обработку запросов в ожидании коммита - нет.

См также

• https://docs.google.com/document/d/1cRSiun6K7qIVQJk85WFDiih7lpLqhvk0bf-IgCwSF0w/edit

Closed in favor of #238 (closed)

closed

mentioned in merge request !1414 (merged)