Долгие годы объектные хранилища жили в странном компромиссе: либо дёшево и медленно, либо быстро и неприлично дорого. Архивы, бэкапы, редкие обращения — под это S3-подобная модель подходила идеально. Но ИИ всё сломал. И новость от FractalBits — это не просто ещё один стартап в переполненном рынке, а попытка переписать саму экономику производительности.
Почему скорость внезапно стала обязательной
Современные ИИ-нагрузки работают не с гигантскими файлами, а с миллионами мелких объектов: изображения, фичи, эмбеддинги, текстовые чанки. Формально пропускной способности хватает, но реальная боль — в задержках и количестве операций.
Каждая миллисекунда ожидания I/O — это простаивающий GPU. А простаивающий GPU — это уже не техническая, а финансовая проблема. Именно здесь традиционная модель «платим за каждый запрос» начинает выглядеть абсурдно.
Ловушка высокой производительности
Рынок уже умеет в быстрые объектные хранилища. Пример — S3 Express One Zone. Технологически всё отлично: низкая латентность, семантика каталогов (directory semantics), атомарное переименование (atomic rename). Но есть нюанс — цена за запрос.
В итоге получается парадокс:
- ⚡ скорость есть
- 💸 пользоваться ей нельзя
Когда 10 тысяч операций в секунду превращаются в десятки тысяч долларов в месяц, производительность становится маркетинговой галочкой, а не рабочим инструментом.
FractalBits целятся именно в эту точку — сломать связку “быстро = дорого”.
Что они сделали иначе
Ключевая идея FractalBits — оптимизировать не только задержку (latency), но и стоимость IOPS как базовую метрику. Почти миллион операций в секунду на мелких объектах — это впечатляет. Но куда важнее, что эта скорость остаётся доступной при масштабировании.
Технически это достигается за счёт нескольких принципиальных решений:
- 🧠 метаданные как first-class компонент, а не побочный эффект
- 🌳 radix tree на диске вместо LSM и B+-деревьев
- 📂 нативная иерархия каталогов и атомарное переименование
- 🧱 строгая согласованность, без сюрпризов отложенной согласованности
Фактически, объектное хранилище начинает вести себя так, как ожидают data-инженеры, а не так, как диктует наследие S3.
Почему radix tree — это важно
Выбор radix tree для метаданных — один из самых интересных моментов. В отличие от inode-подобных структур или LSM-деревьев, здесь путь к объекту — это не костыль, а родная структура данных.
Это даёт практичные эффекты:
- 📁 листинг каталога — это обход поддерева
- 🔁 rename — смена указателя, а не копирование
- 🚀 предсказуемая латентность без коэффициента усиления записи (write amplification)
Именно такие мелочи в сумме определяют, можно ли реально использовать хранилище под ИИ-пайплайны, а не только писать об этом в документации.
Zig, Rust и контроль над наносекундами
Отдельно радует технологический стек. Ядро на Zig — это сознательный выбор в пользу предсказуемости и контроля: никакого GC, ручное управление памятью, SIMD, io_uring. API-шлюз на Rust — безопасная конкуррентность без сюрпризов на проде.
Это редкий случай, когда выбор языков выглядит не модным, а инженерно честным: каждый слой написан под свои требования по латентности и стабильности.
Моё мнение: рынок дозрел
Самое важное в FractalBits — не конкретные цифры бенчмарков, а сигнал рынку. Мы подошли к моменту, когда:
- производительность — это не премиум-фича
- объектное хранилище — это активный слой данных
- экономика I/O важнее красивых SLA
ИИ-инфраструктура больше не про «где подешевле хранить», а про «как не сжечь бюджет на простоях». И если FractalBits действительно смогут удержать заявленную экономику в реальных нагрузках, это будет не нишевое решение, а смена базового ожидания от объектного хранилища object.
Источники и ссылки
🔗 Основная статья FractalBits:
https://fractalbits.com/blog/why-we-built-another-object-storage/
🔗 Официальный сайт FractalBits:
https://fractalbits.com
🔗 GitHub проекта:
https://github.com/fractalbits