Разработка своего формата

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

Как минимум, намного читабельней и меньше. Парсер/генератор проще и быстрей. При необходимости, легко преобразовать в тот-же xml

Правильно ли я понял, что Restas будет переписан в xml-подобном стиле, или вопрос был чисто риторический, для поддержания разговора?

> Как минимум, намного читабельней и меньше.

Насчёт читабельность это ещё вопрос, в xml, как минимум, больше выразительных средств.

правильно ли я понял, что Restas будет переписан в xml-подобном стиле

Ну, он именно с этого начинался, когда я портировал своё старое решение с C++ на CL, но это было давно и не имеет отношения к предмету обсуждения, ибо restas это не формат данных.

>не имеет отношения к предмету обсуждения, ибо restas это не формат данных

Но его код записан с использованием s-expressions. И если вы считаете это менее удобно чем xml, то я и уточнил ваши дальнейшие планы. :-)

> Но его код записан с использованием s-expressions.

Работа с кодом отличается от работы с данными, поэтому подобное сравнение не уместно. Но, кстати, писать XSLT-преобразования, где код представлен в виде xml, довольно таки удобно.

я и уточнил ваши дальнейшие планы.

Я использую CL не потому, что в восторге от его синтаксиса (скорей наоборот, предпочитаю C-подобный синтаксис), но свой код я стараюсь писать так, что бы его смогли понять другие CL-программисты, что исключает возможность использования другого типа синтаксиса.

> MongoDB

Есть ли что-нибудь подобное, но без сервера аля sqlite?

Обычно встраиваемые ведь работают внутри одного процесса с клиентским приложением. Это значит что клиентское приложение может вызвать падение этого процесса. Потому встраиваемые не могут обеспечить подходящий уровень надежности.

Вообще встраиваемые БД необходимы только для простого разворачивания на клиентской машине или юнит-тестирования. Если у вас перманентная серверная инсталляция, которую еще может обслуживать специалист, то встраиваемая не нужна. MongoDB действительно хороший и простой в использовании NoSQL. Выбор JavaScript как языка общения с БД крайне удачен, высокая масштабируемость, надежность и производительность. Если данные имеют структуру как у ТС, то это именно то что надо

Сам скоро перехожу на MongoDB

http://www.sqlite.org/

Чем они лучше xml?

Тем, что избыточность меньше, удобнее читать и писать руками, нет идиотских закрывающих тегов.

Самый большой профит от использования XML это возможность использования технологий типа XPath/XQuery/XSLT, отказываясь от подобного способа структурирования информации

Если оно так надо, то есть дубовое решение. Что-то типа (xml->xexpr (xquery (xexpr->xml xexpr) ... )) ...

> Тем, что избыточность меньше

Это не аргумент.

удобнее читать

Это не так.

удобнее ... и писать рукам

Откройте для себя nxml-mode

нет идиотских закрывающих тегов

Зато много идиотских скобочек. Не аргумент.

> есть дубовое решение

Костыль?

Это не так.

так

Откройте для себя nxml-mode

это костыль

> так

Можете попробовать провести опрос и удивиться результатам.

nxml-mode

это костыль

Серьёзно? Можно поподробней?

Серьёзно? Можно поподробней?

Если для нормальной работы с текстовым форматом надо использовать какие-то спецрежимы и спецредакторы, то фтопку такой формат.

Я правильно понял мысль, что Emacs не нужен? У него так много разных режимов для разных типов файлов (включая лисп)....

Я конечно пользуюсь емаксом, но я не хочу от него зависеть. Многоскобочный формат я могу редактировать где угодно и на чем угодно.

> Многоскобочный формат я могу редактировать где угодно

и на чем угодно.

Как и xml. Редактор, который не подсвечивает парные скобки, мало годится для редактированяи s-выражений. Ещё очень желательно, что бы он хотя бы правильные отступы делал. Вообще, сам факт наличия ParEdit и т.п. как бы намекает.

> Стандартным парсером ваши табуляции до значений не раскручиваются.

Распарсить строчку и обработать ошибки мегасложная задача, дооооо. Вообще у меня сейчас уже есть вариант программы c Ъ XML и «XML по недоразумению», файлы второго варианта получаются в разы меньше, но я все же остановлюсь на первом варианте т.к. он более самодокументирован. Как вариант посмотрю еще YAML. А вот bson в этом плане действительно недоразумение...

теоретики :)

http://www.hdfgroup.org/HDF5/

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

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

С тем что мне надо и как это сделать я более чем определился, и хотел затем просто приделать оптимизацию по размеру, но сейчас я понял, что это плохая идея, а все предложенные альтернативы (возможно за некоторыми исключениями) не лучше. Всем спасибо!

HDF и netcdf как варианты не рассматривались?

Идея насчет БД интересная. Ситуация такая: непосредственно данные (на файл) порядка 1-2Мб, аннотация порядка 100Кб (~5-10%). Нужно в одном файле хранить одновременно данные и аннотацию. По этой причине:

1) не выйдет ли так, что присобаченная к каждому файлу маленькая база данных будет занимать больше места, чем XML+табличка_с_разделителями_где_это_надо?

Зачем? БД - одна на все данные с аннотациями, аттрибутами, чем угодно. Нужен какой-то файл в виде «<block time=„1000“ size=„1000“ offset=„0“ marks=»" comment=«»/>"? Пишете соответствующий SQL-запрос а-ля:

select concat('<block time="', T.time, '" size="', T.size, '" offset="', , T.offset, '" marks="', T.marks, '" comment="', T.comments, '"/>') from my_table T where ...; 

и наслаждаетесь своим xml-ем. Это если наскоряк нужно. Если постоянно - пишете скриптик или приблуду, принимающие различные параметры и т.д. БД рулит.

> У нас с одного расчета валится дцать Гб бинарных данных, диск чуть успевает писать. Как это в БД сувать и зачем?

непосредственно данные (на файл) порядка 1-2Мб, аннотация порядка 100Кб (~5-10%). Нужно в одном файле хранить одновременно данные и аннотацию.

В год будут записываться несколько тысяч новых файлов.

=> БД

И правда немного.

В общем надо привлечь хорошего спеца по БД, который смогет настроить достаточно устойчивую систему, с бэкапами зеркалированием и пр. фигней, способную пережить отключение электричества, текущие кондеры в серверной, прорыв отопления этажом выше и банальную кражу железа. Сделать аналогичные вещи руками на файлах можно но ИМНО не нужно - все таки БД в этом смысле ИМНО больше проработаны...

thread from hell. даже лисп присоветовали. тех кто хранит данные в xml не для межпрограммного взаимодействия надо заставлять носить одежду из нескольких слоев поролона. тех кто использует лисп в продакшне не будучи корпорацией надо заставлять есть ножом суп. ну а тех кто советует в sqlite хранить большие объемы я даже отказываюсь понимать. А у ТСа явно избыток свободного времени раз ему всякая фигня в голову лезет

> Сейчас я думаю сделать хранение таких участков в виде «delimiter-separated values» для разделения значений использовать специально предназначенные для этого символы (U+001F, U+001E).

Вы изобрели CSV - comma separated values - но со своим разделителем ;)