Розыск: нужен более-менее универсальный бинарный формат

[Rosik]

На работе встала проблема: нужно хранить данные из программы.
Программа занимется физикой и хранит много разных массивов, да и не только массивов.
Идеологически подходит XML, но мне не нравится текстовое представление данных. Скроковых переменных у меня раз два и обчелся. Массивы достаточно большие. Один файл весит по несколько метров, что также отпугивает от XML.

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

[Чистый]

БД в виде SQLite ? Есть blob тип данных храни что угодно

[Rosik]

Смотрел на SQLite когда-то раньше, сейчас посмотрел еще раз.
Если я не ошибаюсь, то любые БД работают только с таблицами.
Мне не хватает чего-то типа атрибутов в XMLе.
Вот пример. У меня есть тело, заданное массивом точек, и у тела есть физические параметры, масса например.
Причем массив один, а параметров много, и они имеют древовидную структуру (тел несколько, но их объединяет аттрибут уровнем выше - ускорение свободного падения).
С этой точки зрения мне проще массив сделать плоским и смотреть на него как на еще один атрибут.

[ArcFi]

А что мешает хранить метаданные в xml/plain-text, а массив — бинарно?

[Чистый]

берешь xml формируешь и суешь в blob sqlite, потом от туда достаешь и работаешь как с обычным xml ну или как ArcFi,
 предлагает

[Rosik]

ArcFi,
Неудобно, много отдельных файлов, потеряется итд.
Ну например, для каждого тела есть свой массив координат. Если массив лежит в отдельном файле то нужно следить кто есть кто.
Метаданные тоже хотелось бы в бинарном виде хранить (дабы не терять точность double), хотя этим "хотелось" в крайнем случае можно пренебречь.
Пользователь решил продолжить мысль 06 Июня 2013, 15:49:14:Чистый, Утка в зайце, или как там =)
Вообще щас подумалось что идея ArcFi весьма неплохая, если в tar все завернуть.
Файлики нумеровать не проблема, надо над технической стороной подумать и понять как с tar контейнером работать

[ArcFi]

А можно не заморачиваться и просто хранить в одном месте пару файлов с одинаковым именем и расширениями dat и xml.

[Progger]

ArcFi,
Неудобно, много отдельных файлов, потеряется итд.
Ну например, для каждого тела есть свой массив координат. Если массив лежит в отдельном файле то нужно следить кто есть кто.
Метаданные тоже хотелось бы в бинарном виде хранить (дабы не терять точность double), хотя этим "хотелось" в крайнем случае можно пренебречь.
Пользователь решил продолжить мысль 06 Июня 2013, 15:49:14:Чистый, Утка в зайце, или как там =)
Вообще щас подумалось что идея ArcFi весьма неплохая, если в tar все завернуть.
Файлики нумеровать не проблема, надо над технической стороной подумать и понять как с tar контейнером работать

Я для подобной задачи использовал zip - XML и однородные массивы хорошо сжимаются

[Rosik]

ArcFi,
тогда их будет 10 а не 2.
Все-таки лучше 10 в тар, чем 9 в бинарный dat - это помойка получится. А от такого dat и до собственного формата с метаданными недалеко

Progger,
Ну мне тогда tar.gz нужен, но гзип не так необходим, поэтому просо тара хватит.
А средства / библиотеки не подскажите? Как с зипом работали?

[rapidsp]

А разве иерархию нельзя представить плоскими таблицами?

[Чистый]

zlib

[Rosik]

rapidsp,
Вопрос риторический. При хорошем воображении наверное можно, но зачем сложное дерево представлять плоской таблицей?
Пользователь решил продолжить мысль 06 Июня 2013, 16:20:30:Чистый, спасибо, щас поизучаю

[ArcFi]

Rosik, т.е. каждую структуру данных можно представить в виде 1 — xml и 9 — dat, так?
И сколько таких структур планируется гененировать в день/месяц/год?
Как долго их требуется хранить?

[Dixi257]

Я когда-то обрабатывал гигабайты данных (модели облучённости больших площадей). От бинарного формата отказался сразу, ибо сложности возникали с интерфейсами к сторонним программам стат. обработки/анализа. Данные сжимал кусками zlib и складывал в файлы.

[Rosik]

ArcFi,
Я тогда с самого начала расскажу.
Программа решает нестационарные гидродинамические задачки.
Данный тип файлов используется для запуска расчета (входные параметры), и для сохранения результатов (каждые 100-1000 шагов) и последующей обработки / рисования картинок.

Структура, которую надо хранить, это один временной шаг. Она включает в себя массив вихрей (x y интенсивность), массив тепловых элементов (x y интенсивность), еще несколько аналогичных массивов точек (не буду вдаваться в подробности), и несколько тел. Это нулевой уровень. У нулевого уровня есть еще набор "атрибутов", например текущее время, число Рейнольдса, гравитация и еще несколько параметров. Атрибутов всего штук 15, их набор меняется только при добавлении нового функционала, крайне редко.

Под первым уровнем дерева я имею в виду N тел. Их количество может варьироваться от задачи к задаче. У каждого тела также есть атрибуты. Их штук 10, включая массу и координаты начала, и они тоже не меняются.

Такие файлы генерируются в количестве ~1000 штук на задачку. По 2-3 метра файлик
Я их смотрю, строю картинки, потом удаляю. Некоторые избранные моменты сохраняю на долгую память. Именно поэтому хочется на один шаг иметь один файл. Что касается массивов (гипотетически dat), то их у меня не больше N+4 штук, парочка иногда пустует. Тел обычно 1-3, XML получается один для каждого шага по времени.