В этой серии из трех частей мы покажем технические достижения, которые могут значительно улучшить обработку данных для приложений, работающих по компьютерному протоколу Интернета (ICP).
Это обновление является важной вехой в дорожной карте Stellarator и в настоящее время продвигается по всей сети. Stellarator — это прорыв в хранении данных в цепочке, позволяющий каждой подсети иметь более 1 ТБ памяти, что делает его решением, насыщенным данными. ранее был ограничен объемом памяти. Приложения приносят возможности.
Это достижение позволяет разработчикам создавать сложные приложения, требующие крупномасштабной обработки данных, выводя на новый уровень полезность технологии блокчейн.
Не теряя времени, давайте начнем эту серию, чтобы увидеть, как ICP сейчас использует обновления Stellarator для хранения данных.
Постоянство данных на Интернет-компьютере
В этом посте рассматривается, как работает хранение на копиях машин Интернет-компьютера, с особым акцентом на изменения, связанные с недавно введённым уровнем хранения на основе объединяющего дерева журналов (LSMT), который включает в себя реализацию большего количества реплицируемого хранения на подсетях Интернет-компьютера и позволяет им лучше справляться с тяжелыми рабочими нагрузками.
Интернет-компьютер состоит из подсетей, виртуальных машин, которые выполняют одинаковое копирование на 13-40 машинах-копиях, каждая из которых отвечает за выполнение всех сообщений, отправленных в эту подсеть, и хранение всех данных контейнеров, таким образом, все копии имеют полное и одинаковое состояние подсети.
Разработчики могут развертывать контейнеры на Интернет-компьютере, контейнеры аналогичны смарт-контрактам на других блокчейнах, но могут выполнять более универсальные вычисления и хранить данные на порядки больше, чем смарт-контракты на других цепочках.
Данные, хранящиеся в контейнере, в конечном итоге необходимо хранить на каком-то физическом оборудовании, благодаря недавно введенному уровню хранения на основе LSMT и многим другим оптимизациям и улучшениям, подсеть на Интернет-компьютере может хранить до 1 ТБ данных контейнера.
Большая часть данных контейнера хранится либо в его куче памяти (до 4 ГБ при записи), либо в его стабильной памяти (до 500 ГБ при записи), также имеются иные формы данных, связанные с контейнером, такие как код контейнера, сообщения в процессе и различные сведения, такие как список контроллеров и остаток циклов.
Уровень хранения ICP сокращает разрыв между хранением контейнеров (например, кучей и стабильной памятью) и хранилищем аппаратного обеспечения узлов-копий (например, диском и ОЗУ).
В рамках вехи Stellarator уровень хранения претерпел обширный редизайн и переоснащение, чтобы ICP мог справляться с будущими вызовами масштабируемости и решать наиболее важные узкие места старого уровня хранения, все соответствующие изменения были недавно завершены, Интернет-компьютер уже несколько месяцев работает с новой реализацией уровня хранения.
Остальная часть этого поста описывает процесс переработки уровня хранения в структуру данных объединяющего дерева журналов, редизайн направлен на устранение узких мест, связанных с хранением, и улучшение опыта пользователей и разработчиков, работающих с ресурсоемкими контейнерами.
Для пользователей ICP наиболее примечательным является то, что эта работа позволила недавнему увеличению копий состояния в одном подсети до 1 ТБ, кроме того, переработка также позволила Интернет-компьютеру лучше обрабатывать записи большого объема данных.
Контрольная точка
В общем, уровень хранения Интернет-компьютера сочетает в себе постоянное хранение на диске и временное хранение в ОЗУ, ключевой концепцией того, как Интернет-компьютер хранит свое состояние, является так называемая контрольная точка, контрольная точка - это логическая точка времени, в которой состояние всей подсети хранится на диске.
Контрольные точки создаются каждые 500 блоков или каждые несколько минут определенным образом, что означает, что все копии будут записывать одну и ту же контрольную точку на одной и той же высоте, контрольные точки хранятся на диске каждого узла-копии в виде файлового каталога, структура каталога выглядит следующим образом (значительно упрощена):
В этой структуре каждый контейнер хранится в своем собственном подкаталоге, и каждый каталог контейнера содержит отдельные файлы для кучи памяти, стабильной памяти и другой информации (например, сообщений в процессе), данные сохраняются на диск в виде контрольных точек по нескольким причинам.
1. Постоянство данных: машины-копии могут перезагрузиться в любое время, в коде копий могут быть ошибки программного обеспечения, или аппаратное обеспечение может выйти из строя, или может быть проблема с электроснабжением в дата-центре, в таких случаях можно перезагрузить последнюю контрольную точку.
Обратите внимание, что даже при создании контрольной точки только каждые 500 раундов копии могут восстановить состояние на неконтрольной высоте, копиям нужны только последние контрольные точки и все окончательные блоки между контрольной точкой и последним состоянием, поскольку все выполнения являются детерминированными, эти блоки могут быть воспроизведены, и гарантируется, что восстановленное состояние будет полностью идентично, необходимые блоки могут храниться отдельно от контрольной точки на диске или получаться от других копий.
2. Синхронизация: все (копируемые) сообщения выполняются всеми копиями, поэтому для любой заданной высоты h все копии должны иметь одинаковое состояние, этот протокол предотвращает расхождения, сначала хэшируя состояние, а затем подписывая полученный хэш порогом, только тогда, когда как минимум ⅔ (точнее 2f + 1) копий согласны с одинаковым хэшом, может быть создана такая пороговая подпись, чтобы подсеть могла продолжать функционировать.
Тем не менее, подсети Интернет-компьютера могут иметь большое состояние, на момент написания этой статьи ограничение составляет 1 ТБ, при сохранении до 2,5 блоков в секунду (что быстрее всего на данный момент достигается на Интернет-компьютере) невозможно выполнять хэширование такого объема данных после каждого блока, поэтому Интернет-компьютер лишь частично хэширует состояние на неконтрольной высоте, например, включая некоторую основную информацию о каждом контейнере, недавние ответы на входящие сообщения и сообщения XNet, отправленные в другие подсети.
Для контрольной точки протокол хэширует все состояние, чтобы получить структуру данных, называемую списком, этот список вычисляется путем хэширования всех файлов в каталоге контрольной точки и содержит хэши всех отдельных файлов, разбитых на блоки по 1 МБ, в конце вычисления списка будет вычислен корневой хэш списка, охватывающий все отдельные хэши в списке, после чего подсеть подпишет его порогом, вычисление списка может занять десятки секунд, но эта работа выполняется только каждые 500 блоков и выполняется параллельно с выполнением контейнера в фоновом режиме.
3. Синхронизация состояния: Интернет-компьютер позволяет изменять топологию подсети через предложения NNS, когда узлы-копии присоединяются к подсети, они могут получить последнюю контрольную точку от других узлов-копий, вспомните, что контрольная точка - это набор файлов, поэтому, используя их корневой хэш и подпись порога подсети для проверки списка, протокол синхронизации состояния может получать файлы по частям, одновременно сравнивая хэш полученных блоков с хэшами в списке, если все проверки успешны, копия может заключить, что полученное состояние соответствует согласованному состоянию отдельных подсетей на уровне контрольной точки, если копия отстает по другим причинам и слишком велика разница с состоянием здоровья, чтобы догнать чистое воспроизведение блоков, это также вызовет синхронизацию состояния.
4. Максимальный размер состояния: в настоящее время максимальный размер состояния составляет 1 ТБ, а оперативная память узлов-копий составляет 512 ГБ, поэтому загрузить все состояние в ОЗУ невозможно, Интернет-компьютер использует ОЗУ в основном для хранения последних данных, которые еще не были сохранены, а также для кэширования данных с целью повышения производительности.
PageMap и неконтрольные высоты
Поскольку контрольная точка создается только каждые 500 блоков, ICP необходимо обеспечить различное пространство хранения для состояния на неконтрольной высоте, основная идея, следуемая уровнем хранения, заключается в том, что эти данные хранятся на диске в виде комбинации последней контрольной точки, все последующие изменения хранятся в ОЗУ.
PageMap является реализацией большей части содержания копий по состоянию подсети, подавляющее большинство состояния подсети - это состояние контейнеров, особенно куча и стабильная память контейнеров.
В настоящее время контейнеры могут иметь до 4 ГБ кучи памяти, 500 ГБ стабильной памяти, и общий лимит состояния подсети составляет 1 ТБ, но все эти ограничения могут измениться в будущем, обе эти памяти могут быть прочитаны через вызовы контейнера, как через копирование (обновление), так и через некопирование (запросы), также могут быть изменены через вызовы копирования.
Структура данных PageMap предназначена для реализации эффективного чтения и записи в память, а также для поддержки эффективной записи контрольных точек, одной из конкретных целей является то, чтобы производительность не зависела от общего размера памяти, обратите внимание, что название PageMap происходит от того факта, что все операции чтения и записи имеют размер 4 КБ, что совпадает с размером страниц, используемым в операционной системе.
PageMap хранит состояние в двух слоях: первый слой называется хранилищем, это файлы из предыдущей контрольной точки, они представляют состояние на высоте предыдущей контрольной точки, второй слой, т.е. инкремент страниц, представляет все изменения с этой контрольной точки и хранится в ОЗУ.
При чтении из PageMap возвращаемые данные либо извлекаются из инкремента страницы, либо читаются из файла контрольной точки (если отсутствуют), запись в PageMap выполняется путем изменения инкремента страницы с помощью новых данных.
Жизненный цикл контрольной точки
Основная задача уровня хранения заключается в записи контрольных точек на диск и поддержании актуального состояния всех PageMap, при записи новой контрольной точки все страницы инкремента обновляются на диск, обновляя хранилище всех PageMap.
Чтобы гарантировать сохранность всех данных, копиям необходимо постоянно сохранять последнюю контрольную точку с пороговой подписью, это означает, что просто перезаписать старые файлы контрольных точек невозможно, так как любое такое изменение изменит предыдущую контрольную точку до полной записи новой контрольной точки, тем самым существует риск потери данных, одновременно каждые 500 раундов записывая полную контрольную точку на диск (максимум 1 ТБ) будет очень дорого, напротив, создание новой контрольной точки включает в себя 3 основных шага:
Скопировать старую контрольную точку в временную папку, называемую подсказкой;
Измените подсказку, чтобы она представляла данные новой контрольной точки;
Переименуйте подсказку в новый каталог контрольной точки (чтобы атомарно создать новую контрольную точку).
Первый шаг может быть самым дорогим, так как чем больше состояние, тем больше времени требуется для копирования файлов, следовательно, контрольная точка становится больше.
Однако именно здесь вступает в действие формат файлов контрольных точек и объединяющего дерева журналов, благодаря использованию LSMT эта стадия становится недорогой и не увеличивается с увеличением размера состояния, в отличие от этого, до редизайна уровня хранения LSMT этот шаг был медленным и непредсказуемым.
Структура объединяющего дерева журналов
Структура объединяющего дерева журналов (LSMT) - это широко используемая структура данных, особенно подходящая для баз данных, на Интернет-компьютере они используются в качестве основы для хранения части PageMaps, одна из специальных проблем, которую она может решить, заключается в том, что она упрощает шаг 'копирования' в жизненном цикле контрольных точек, так как все файлы записываются только один раз и никогда не изменяются.
С помощью LSMT состояние (логическое) можно изменить, записывая дополнительные файлы перекрытия, чтобы прочитать значения страниц, алгоритм сначала проверяет недавно записанные файлы перекрытия, чтобы узнать, есть ли эта страница в этом файле, если есть, то значение страницы читается из этого файла, если нет, проверяется следующий более старый файл перекрытия, в реализации, используемой на Интернет-компьютере, если страница не существует ни в одном файле перекрытия, она читается как ноль.
На рисунке ниже показан набор из трех файлов перекрытия, представляющих состояние контейнера, вертикальные стрелки показывают различные чтения данных и конечный файл, в котором были считаны данные.
Жизненный цикл контрольных точек LSMT выглядит следующим образом:
Жесткие ссылки на все файлы предыдущей контрольной точки в временную папку, называемую подсказкой;
Запишите новый файл перекрытия, содержащий все изменения с последней контрольной точки;
Переименуйте подсказку в новый каталог контрольной точки (для атомарности).
Ключ в том, что каждый файл перекрытия записывается только один раз и никогда не изменяется, что делает безопасным установку нескольких контрольных точек на диске и совместное использование некоторых файлов между ними через жесткие ссылки, обратите внимание, что если жизненный цикл контрольной точки пытается изменить любой файл, то этот же процесс не будет работать, если файл имеет несколько жестких ссылок, изменение любой из них изменит данные во всех жестких ссылках, что подорвёт ранее сертифицированные контрольные точки.
Структура объединяющего дерева журналов может хранить несколько версий одного и того же диапазона данных, что приведет к накладным расходам на хранение, определяемым как отношение общего размера всех файлов перекрытия к логическому размеру данных, которые они представляют, кроме того, данные могут быть разбросаны по нескольким файлам.
С увеличением накладных расходов на хранение или количества файлов перекрытия реализация уровня хранения будет организовывать слияние, слияние происходит путем получения набора файлов перекрытия и замены их одним файлом, содержащим только последние версии каждой записи, слияния планируются для PageMap с особенно высокими накладными расходами на хранение или количеством файлов и выполняются в фоновом режиме, чтобы они не мешали выполнению сообщений контейнера.
Предыдущий дизайн, использующий Reflinks
Первоначальный уровень хранения Интернет-компьютера не зависел от LSMT, с момента рождения Интернет-компьютера в 2021 году до 2024 года уровень хранения сильно зависел от повторной привязки.
Повторная привязка, иногда также называемая записью при копировании, является операцией файловой системы, используемой для копирования файлов, некоторые файловые системы поддерживают эту операцию, копии Интернет-компьютера используют файловую систему XFS, поддерживающую эту операцию, повторная привязка отличается от обычного копирования файлов тем, что она не копирует все содержимое файла, вместо этого файловая система запоминает, какие данные разделяют оригинальный файл и новый файл, повторная привязка также отличается от жестких ссылок тем, что оба файла могут быть изменены независимо друг от друга.
В старом дизайне уровня хранения работа цикл контроля точки выглядела следующим образом:
Повторная привязка всех файлов предыдущей контрольной точки в временную папку, называемую подсказкой;
Измените файлы в подсказке в соответствии со всеми изменениями с последней контрольной точки;
Переименуйте подсказку в новый каталог контрольной точки.
Одним из потенциальных преимуществ является то, что PageMap будет представлен одним файлом в контрольной точке, что позволит избежать накладных расходов на хранение, однако для изменения файла, чтобы соответствовать новой высоте контрольной точки, необходимо повторно привязать соответствующий файл предыдущей контрольной точки, а не жестко связать.
Преимущества LSMT по сравнению с Reflinks
В принципе, повторная привязка гарантирует скорость жестких ссылок и доступность копирования, к сожалению, с увеличением потребностей Интернет-компьютера в данных (независимо от того, это I/O пропускная способность или общий объем данных), по ряду причин повторная привязка стала узким местом производительности.
1. Медленная скорость повторной привязки: время, необходимое для повторной привязки файлов, может значительно отличаться, в некоторых случаях оно может составлять всего несколько секунд, но в экспериментах мы также наблюдали, что повторная привязка 370 ГБ занимает до 10 часов, в старой логике контрольной точки Интернет-компьютера 10-часовая повторная привязка приводит к тому, что вся подсеть останавливается на 10 часов.
Фрагментация приводит к низкой скорости повторной привязки, внутри файловой системы XFS поддерживается структура данных, которая сопоставляет части файла с фактическими блоками данных на диске, когда стоимость обхода этих структур данных становится высокой, возникает фрагментация и более медленная скорость повторной привязки.
Фрагментация может быть вызвана следующей последовательностью: большое количество записей в файл, затем повторная привязка его, большое количество записей в одну из копий, снова повторная привязка и так далее, к сожалению, учитывая рабочий процесс контрольных точек на Интернет-компьютере, чрезмерное использование контейнеров приводит к такому поведению.
С другой стороны, жесткие ссылки имеют постоянную производительность, не подвержены каким-либо проблемам с фрагментацией.
Перед введением объединяющего дерева журналов было реализовано множество временных мер, включая ручную дефрагментацию файлов (чтение файлов и запись их обратно) и запись файлов в более крупные непрерывные части, оба метода были связаны с большим увеличением записи и все еще могли привести к задержкам до 30 минут.
2. Максимальный размер состояния: помимо очень длительного времени повторной привязки, вызванного чрезмерной фрагментацией, даже при умеренной фрагментации, время повторной привязки будет пропорционально общему объему данных, хранящихся в подсети, в предыдущей реализации уровня хранения Интернет-компьютера было установлено ограничение на объем хранения каждой подсети в 700 ГБ, это число в значительной степени зависело от того, сколько данных с умеренной фрагментацией можно было повторно привязать за 20-30 секунд.
При использовании жестких ссылок время контрольной точки не будет увеличиваться одинаково с размером данных, что устраняет это узкое место.
3. Плохая многопоточная производительность: одной из целей логики контрольных точек является максимальное избегание синхронных операций, поскольку во время контрольной точки выполнение контейнера приостанавливается, естественно, следует учитывать, можно ли выполнять повторную привязку в фоновом режиме (даже если она медленная), пока выполнение продолжается, к сожалению, опыт показывает, что невозможно одновременно повторно привязать и прочитать файлы, поэтому выполнение параллельной повторной привязки только замедляет выполнение.
В новом дизайне уровня хранения жесткие ссылки выполняются параллельно, и они не замедляют друг друга.
4. Кэш: как упоминалось выше, чтение данных из памяти контейнера будет одновременно извлекать данные из ОЗУ и из файлов контрольной точки, повторное чтение одного и того же файла обычно не приводит к необходимости многократного чтения данных с реального жесткого диска или SSD, вместо этого эти данные будут кэшироваться операционной системой, к сожалению, повторная привязка нарушает кэш, так как сначала повторная привязка файла, а затем чтение из новой копии не использует кэш, поэтому на Интернет-компьютере после записи контрольной точки наблюдаются значительные (и медленные) пики чтения диска, так как все чтения переключаются на новые файлы, кроме того, явное вычисление (то есть вычисление хэш-значений всех файлов контрольной точки для достижения консенсуса) также значительно выигрывает от лучшего кэширования.
Напротив, при жестком связывании файлов все кэши сохраняются, любые недавно прочитанные или записанные данные, даже если они произошли в предыдущем интервале контрольной точки, все равно будут кэшироваться, что позволяет быстро извлекать.
Результаты
Уровень хранения LSMT был развернут по всем подсетям Интернет-компьютера в течение нескольких недель второго квартала 2024 года, на нижнем рисунке показаны метрики до и после обновления кода копии, где красная вертикальная линия обозначает время включения уровня хранения LSMT.
На первом рисунке показано время контрольной точки подсети w4rem, которая хостит контейнеры для интеграции биткойна, в отличие от многих других подсетей, контейнеры, хостящиеся в биткойн-подсети, имеют тяжелые нагрузки записи как в куче, так и в стабильной памяти, поэтому фрагментация является особенно тревожной проблемой для этой подсети.
С точки зрения метрик время контрольной точки сократилось с более 20 секунд до всего 1-2 секунд, что в основном связано с устранением этапа повторной привязки, который занимал большую часть времени в 20 секунд.
Для пользователей контейнеров биткойн его преимущества заключаются в более быстром времени отклика: во время контрольной точки подсеть не обрабатывает никаких обновляющих вызовов или запросов на копирование, если пользователь отправляет обновляющий вызов или запрос на копирование контейнеру биткойн в начале контрольной точки, потребуется как минимум 20 секунд, чтобы получить ответ, использование уровня хранения LSMT может практически устранить такие несоответствия во времени отклика.
На втором рисунке показан уровень завершенности подсети k44fs, уровень завершенности или скорость блоков - это количество блоков, производимых подсетью в секунду.
Интернет-компьютер ограничивает количество инструкций, выполняемых за каждый раунд, примерно соответствующим значению, которое он может выполнить за одну секунду, чтобы уровень завершения оставался выше одного блока в секунду.
Перед обновлением на уровень хранения LSMT, уровень завершения регулярно снижался, что полностью совпадало с контрольными точками, на уровень завершения контрольные точки влияли по двум основным причинам: во-первых, время, необходимое для создания контрольной точки, в течение которого блоки не выполняются, после обновления это влияние сократится, поскольку время контрольной точки обычно намного короче.
Вторая причина заключается в том, что уровень хранения LSMT имеет лучшее поведение кэша, особенно в старой реализации уровня хранения шаг повторной привязки приводил к сбоям кэша, поэтому после контрольной точки любые контейнеры, считывающие из своей памяти, заставляли копии получать эти данные с диска, что медленнее по порядкам величины, чем те же данные, доступные в кэше в ОЗУ, новая LSMT не имеет этой проблемы.
Как показывают метрики, снижение уровня завершенности после обновления стало заметно меньше, это связано с тем, что контрольные точки сами по себе стали быстрее, повторная привязка больше не требуется, и кэширование файлов также больше не теряется.
Для пользователей контейнеров в этой подсети это означает более быстрое время отклика и большую пропускную способность.
Заключение
Переработка слоя хранения Интернет-компьютера вокруг структуры данных объединяющего дерева журналов является важной инвестицией в масштабируемость и производительность платформы, она не только делает некоторые ресурсоемкие рабочие нагрузки возможными, но также позволяет Интернет-компьютеру предоставлять контейнерам большее состояние.
В контексте работы с большими языковыми моделями на основе ИИ и в цепочке контейнеров, особенно интересными являются контейнеры, которые не только зависят от хранения больших объемов данных, но также сильно полагаются на пропускную способность ввода-вывода.
Кроме того, это также закладывает основу для последующих улучшений, таких как улучшение использования параллелизма для уменьшения тяжелых нагрузок на критическом пути, что делает Интернет-компьютер более быстрым, опыт первоначального уровня хранения показывает, что предотвращение повторной привязки имеет решающее значение для достижения этого, и структура данных LSMT может это сделать.
Вам понравилась эта статья? Поделитесь своими мыслями на канале DFINITY Developers X, присоединяйтесь к нашему путешествию по Stellarator завтра, чтобы обсудить улучшение ортогональной стойкости с Люком Блэзером.
Содержимое IC, которое вас интересует
Технический прогресс | Информация о проекте | Глобальные мероприятия
Добавьте в избранное, следите за каналом IC Binance
Оставайтесь в курсе последних новостей
