Tidehunter: Следующее поколение базы данных Sui, оптимизированное для низкой задержки и снижения усиления записи

Кратко

Sui представила Tidehunter — специально разработанный движок хранения данных для блокчейнов, созданный для замены RocksDB за счет снижения амплификации записей и обеспечения более высокой, стабильной пропускной способности и меньшей задержки для рабочих нагрузок валидаторов и полноузлов.

Sui, сеть блокчейнов уровня 1, представила Tidehunter — новый движок хранения данных, разработанный с учетом требований к производительности, характеристик доступа к данным и операционных ограничений, характерных для современных инфраструктур блокчейнов.

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

Изначально Sui использовала RocksDB в качестве основного слоя хранения ключ-значение — широко распространенное и зрелое решение, позволяющее быстро разрабатывать протоколы. По мере расширения платформы и увеличения операционных требований становились очевидны фундаментальные ограничения универсальных баз данных на базе LSM-деревьев, особенно в средах, приближенных к производственным.

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

Одним из ключевых факторов, повлиявших на это решение, была постоянная амплификация записей. Измерения в условиях реальных нагрузок Sui показали уровни амплификации примерно в десять-двадцать раз, что означало, что относительно небольшие объемы данных создавали непропорционально большой объем дискового трафика. Хотя такое поведение характерно для систем на базе LSM, оно снижает эффективную пропускную способность хранения и усиливает конкуренцию между фоновым сжатием и операциями чтения. В условиях интенсивных или сбалансированных чтением-записью средах этот накладной расход становится все более ограничивающим при масштабировании пропускной способности.

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

Архитектура Tidehunter: движок хранения, оптимизированный для паттернов доступа в блокчейнах и устойчивых высокопроизводительных нагрузок

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

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

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

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

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

Индексы сильно шардуются для снижения амплификации и увеличения параллелизма, устраняя необходимость в традиционных структурах LSM-деревьев. Для данных, ориентированных на добавление, таких как контрольные точки и записи консенсуса, используются специальные стратегии шардинга, которые группируют свежие данные так, чтобы нагрузка на запись оставалась стабильной даже при росте исторических данных.

Для таблиц с равномерно распределенными хеш-ключами Tidehunter вводит унифицированный индекс поиска, оптимизированный для предсказуемого и низкозадержного доступа. Вместо выполнения множества мелких случайных чтений индекс читает немного больший смежный участок, который статистически содержит нужную запись, что позволяет завершать большинство запросов за один круг диска.

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

Для дальнейшего контроля хвостовой задержки в масштабных системах Tidehunter сочетает прямой ввод-вывод с управляемым приложением кэшированием. Большие исторические чтения обходят кеш страниц операционной системы, чтобы избежать загрязнения кеша, а недавно и часто используемые данные сохраняются в пользовательских кешах, основанных на паттернах доступа приложений. В сочетании с индексной структурой это уменьшает ненужные обращения к диску и повышает предсказуемость при устойчивой нагрузке.

Управление жизненным циклом данных также упрощено. Поскольку записи хранятся непосредственно в сегментах журнала, удаление устаревших данных осуществляется путем удаления целых файлов журнала, выходящих за пределы окна хранения. Это исключает необходимость сложных и ресурсоемких механизмов сжатия, характерных для баз данных на базе LSM, и позволяет быстрее и предсказуемо очищать данные по мере их роста.

На рабочих нагрузках, моделирующих реальное использование Sui, Tidehunter демонстрирует более высокую пропускную способность и меньшую задержку по сравнению с RocksDB, при этом потребляя значительно меньшую пропускную способность диска для записей. Самое заметное улучшение — почти полное устранение амплификации записей, что позволяет активности диска более точно соответствовать записям на уровне приложений и сохранять I/O-емкость для чтения. Эти эффекты наблюдаются как в контролируемых бенчмарках, так и в полномасштабных развертываниях валидаторов, что свидетельствует о том, что преимущества выходят за рамки синтетического тестирования.

Оценка проводится с помощью универсальной тестовой системы, моделирующей реалистичные миксы вставок, удалений, точечных запросов и итераций. Тесты параметризованы для отражения распределений ключей, размеров значений и соотношений чтения-записи, соответствующих Sui, и выполняются на оборудовании, соответствующем рекомендациям для валидаторов. В этих условиях Tidehunter стабильно обеспечивает более высокую пропускную способность и меньшую задержку, чем RocksDB, особенно в сценариях с интенсивной записью и сбалансированных нагрузках.

Бенчмарки валидаторского уровня дополнительно подтверждают результаты. При интеграции непосредственно в Sui и при постоянной нагрузке транзакций системы с Tidehunter поддерживают стабильную пропускную способность и меньшую задержку в точках работы, где развертывания на базе RocksDB начинают страдать от роста использования диска и ухудшения производительности. Измерения показывают снижение нагрузки на диск, более стабильное использование CPU и улучшение времени финализации, что явно свидетельствует о различиях в поведении при сопоставимых нагрузках.

Tidehunter — практический ответ на операционные требования долгосрочных, высокопроизводительных систем блокчейна. По мере перехода блокчейнов к устойчивым, а не всплесковым нагрузкам, эффективность хранения становится фундаментальным требованием к производительности протокола. Конструкция Tidehunter отражает сдвиг в сторону инфраструктуры, специально созданной для следующего этапа масштабирования, с дальнейшими техническими деталями и планами внедрения, ожидаемыми в будущем.