Сколько времени на миграцию хранилища у вас есть на каждый блок?

Question

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

Итак, предположим,

• существует N валидаторов, использующих текущую согласованную систему, найденную в настройке Substrate, а не как парашютист
• узлы работают на достойных гражданских рабочих станциях
• в коде миграции преобладают последовательности базы данных пары чтения / записи, а также обычные ассоциированные логики кодирования / декодирования c
• размер данных в каждой паре чтения / записи довольно стабилен, в среднем M байтов

пусть f (N, M) будет количеством пар чтения и записи, которые вы сможете безопасно выполнить в одном блоке, когда нет других обработок extrinsi c.

Что хорошо угадайте, как выглядит f (N, M)? просто некоторые достойные ответы для популярных значений N (например, 40) и M (например, 32, 1024).

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

Answer 1

Во-первых, почему N здесь уместно? миграция может происходить в конкретном блоке, и ограничение должно соответствовать его времени внутри блока.

Для этого я бы порекомендовал провести некоторый микро-бенчмаркинг (в WASM) и получить оценку того, сколько каждая операция стоит. Поместите это рядом с желаемым временем блока, и у вас должно быть хорошее число. Я бы также уменьшил это, чтобы быть безопасным.

Обратите внимание, что тип переноса данных имеет значение здесь; Если вы храните значения, это довольно просто, и я предполагаю, что у вас все будет хорошо, поскольку узкое место, вероятно, декодирует, а не хэширует. Если ваше значение (скажем, большое ve c) уже настолько велико, что его нельзя прочитать + записать один раз в блоке, тогда у вас гораздо большие проблемы. С картами вы должны принять во внимание, что вы будете выполнять больше проверок состояния, поэтому весь процесс отличается.