Switch lang: Русский \ English

Path in storage used for internal purpose


В Документе отражены для каждого сервиса

  1. занятое пространство ключей
  2. возможная процедура очистки данных (освобождение места сервисом)
  3. процедура определения лишнего и удаление лишнего (избыточные даные или данные к которым потерян доступ)

У нас есть KV и ARDB. Описывается пространство ключей, занимаемое каждым сервисом в этих хранилищах.

Service CB , Хранение данных кодовой базы CB (CodeBase of runtime CPVM)

статистика фрагментов, сами фрагменты в разных форматах, логи / части логов и др

Код фрагмента frId/version:

fragments/$$TEST_USER$$/code/frId/version

Пример:

fragments/$$TEST_USER$$/code/fr1/0  ->  print "hello"

Метаинфа фрагмента frId/version:

fragments/$$TEST_USER$$/meta/frId/version

Пример:

fragments/$$TEST_USER$$/meta/fr1/0  ->  {"id":"fr1","version":0,"isTrusted":true,"isTextSource":false,"execTypes":["LuaJit","VmLuaJ","LuaC"]}

chunkIndex-часть лога фрагмента запущенного в трназакции trId и с начальным dam:

logs/trId/dam/chunkIndex

лог разбитый на 3 чанка:

logs/tr1/0.3.13.200/0  ->  "Data Fabric is a high-performance, integrated and distr
logs/tr1/0.3.13.200/1  ->  "ibuted in-memory platform for computing and transactin"
logs/tr1/0.3.13.200/2  ->  "g on large-scale data sets in real-time."

Service PTS

промежуточные и мета-данные сервиса

Service FragSeq (LPF level paralle form Storage) информация о ярусах

Часть пространства ключей , занимаемая данными сервисами

Множества фрагментов с id==setid

['FRAGSEQ', 's_' + setid + '_s']

Идентификатор множества к которому принадлежит фрагмент с id==fid

['FRAGSEQ', 'f_' + fid + '_set']

Метаинформация, максимальный ид множества (decimal) для всех фрагментов в данном временном множестве

['FRAGSEQ', '_s_' + tmpset + '_max']

Следующее в цепочке множество, следующее за множеством с id==setid. (множества следуют цепочкой)

['FRAGSEQ', 's_' + setid + '_next']

Service DT (distributed tree) распределенное дерево

описать занятое пространство ключей

возможная процедура очистки данных (освобождение места сервисом)

определение лишнего и удаление лишнего (избыточные даные или данные к которым потерян доступ)

Service RT (R-TRee)

Сначала пишем ТЗ на сервис

структуры сервиса занимают следующие ключи. TODO

TVM DATA History Storage (сброс истории по каждой ячейке в ARDB)

в каких ключах ardb/redis находятся структуры данных, какого они типа.

Данные, отправленные в ardb представлены следующим набором ключей:

  1. Множество закоммиченных транзакций каждого tvm. Начало его присутствия определяется первым обращением произвольного tvm в данное хранилище. Схема наименования членов множества: tvm|tr_id

  2. Список родительских фрагментов. Может отсутствовать. Схема наименования: tvm|tr_id Структура списка - пары dam/f_id:

dam0 fr0 dam1 fr1 ... damN frN

  1. Список r/w операций для отдельной ячейки. Может отсутствовать. Схема наименования: tvm|tr_id|v_id|key Структура списка - триплеты dam/f_id/is_read:

dam0 fr0 0 dam1 fr1 1 ... damN frN 0

is_read - флаг: 1 - чтение, 0 - запись

Координационный центр:

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

offloaded. Cодержит идентификаторы всех tvm, сбросивших свою данные об IO writes другим tvm, учавствующим в операции commit. tvm, завершивший сброс, дополняет данное множество своим идентификатором и сверяет получившуюся мощность множества с числом tvm, учавствующими в операции commit - при достижении равенства tvm приступает к сортировке накопившихся данных об IO writes, установлению цепочки подписок. При этом удостоверившийся в равенстве tvm публикует в координационном центре сообщение '' на 'tvm_ready_for_io_check'.

sorted. Содержит идентификаторы всех tvm, выполнивших сортировку IO writes и готовых к непосредственному их выполнению. tvm, завершивший данную сортировку дополняет данное множество своим идентификатором и сверяет получившуюся мощность множества с числом tvm, учавствующих в операции commit - при достижении равенства, tvm приступают к выполнению IO операций согласно отсортированному порядку. При этом удостоверившийся в равенстве tvm публикует в координационном центре сообщение 'dam' на 'tvm_begin_io'.

IO операции происходят через io_server (ы), транспортом является protobuf.

Каждый tvm, учавствующий в операции commit, по окончанию своих IO writes и завершению сборки мусора публикует в координационном центре (или у себя, в его отсутствии) сообщение в commit_end_ 'ok' - если операция завершилась без ошибок, или 'tr was not properly committed - ' - если в процессе операции commit произошла какая-нибудь ошибка.

на разных этапах обработки данные трансформируются, как они трансформируются и петемещаются (из каких ключей в какие)

как происходит освобождение занимаемого места ?

Удаление множеств offloaded и sorted происходит сразу же после убеждения в том, что все tvm завершили обмен IO данными, завершили сортировку соответственно.

Комментарии

Comments powered by Disqus
Перейти к главному содержимому