Binary xml representation

Когда ты говоришь «XML» что конкретно ты имеешь в виду?

zip подойдет?

Бери gzip, хорошо работает, поддерживается где угодно. Будешь слать по http, там вообще на уровне протокола

gzip не подойдёт, так как только уменьшает размер файла, а время парсинга, записи и поиска только увеличивается

http://www.w3.org/TR/2006/REC-xml11-20060816/

Бинарный аналог XML используется в медиаконтейнере Matroska.

* dev-libs/libebml
Available versions: 0.7.8-r1 (~)0.7.8-r2 0.8.0 1.0.0 (~)1.2.0 (~)1.2.1
Homepage: http://www.matroska.org/
Description: Extensible binary format library (kinda like XML)

Также, судя по гуглу, есть бинарый XML:
* dev-libs/libwbxml
Available versions: 0.10.1 (~)0.10.9 {test}
Homepage: http://libwbxml.opensync.org/
Description: Library and tools to parse, encode and handle WBXML documents.

А вам критично именно XML? Есть Apache Thrift или Google Protobuf с невероятной скоростью сериализации

>А вам критично именно XML? Есть Apache Thrift или Google Protobuf с невероятной скоростью сериализации

на данный момент в базе хранятся гигабайты валидного XML. Хочется уменьшить объём хранимых данных и ускорить с ними работу.

Для JSON есть собственно BSON, успешно используется для хранения кортежей в MongoDB

поддерживаю. pure C и xml? зачем?

а может быть проблема вооще в том, что он там хранится?

>pure C и xml? зачем?

очевидно, чтобы быстро работало хранилище данных, которым можно легко и непринуждённо делится с другими приложениями не выдумывая никаких лишних API

>Google Protobuf с невероятной скоростью сериализации

Then you compile it with protoc, the protocol buffer compiler, to produce code in C++, Java, or Python.

Нет Pure c

не верю, что ты получишь такое уж преимущество. Особенно при сложной работе с текстом - тут на pure C можно написать в разы медленее, чем даже на python.

Думаю что вполне можешь посмотреть на С++ (не целиком, а только на работу со строкам)

>> pure C и xml? зачем?

очевидно, чтобы быстро работало хранилище данных, которым можно легко и непринуждённо делится с другими приложениями

Си++ работает так же быстро, как и Си. Впрочем, для protobuf есть и компилятор в Си.

> Нет Pure c

Есть: http://code.google.com/p/protobuf-c/

> Особенно при сложной работе с текстом - тут на pure C можно написать в разы медленее, чем даже на python.

в разы больше надо будет писать - да, а вот работать будет гораздо быстрей

в базе хранятся гигабайты валидного XML. Хочется уменьшить объём хранимых данных и ускорить с ними работу.

может вам просто базу сменить ? а-ля специальные Berkeley DB XML и sedna..или универсалы а-ля Oracle 10g, IBM DB2

>Си++ работает так же быстро, как и Си. К сожалению, при всей моей любви к этому языку, он непригоден для промышленной разработки ПО

Впрочем, для protobuf есть и компилятор в Си.

У меня есть пунктик, не использовать программы версии 0.14beta1 в разработке, результатами которой пользуются больше ста человек

>может вам просто базу сменить ? а-ля специальные Berkeley DB XML

Всё хранится в Berkeley DB XML

>> Си++ работает так же быстро, как и Си.

К сожалению, при всей моей любви к этому языку, он непригоден для промышленной разработки ПО

Серьезный подход. Ну, удачи в промышленной разработке на Си.

> Ну, удачи в промышленной разработке на Си.

Язвите? В моём проекте основная разработка идёт на Python. На си пишется только та часть, которая должна работать быстро.

> в разы больше надо будет писать - да, а вот работать будет гораздо быстрей

Не всегда. Надо очень аккуратно подходить к вопросам выделения/освобождения памяти, обработки по кускам и тд

> в разы больше надо будет писать - да, а вот работать будет гораздо быстрей

вот что-то мне говорит, что не выиграете вы этим ничего.

Или потратите кучу времени и получите пшик

>> Ну, удачи в промышленной разработке на Си.

Язвите?

Слегка. Обычно при «промышленной разработке» противопоставляются Си++ и какой-нибудь managed-язык, но не Си++ и Си.

основная разработка идёт на Python

Hint: zip-модуль Python написан на Си, XML-модуль - тоже :)

Ну и Python-обертки к protobuf хорошо протестированы в Гугле, так что я не понимаю возражение против Си++ здесь.

Всё хранится в Berkeley DB XML

и оптимизировать вы хотите именно работу с базой как я понимаю. Если BDB вам нехватило, то «Бинарный XML» каким-бы он ни был уже не поможет :)

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

Можно переехать на sedna как простую клиент-сервер базу близкую к BDB, и разместить хранилище на отдельной машине. Но тоже профит невысок.

В общем, где-то вам в своей архитектуре/алгоритмах надо шороху наводить, раз Berkeley DB XML оказалось узким местом. Разделите данные на 2-3 независимые базы, добавьте уровень кеширования, сами схемы XML оптимизируйте под частые запросы и так далее.

>Hint: zip-модуль Python написан на Си, XML-модуль - тоже :)

Ну и Python-обертки к protobuf хорошо протестированы в Гугле

У меня есть быстрый легковесный демон написанный на Си, работающий с данными, которые представляют собой XML и работающий быстро. Задача: сделать так, чтобы он работал ещё быстрее.

Я правильно понимаю, что вы предлагаете всунуть в этот демон Python-support и protobuf для решения этой задачи?

>и оптимизировать вы хотите именно работу с базой как я понимаю.

Про работу с базой речь не идёт. Я хочу обрабатывать данные, которые я из этой базы уже вытянул.

> У меня есть быстрый легковесный демон написанный на Си, работающий с данными, которые представляют собой XML и работающий быстро. Задача: сделать так, чтобы он работал ещё быстрее.

Это немного не та задача, с которой началось обсуждение.

Я правильно понимаю, что вы предлагаете всунуть в этот демон Python-support и protobuf для решения этой задачи?

Я вообще ничего не предлагал для задачи, сформулированной таким образом. Но лично я начал бы не с поиска сверхбыстрой библиотеки работы с двоичным XML, а с профилирования. Просто чтобы знать, не уперся ли ты в IO, и, если да, то попробовать то, что предложили в во втором же посте.

>лично я начал бы не с поиска сверхбыстрой библиотеки работы с двоичным XML, а с профилирования. Просто чтобы знать

По результатам работы callgrind 10% времени занимает доступ к БД 16% работа с памятью и 42% времени работа по сериализации/десериализации/поиску в XML

> 10% времени занимает доступ к БД 16% работа с памятью и 42% времени работа по сериализации/десериализации/поиску в XML

10+16+42 == 68, т.е. 32% знимает ожидание ввода? Можно пробовать zip (если его можно хранить в базе). Ну и хорошо бы знать, как раскладываются эти 42% между сериализацией и поиском, чтобы понять, поможет ли тебе быстрый парсер вообще.

17% от 42-х - сериализация остальное примерно равномерно распределено между другими вызовами библиотеки работы с XML

Могу предложить формат ASN.1. Компилятор asn1c для PureC.

> 17% от 42-х

Даже если это 17% от общего времени (а не 0.17 * 0.42 == 0.07 общего времени), и ты ускоришь парсер в 2 раза, выигрыш будет невелик.

Сначала zip, потом, если ускорения не хватит или его вообще не будет, то улучшение алгоритмов.

Кстати, поиск ты делаешь в DOM?

и 42% времени работа по сериализации/десериализации/поиску в XML

почему поиском занимается не БД ? это её непосредственные обязанности и она у вас тупо простаивает («10% времени занимает доступ к БД»)

>Кстати, поиск ты делаешь в DOM? Да

>почему поиском занимается не БД ? формат данных произвольный, задаётся пользователем сколь угодно сложный. Было решено хранить в базе as is, а парсить на выходе.

>> Кстати, поиск ты делаешь в DOM?

Да

Я не силен в XML, но вроде это не самый быстрый способ? На крайний случай, строй свои структуры через SAX и ищи в них руками.

Было решено хранить в базе as is, а парсить на выходе.

то есть в базе де-факто лежат raw данные? и о том что это xml знают только избранные лица, которые и строят из них DOM для поиска..