Хранилище данных для больших данных моделирования астрофизики - PullRequest
2 голосов
/ 29 июня 2011

Я аспирант по астрофизике.Я запускаю большие симуляции, используя коды, в основном разработанные другими в течение десяти лет или около того.Для примеров этих кодов вы можете проверить гаджет http://www.mpa -garching.mpg.de / gadget / и enzo http://code.google.com/p/enzo/. Это, безусловно, два наиболее зрелых кода (они используют разные методы).

Результаты этих симуляций огромные .В зависимости от вашего кода ваши данные немного отличаются, но это всегда большие данные.Обычно вы берете миллиарды частиц и клеток, чтобы сделать что-нибудь реалистичное.Самые большие прогоны - это терабайты на снимок и сотни снимков на симуляцию.

В настоящее время кажется, что лучший способ для чтения и записи такого рода данных - это использование HDF5 http://www.hdfgroup.org/HDF5/,, который в основном являетсяорганизованный способ использования бинарных файлов.Это огромное улучшение по сравнению с неформатированными бинарными файлами с пользовательским блоком заголовка (все еще дающим мне ночные кошмары), но я не могу помочь, но думаю, что мог бы быть лучший способ сделать это.

Я представляю большой размер данныхпроблема в этом, но есть ли какое-то хранилище данных, которое может эффективно обрабатывать терабайты двоичных данных, или двоичные файлы - единственный способ на данный момент?

Если это помогает, мы обычно храним данные по столбцам.То есть у вас есть блок всех идентификаторов частиц, блок всех положений частиц, блок скоростей частиц и т. Д. Он не самый красивый, но самый быстрый для выполнения чего-то вроде поиска частиц в некотором объеме.

edit: Извините за расплывчатость в вопросах.Стив прав, что это может быть просто проблемой структуры данных, а не метода хранения данных.Мне нужно бежать сейчас, но я предоставлю больше деталей поздно вечером или завтра.

edit 2: Так что чем больше я смотрю на это, тем больше я понимаю, что это, вероятно, непроблема хранилища данных больше.Основная проблема с неформатированным двоичным файлом заключалась в том, что все проблемы с чтением данных были правильными (правильное определение размеров и порядка блоков, а также уверенность в этом *1027*).HDF5 в значительной степени исправил это, и не будет более быстрого варианта, пока не будут улучшены ограничения файловой системы (спасибо Мэтту Терк).

Новые проблемы, вероятно, сводятся к структуре данных.HDF5 настолько эффективен, насколько это возможно, даже если это не самый лучший интерфейс для запроса.Привыкнув к базам данных, я подумал, что было бы действительно интересно / мощно иметь возможность запрашивать что-то вроде «дай мне все частицы со скоростью выше x в любое время».Вы можете сделать что-то подобное сейчас, но вы должны работать на более низком уровне.Конечно, учитывая, насколько велики данные и в зависимости от того, что вы с ними делаете, было бы неплохо работать на низком уровне ради производительности.

1 Ответ

4 голосов
/ 29 июня 2011

EDIT

Обоснование моего отсутствия объяснения / и т. Д .:

  • ОП говорит: «[HDF5] - огромное улучшение по сравнению с неформатированными двоичными файлами с настраиваемым блоком заголовка (все еще дают мне ночные кошмары), но я не могу не думать, что может быть лучший способ сделать это». 1021 *

Что значит "лучше"? Лучше структурированы? Кажется, он ссылается на «неформатированные бинарные файлы» как на проблему - так что, возможно, именно это он и имеет в виду. Если это так, ему понадобится что-то с какой-то структурой - отсюда и первая пара предложений.

  • ОП говорит: «Я полагаю, что проблема заключается в большом размере данных, но есть ли какое-то хранилище данных, которое может эффективно обрабатывать терабайты двоичных данных, или двоичные файлы - единственный способ на данный момент?»

Да, их несколько. И структурированные, и «неструктурированные» - хочет ли он структуры, или он счастлив оставить их в каком-то «неформатированном двоичном формате»? Мы до сих пор не знаем - поэтому я предлагаю проверить некоторые распределенные файловые системы.

  • ОП говорит: «Если это помогает, мы обычно храним данные по столбцам. То есть у вас есть блок всех идентификаторов частиц, блок всех положений частиц, блок скоростей частиц и т. Д. Это не самый красивый, но это самый быстрый для выполнения чего-то вроде поиска частиц в каком-то объеме. "

Опять же, ОП хочет улучшить структуру или нет? Похоже, он хочет и того, и другого - лучшей структуры И быстрее .... возможно, масштабирование OUT даст ему это. Это еще более усиливает первые несколько вариантов, которые я перечислил.

  • OP говорит (в комментариях): «Я не знаю, сможем ли мы принять удар на io».

Есть ли требования к IO? Стоимость ограничения? Кто они такие?

Мы не можем получить что-то здесь даром. Не существует решения для хранения «серебряной пули». Все, что нам нужно здесь для требований - это «много данных» и «я не знаю, нравится ли мне отсутствие структуры, но я не хочу увеличивать свой ввод-вывод для размещения какой-либо дополнительной структуры» ... так Я не знаю, какой ответ он ожидает. Он не перечислил ни одной жалобы на текущее решение, которое у него есть, кроме отсутствия структуры - и он уже сказал, что не готов платить какие-либо накладные расходы, чтобы что-то с этим сделать ... так что ...?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...