04. StudioFS та альтернативи: що обрати?¶
Work in progress
Уявімо, що монтажер у Німеччині, колорист в Україні, а VFX-художник у Польщі працюють над одним проєктом. Матеріалів — 20 ТБ, і ніхто не хоче спочатку завантажувати їх усі на свій комп’ютер.
Рішень на ринку багато. Але перш ніж порівнювати назви, варто розібратися, що саме вони роблять із файлами.
Синхронізація чи спільний диск?¶
Є два основні підходи.
Синхронізація — програма переносить файли або їхні змінені частини між комп’ютерами. Кожен учасник працює зі своєю локальною копією. Це зручно, коли файлів небагато або вони мають бути доступні без інтернету.
Спільна файлова система — усі бачать один файловий простір, а потрібні частини файлів завантажуються в процесі роботи. Необов’язково мати локальну копію всього проєкту. StudioFS працює саме за таким принципом.
Між цими двома підходами є й проміжні рішення: наприклад, хмарні диски з файлами «лише онлайн» або утиліти, що підключають S3 як папку.
Найближчі до StudioFS¶
LucidLink — мабуть, найближчий до StudioFS за ідеєю продукт. Він дозволяє віддаленій команді працювати зі спільними файлами так, ніби вони лежать на звичайному диску, не завантажуючи весь проєкт на кожен комп’ютер.
Власне, StudioFS має ту саму мету, що й LucidLink: дати команді постпродакшену єдиний робочий простір, незалежно від того, у яких країнах перебувають її учасники.
Різниця в підході. LucidLink — готовий комерційний продукт: ви оплачуєте сервіс, отримуєте клієнтські програми та підтримку виробника. StudioFS — відкритий проєкт, який можна розгорнути на власній інфраструктурі й використовувати зі своїм S3-сховищем. Більше свободи й контролю, але й більше відповідальності за налаштування та підтримку.
JuiceFS — найближчий архітектурний родич StudioFS, який багато в чому надихнув нашу розробку. Обидві системи використовують S3, окрему базу метаданих і локальний кеш.
Але є принципова відмінність — local-first. У JuiceFS затримка до сервера метаданих (RTT) понад 10 мс може зробити систему практично непридатною для задач постпродакшену, особливо під час запису. Кешування метаданих допомагає з читанням, але не розв'язує проблему запису.
У StudioFS файлові операції виконуються локально, а зміни синхронізуються через PostgreSQL у фоновому режимі. Тому навіть за RTT 100 мс звичайна робота з файлами не залежить від кожного мережевого запиту.
Чому не просто Dropbox або Google Drive?¶
Dropbox і Google Drive чудово підходять для обміну файлами та синхронізації робочих папок. Проблеми починаються, коли матеріалів стає ДУЖЕ багато.
Уявімо наш проєкт на 20 ТБ. Якщо п’ять художників працюють із повними синхронізованими копіями, кожному потрібно мати 20 ТБ локального сховища. Разом — 100 ТБ дискового простору для одного проєкту. І всі ці дані ще потрібно завантажити через інтернет.
Так, обидва сервіси дозволяють залишати файли лише в хмарі й завантажувати їх за потреби. Але це не те саме, що файлова система, спеціально створена для потокової роботи з великими медіафайлами. Наприклад, відкриття великого RAW-файлу може вимагати завантаження значно більшого обсягу даних, ніж потрібно програмі для конкретної операції.
Є й друга проблема — egress, тобто вихідний трафік із хмари. Хмарні сервіси мають квоти й обмеження передачі даних, які залежать від тарифу та способу доступу. Для команди, яка щодня читає сотні гігабайтів або терабайти матеріалів, це може стати серйозним обмеженням.
У StudioFS інший підхід: усі учасники бачать спільний файловий простір, але кожен завантажує лише потрібні для роботи частини файлів. Якщо монтажеру потрібні кілька секунд із двогодинного RAW-файлу, немає потреби спочатку переносити весь файл на його комп’ютер.
Resilio та Syncthing — інший випадок. Вони хороші, коли потрібно доставити матеріали на кілька комп’ютерів і зберігати локальні копії. Але синхронізована папка й один спільний диск — не те саме.
А чому не підключити S3 напряму?¶
Можна. Наприклад, rclone mount дозволяє підключити S3 як звичайний диск. Він підтримує локальне кешування, часткове читання великих файлів і навіть багато звичних файлових операцій.
Але коли справа доходить до активного редагування великих файлів, усе стає складніше. Залежно від сховища та налаштувань зміна невеликої частини файлу може вимагати повторного завантаження цілого об’єкта. А якщо з тими самими файлами працюють кілька комп’ютерів, виникають додаткові питання щодо кешування та узгодженості змін.
Це не провина самого rclone. Просто зробити так, щоб десятки різних хмарних сервісів поводилися як повноцінна локальна файлова система, — завдання не з простих.
Існують й інші способи підключити S3 як диск. Для читання файлів або перенесення матеріалів деякі з них цілком підходять. Але S3 — це об’єктне сховище, а не звичайна файлова система. Воно не підтримує всі звичні операції над файлами в тому самому вигляді, зокрема, довільний запис усередину файлу (random writes) або перейменування (rename).
Докладніше про цю проблему можна прочитати в статті How To Make Your Object Storage Look Like a File System.
Саме тому в архітектурі StudioFS ми відокремлюємо дані від метаданих. S3 відповідає за зберігання вмісту, а StudioFS сам керує файловою структурою, версіями та змінами. Це дозволяє реалізувати звичні файлові операції, не вимагаючи від S3 того, для чого він не призначений.
Коли StudioFS — не найкращий вибір?¶
- Вам потрібне рішення для важливого виробництва вже сьогодні. StudioFS ще активно розробляється. Якщо ви готові стати першопрохідцем — welcome to the bright side! Якщо ні — мій кіт вкусить вас за ногу, коли зустріне.
- Ви не хочете адмініструвати S3, PostgreSQL і доступ до них. Власна інфраструктура дає контроль, але не обслуговує себе сама.
- Потрібно працювати без інтернету з усім проєктом. Тут зручнішими можуть виявитися повні локальні копії та звичайна синхронізація.
- Вас корчить від українського прапора. Тут ми навряд чи зможемо допомогти.
А скільки це коштує?¶
У StudioFS немає обов’язкової плати за ліцензію, але «відкритий код» не означає «безкоштовне сховище». Потрібно оплачувати S3, PostgreSQL, сервери, інтернет-трафік та витрачати час на налаштування й підтримку.
І не плутайте знімки файлової системи з незалежним бекапом — незалежно від обраного продукту.
Зміст · English · ← Попередня · Наступна →