Хранение 3D-моделей: файлы, дерево, граф

Введение

Путаница с версиями 3D-моделей при проектировании и имена вроде `v1`, `v2_final`, `v3_final_ok` — это симптом отсутствия системы и место отложенных проблем. К этому добавляются конфликты при совместной работе, случайные перезаписи и вопросы «а я сейчас правлю актуальную версию?».

В области разработки программного обеспечения аналогичную задачу решили без компромиссов. Это решение получило название DevOps — методология и культура, объединяющие разработку (Dev) и эксплуатацию (Ops) ПО.

Почему именно GitLab, CADBase и Onshape

Можно выделить три подхода: кодоцентричный (GitLab), компонентноцентричный (CADBase) и документоцентричный (Onshape).

• GitLab — это контроль версий, фундамент для софта, инфраструктуры и текстового описания железа.
• CADBase — это библиотека компонентов, связующее звено и интегратор для классической промышленности, которой нужно связать привычные десктопные САПР с современными практиками и моделью Индустрия 4.0.
• Onshape — это единая облачная среда, объединяющая CAD, PDM и версионирование.

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

Подход к хранению данных: архитектура

Теперь, когда есть представление о том, что такое GitLab, CADBase и Onshape и для чего они нужны, необходимо понять, как именно каждая система хранит данные. Это не техническая деталь: архитектура хранения определяет, какие задачи система решает хорошо, а какие — принципиально не может решить.

GitLab + Git LFS: хранение как указатель

GitLab использует распределённую систему контроля версий Git. По умолчанию Git хранит полную копию каждого файла в каждой версии репозитория. Для текстовых файлов это эффективно: Git вычисляет разницу между версиями (diff) и хранит только изменения. Но для бинарных форматов (STL, STEP, F3D) это не работает — любое изменение означает полную замену файла в истории.

Решение — Git LFS (Large File Storage). Механизм работает так:

• Файл физически выгружается в отдельное объектное хранилище.
• В Git-репозитории остаётся только текстовый указатель размером несколько сотен байт.
• Указатель содержит SHA-256 хеш, размер файла и версию спецификации LFS.

При клонировании репозитория LFS-файлы скачиваются только для текущего коммита (HEAD). История старых версий подтягивается по запросу командой `git lfs fetch`.

GitLab управляет версиями файлов, а не версиями моделей. Система не знает, что `bracket.stl` и `bracket_v2.stl` — это одна деталь. Она видит два разных файла. Связи между ними — это ручная дисциплина пользователя, выраженная через коммиты и теги.

Плюсы:

• Полный контроль над историей на уровне байт.
• Возможность самохостинга: данные остаются на вашей инфраструктуре.
• Бесплатно (в базовой конфигурации).

Минусы:

• Бинарные файлы не мержатся. Два человека не могут одновременно править одну модель.
• Отсутствует инженерный контекст: изделия, параметры, состав изделия (BOM).
• Требует дисциплины: без соглашения о структуре папок и описаний история превращается в хаос.
• Git LFS не уменьшает уже раздутый репозиторий: если бинарники попали в историю, нужна миграция с перезаписью.

CADBase: хранение как иерархия сущностей

CADBase использует объектную модель данных. Структура изделия задана иерархией из трёх уровней:

📦 Компонент (Карточка изделия)

└── ⚙️ Модификация (Конкретное исполнение)

      └── 📂 Набор файлов (Контекстный контейнер под ПО)

• Компонент — базовая карточка изделия с его характеристиками и другими метаданными.
• Модификация — конкретное исполнение изделия (например, «кронштейн, исполнение 01, PETG» или «кронштейн, исполнение 02, алюминий»). У каждой модификации свои параметры.
• Набор файлов — контекстный контейнер для конкретной САПР или задачи. Одна модификация может включать различные наборы файлов, как для работы из FreeCAD и Blender, так и для запросов с 3D-принтера для печати.

Это принципиально иная логика: система хранит не файлы, а изделия. Файлы могут добавляться к объектам платформы — это атрибут, а не самостоятельная сущность.

Плюсы:

• Инженерная логика: поиск не по имени файла, а по параметрам изделия и другим метаданным.
• Open Source: весь стек открыт, возможен On-Premise.
• Прямая интеграция платформы с FreeCAD и Blender.
• GraphQL API для автоматизации и расширения интеграций.

Минусы:

• Нишевость: интеграция только с FreeCAD и Blender. Пользователям SolidWorks, Fusion 360 и Компас-3D потребуется создавать интеграции с рабочими инструментами, чтобы получить возможность публикации и обмена моделями из их интерфейса.
• Нет процесса согласования: стадии жизненного цикла переключаются вручную (не PLM).
• Связи ограничены иерархией, пока без BOM и where-used.

Onshape: создание и хранение в единой среде

Onshape радикально отличается от обоих подходов: здесь нет файлов. Данные хранятся в облачной базе данных: каждый документ — это объект со своими атрибутами, а связи между документами хранятся как граф ссылок. Это означает, что система «знает» не только о существовании детали, но и о том, где она используется, от чего зависит и что зависит от неё.

Как это работает:

Каждое изменение документа создаёт microversion — неизменяемый объект, который хранит ссылку на предыдущую версию и дельту-изменение. Ничего не перезаписывается: история накапливается как цепочка microversions. Это даёт бесконечную историю и возможность отката к любому моменту.

Документ в Onshape — это контейнер, который хранит части, сборки, чертежи, BOM и другие данные в одном месте. Документы могут ссылаться друг на друга, создавая связи между проектами.

В Onshape невозможно создать дубликат. Файл не может «потеряться» или «разойтись» с оригиналом, потому что файлов нет. Есть документ и ссылки в базе данных.

Плюсы:

• Единственный источник истины: нет дубликатов, нет «какая версия правильная».
• Неблокирующая работа: несколько инженеров могут одновременно редактировать одну модель.
• Автоматическое версионирование: каждое действие записывается, ничего не теряется при потере соединения.
• Встроенный PDM: управление данными — часть CAD, а не отдельная система.

Минусы:

• Полная зависимость от облака: данные хранятся только на серверах Onshape (AWS). Нет On-Premise, нет локальной копии.
• Проприетарность: вы не можете экспортировать «базу данных» — только отдельные модели в стандартных форматах.
• SaaS-модель: при прекращении подписки доступ к данным ограничивается.
• Только Onshape-документы: система не управляет STL из других CAD как «полноценными» объектами.

Сравнение подходов

А что выбрали вы и какие компромиссы считаете несущественными? Поделитесь :)