Оценка HDF5: Какие ограничения/возможности HDF5 предоставляют для моделирования данных?

Мы оцениваем технологии, которые мы будем использовать для хранения данных, которые мы собираем во время анализа кода C/С++. В случае С++ объем данных может быть относительно большим, ~ 20Mb на TU.

После прочтения следующего SO answer он заставил меня подумать, что HDF5 может быть подходящей технологией для нас. Мне было интересно, могут ли люди помочь мне ответить на несколько начальных вопросов, которые у меня есть:

Производительность
. Общее использование данных будет записываться один раз и читать "несколько" раз, аналогично времени жизни файла .o, созданного компилятором. Как HDF5 сравнивается с использованием чего-то вроде SQLite DB? Это даже разумное сравнение?
Со временем мы добавим информацию, которую мы храним, но не обязательно хотим повторно распространять совершенно новый набор "читателей" для поддержки нового формата. После прочтения руководства пользователя я понимаю, что HDF5 похож на XML или DB, поскольку эта информация связана с тегом/столбцом, и поэтому инструмент, созданный для чтения старой структуры, просто игнорирует поля, в которых это не касается? Насколько я понимаю это правильно?
Значительным фрагментом информации, которую мы хотим выписать, будет тип дерева структуры: иерархия областей, иерархия типов и т.д. В идеале мы будем моделировать области с родителями, детьми и т.д. Возможно ли иметь один объект HDF5 "указывает" на другой? Если нет, существует ли стандартная методика для решения этой проблемы с использованием HDF5? Или, как требуется в БД, нужен ли нам уникальный ключ, который "связывает" один объект с другим с соответствующими поисками при поиске данных?

Большое спасибо!

Ответ 1

Как HDF5 сравнивается с использованием чего-то вроде SQLite DB? Это даже разумное сравнение?

Относительно похожего, но не очень. Они оба структурированные файлы. SQLite имеет функции для поддержки запросов к базе данных с использованием SQL. HDF5 имеет функции для поддержки больших научных наборов данных.

Они оба предназначены для высокой производительности.

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

Если вы храните данные в структурированной форме, типы данных этих структур также сохраняются в файле HDF5. Я немного ржавый относительно того, как это работает (например, если оно включает в себя врожденную обратную совместимость), но я знаю, что если вы правильно спроектируете своего "читателя", он должен иметь возможность обрабатывать типы, которые были изменены в будущем.

Возможно ли, чтобы один объект HDF5 "указывал" на другой?

Абсолютно! Вы захотите использовать attributes. Каждый объект имеет одну или несколько строк, описывающих путь для достижения этого объекта. HDF5 groups аналогичны папкам/каталогам, за исключением того, что папки/каталоги являются иерархическими = уникальный путь описывает каждое одно местоположение (в файловых системах с /o жесткие ссылки, по крайней мере), тогда как группы образуют ориентированный граф, который может включать в себя циклы. Я не уверен, можно ли хранить "указатель" на объект непосредственно как атрибут, но вы всегда можете сохранить абсолютный/относительный путь как строковый атрибут. (или где-нибудь еще как строка, вы могли бы найти таблицы поиска, если хотите.)

Ответ 2

Мы производим данные HDF5 по моему проекту, но я не рассматриваю их напрямую. Я могу взять удар по первым двум вопросам:

Мы используем запись один раз, читаем много раз модель, и формат, похоже, справляется с этим. Я знаю проект, который использовался для записи как в базу данных Oracle, так и в HDF5. В конце концов они удалили выход Oracle с тех пор, как пострадали производительность, и никто не использовал его. Очевидно, что SQLite не является Oracle, но формат HDF5 лучше подходит для этой задачи. На основе этой одной точки данных RDBMS может быть лучше настроена для нескольких вставок и обновлений.
Читатели, которых используют наши клиенты, являются надежными при добавлении новых типов данных. Некоторые изменения ожидаются, но нам не нужно беспокоиться о нарушении при добавлении большего количества полей данных. Наш DBA недавно написал программу Python для чтения данных HDF5 и заполнения файлов KMZ для визуализации в Google Earth. Поскольку это был проект, который он использовал для изучения Python, я бы сказал, что не сложно создавать читателей.

По третьему вопросу я поклоняюсь превосходным знаниям Джейсона С..

Я бы сказал, что HDF5 является вполне разумным выбором, особенно если вы уже заинтересованы в нем или планируете что-то сделать для научного сообщества.