Какие можно использовать технологии/форматы для хранения бинарных пользовательских данных в десктопном приложении?

Question

[FatumFL]

Десктопное приложение с функциями Second Brain / Personal Project Management / Personal Knowledge Management / Document Management System / Media-Photo Library Management / Virtual Board.
Хочется хранить весь профиль пользователя (то, что обычно называют Vaults или Spaces в похожих приложениях) включая бинарные файлы (библиотеки изображений, мультимедиа, документов и т.п. файлов) в едином файле с быстрым доступом, вместо иерархии папок на файловой системе.
Какие есть варианты? Архив без сжатия, динамический виртуальный диск vhdx (наверное, самый близкий к желаемому функционалу вариант)? Объектные хранилища по типу MinIO? Не очень бы, конечно, хотелось для полностью десктопного приложения использовать работающие по архитектуре сервер-клиент технологии, может есть некие автономные объектные хранилища?

Comments

[Дмитрий]

А чем файловая система не угодила?

[shurshur]

Вообще-то файловая система - наиболее эффективное хранилище для таких задач.

1. Легко масштабируется, бэкапится.
2. Эффективно кэшируется операционной системой.
3. Множественный конкурентный доступ к разным файлам этой большой базы без каких-либо спецэффектов.
4. Риск повреждения данных минимальный. Разве что повреждается тот файл, который не успел записаться в момент ёк-ёк.

Архив это плохо - он по сути на каждую операцию изменения файла пересоздаётся заново. И если что - весь архив отлетает со всеми данными.

Минио на каждый файл создаёт каталог, внутри которого файл (возможно, зашифрованный) и json с метаданными - тут объектов файловой системы ещё больше, чем при обычном хранении файлов.

Виртуальный диск - это прям из пушки по воробъям. Проще и даже надёжнее тогда хранить файлы в sqlite, которая, к слову, может иметь формальный размер до 281 Тб (да, именно террабайт). Но база огромного размера это тоже не очень удобно.

Как правило, нормальная практика - хранить метаданные в sqlite (а может berkeleydb или ещё какой-нить локальной базе), сами файлы - в файлах. Как и написано в том вот ответе внизу. Сами имена файлов могут быть сколь угодно эзотерическими (какие-нить 16-ричные без расширения).

Иногда делают специфические решения под специфические задачи. Два примера приведу.

Первый пример - формат mbtiles. Придумали для тайловых данных (TMS) веб-карт, где много тайликов размера 256x256. Представляет из себя sqlite, в котором лежат эти файлы. Для чего используют? Во-первых, для обмена - много софта умеет собирать файлы в такой архивчик. Во-вторых, можно с помощью нарезания на таблицы и создания view оптимизировать хранение тайлов с одинаковым содержанием, что для читающего софта будет прозрачно. Но для приличного продакшн-решения mbtiles напрямую не используют, всё равно раскатывают в файлики.

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

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

[d'Ivan]

shurshur, вот это да! Мега-комментарий! И мега-скромность (ведь скрыто от глаз)!

Answer 1

[d'Ivan]

Хочется хранить весь профиль пользователя (то, что обычно называют Vaults или Spaces в похожих приложениях) включая бинарные файлы (библиотеки изображений, мультимедиа, документов и т.п. файлов) в едином файле с быстрым доступом, вместо иерархии папок на файловой системе.

Хранить в архивах ZIP, TAR/PAX, конечно, можно, но не сильно удобно: вместо работы с файлами придётся работать с библиотеками для работы с архивами: то записать в архив, то прочесть с него. С точки зрения производительности вряд ли будет столь же эффективно, как с файловой системой (даже с иерархией папок).

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

В настольных приложениях общие настройки и данные хранят в /etc , /usr/share , /usr/lib (Linux) , пользовательские - согласно спецификациям XDG и в Windows - в своих директориях.

Медиа-файлы, конечно, должны быть доступны приложению простым образом, без необходимости писать/читать в/из архив(а). Особенно, если необходимо запустить ассоциированное с типом файла внешнее приложение, как видео-проигрыватель.

Более гибкий вариант: использовать SQLite или какую-то K/V СУБД (тот же Redis!). В добавок к кросс-платформенности получаем возможность простым API работать с данными, не занимаясь мелочью типа открыть-закрыть файл, (де)сериализовать данные (настройки всякие), записать/прочесть блок данных. Ими занимается драйвер СУБД (обычно библиотека) и сама СУБД.

Дополнительный гибридный вариант - использовать файлы локально и удалённо (с SDK): допустим с каким-нибудь объектным хранилищем, по протоколу S3 или другому. Как вариант, даже, использовать драйвер VFS для прозрачной работы с неким хранилищем, которое с точки зрения настольного приложения будет работать, как обычная ФС.

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

Answer 2

[alexalexes]

sqlite - для хранения метаданных файлов и виртуальных путей расположения (с точки зрения внутренней логики приложения).
Плюс физический каталог media для сохранения содержимого файлов в одном или нескольких подкаталогах, рассортированных по расширению (виду контента), с именем в виде уникального хеша (хеш записывается в метаданные в качестве ссылки на media).
По-моему, это самое распространенное решение, если взглянуть на внутренности популярных мессенджеров.

Answer 3

[uvelichitel]

В posix системах архивы принято держать и распространять в формате tar. Бинарный архив без сжатия https://ru.wikipedia.org/wiki/Tar При желании можно сжать, получится .tar.gz Пользуюсь ежедневно.