Снапшоты в TATLIN.BACKUP: внутреннее устройство на LSM-дереве и RocksDB

Снапшоты — это не просто кнопка «сделать копию». В системах резервного копирования они определяют, насколько быстро можно восстановить данные и сколько места при этом потребуется. Разработчики TATLIN.BACKUP из компании «Ядро» почти год назад внедрили снапшоты в свою дедуплицирующую файловую систему и теперь делятся опытом, как это устроено изнутри. Речь пойдёт о LSM-дереве, RocksDB и Bloom-фильтре, который по размеру сравним с системным диском ноутбука.

Как устроены снапшоты в TATLIN.BACKUP

TATLIN.BACKUP — это система резервного копирования, которая использует собственную дедуплицирующую файловую систему. В предыдущих статьях команда рассказывала, как они строили хранилище с нуля: использовали чанки, алгоритм FastCDC и протокол T-BOOST. Теперь пришло время разобраться, как работают снапшоты на уровне архитектуры.

Снапшот — это мгновенный снимок состояния файловой системы на определённый момент времени. В TATLIN.BACKUP снапшоты строятся на основе экстентов — непрерывных областей данных. Файл представляется как список идентификаторов экстентов, что позволяет быстро создавать снимки без копирования самих данных. Для сборки мусора выбрали алгоритм Mark-and-Sweep, а не подсчёт ссылок, потому что он лучше справляется с циклическими ссылками и сложными зависимостями.

Уже почти год снапшоты работают в продакшене, и, по отзывам пользователей, они справляются со своей задачей. Но как именно это реализовано технически? Ответ — в использовании LSM-дерева и RocksDB.

Предыстория и контекст

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

Снапшоты в системах резервного копирования — стандартная функция, но реализация может сильно различаться. В TATLIN.BACKUP решили пойти по пути использования LSM-дерева (Log-Structured Merge-tree) — структуры данных, которая оптимизирована для операций записи и чтения в системах с большим объёмом данных. LSM-дерево лежит в основе многих современных баз данных, включая RocksDB, которая используется в проекте.

Выбор Mark-and-Sweep вместо подсчёта ссылок был осознанным. Подсчёт ссылок имеет проблемы с циклическими ссылками, когда объекты ссылаются друг на друга и не могут быть удалены. Mark-and-Sweep позволяет обойти эту проблему, но требует периодического прохода по всем данным, что может быть затратно. Однако для снапшотов это оказалось более надёжным решением.

Почему LSM-дерево и RocksDB?

LSM-дерево — это структура данных, которая обеспечивает высокую производительность при записи за счёт буферизации данных в памяти и последующего слияния в отсортированные файлы на диске. RocksDB — это встраиваемая база данных, реализующая LSM-дерево. Она широко используется в проектах, где требуется высокая скорость записи и чтения, например, в Apache Kafka и Cassandra.

В TATLIN.BACKUP RocksDB используется для хранения метаданных о чанках и экстентах. Когда создаётся снапшот, записи о новых экстентах добавляются в RocksDB, а старые остаются на месте. Это позволяет быстро получать список экстентов для конкретного снапшота. LSM-дерево обеспечивает эффективное слияние данных и компактное хранение, что важно для системы с дедупликацией.

Технические детали: как это работает на практике

Основная сложность при реализации снапшотов на LSM-дереве — это управление версиями данных. Каждый снапшот должен видеть своё состояние файловой системы, независимо от изменений, происходящих после его создания. В TATLIN.BACKUP это решено с помощью версионирования на уровне RocksDB: каждый снапшот получает свой идентификатор, и все записи в RocksDB помечаются этим идентификатором. При чтении данных для конкретного снапшота RocksDB фильтрует записи по идентификатору.

Однако такой подход требует быстрого поиска записей, относящихся к конкретному снапшоту. Для этого используется Bloom-фильтр — вероятностная структура данных, которая позволяет быстро определить, есть ли элемент в множестве. В TATLIN.BACKUP Bloom-фильтр построен для каждого снапшота и занимает значительный объём памяти. По словам разработчиков, размер Bloom-фильтра может достигать размера системного диска ноутбука — это порядка сотен гигабайт. Это допустимо, поскольку фильтр хранится в оперативной памяти и позволяет избежать лишних обращений к диску.

Ещё одной важной деталью является сборка мусора. Mark-and-Sweep в контексте LSM-дерева означает, что периодически система проходит по всем данным, помечает те, которые ещё используются каким-либо снапшотом, и удаляет остальные. Этот процесс называется компакцией в RocksDB. Он может быть затратным по времени, но позволяет поддерживать хранилище в чистоте без риска удалить нужные данные.

Как работает сборка мусора в снапшотах на LSM-дереве?

Сборка мусора в снапшотах на LSM-дереве — это критически важный процесс, который обеспечивает эффективное использование дискового пространства. В TATLIN.BACKUP используется алгоритм Mark-and-Sweep, который работает в тесной связке с компакцией RocksDB. Во время компакции система анализирует все записи, определяет, какие из них всё ещё нужны для существующих снапшотов, и удаляет устаревшие версии данных. Этот процесс может занимать значительное время, но он необходим для поддержания производительности системы на высоком уровне.

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

Кого затронет и как

Эта статья будет полезна разработчикам, которые работают с системами резервного копирования, файловыми системами или базами данных на основе LSM-дерева. Они узнают, как можно реализовать снапшоты на RocksDB и какие подводные камни могут встретиться. Для пользователей TATLIN.BACKUP это означает, что система имеет продуманную архитектуру, которая обеспечивает надёжность и производительность.

Для бизнеса, использующего TATLIN.BACKUP, важно понимать, что снапшоты работают уже почти год в продакшене и зарекомендовали себя как надёжное решение. Это снижает риски при внедрении и позволяет рассчитывать на стабильную работу системы.

В России и СНГ TATLIN.BACKUP активно используется в компаниях, которым требуется резервное копирование больших объёмов данных. Понимание внутренней архитектуры помогает администраторам лучше настраивать систему и планировать ресурсы.

Что будет дальше

Команда TATLIN.BACKUP продолжает развивать систему. В планах — улучшение производительности снапшотов, оптимизация Bloom-фильтров и, возможно, переход на другие структуры данных, если это даст выигрыш. Также ожидается расширение функциональности, например, поддержка инкрементальных снапшотов, которые позволят ещё больше экономить место.

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

Итог

Снапшоты в TATLIN.BACKUP построены на современных технологиях — LSM-дереве и RocksDB, что обеспечивает высокую производительность и надёжность. Использование Bloom-фильтров, несмотря на их размер, позволяет быстро находить нужные данные. Опыт команды показывает, что даже сложные задачи можно решить элегантно, если правильно выбрать архитектуру. Для тех, кто работает с резервным копированием, эта статья — ценный источник знаний о том, как устроены снапшоты изнутри.