Я аспирант факультета астрофизики. Я запускаю большие симуляции, используя коды, в основном разработанные другими за десятилетие или около того. Примеры этих кодов можно найти на гаджете http://www.mpa-garching.mpg.de/gadget/ и enzo http://code.google.com/p/enzo /. Это определенно два самых зрелых кода (они используют разные методы).
Результаты этих симуляций огромны. В зависимости от вашего кода ваши данные немного отличаются, но это всегда большие данные. Обычно вы берете миллиарды частиц и клеток, чтобы сделать что-то реалистичное. Самые большие прогоны составляют терабайты на снимок и сотни снимков на симуляцию.
В настоящее время кажется, что лучший способ чтения и записи таких данных — использовать HDF5 http://www.hdfgroup.org/HDF5/, который в основном представляет собой организованный способ использования двоичных файлов. Это огромное улучшение по сравнению с неформатированными двоичными файлами с настраиваемым блоком заголовков (до сих пор вызывают у меня кошмары), но я не могу не думать, что может быть лучший способ сделать это.
Я предполагаю, что здесь проблема заключается в чистом размере данных, но есть ли какое-то хранилище данных, которое может эффективно обрабатывать терабайты двоичных данных, или двоичные файлы являются единственным способом на данный момент?
Если это помогает, мы обычно храним данные по столбцам. То есть у вас есть блок всех идентификаторов частиц, блок всех позиций частиц, блок скоростей частиц и т. д. Это не самое красивое, но самое быстрое для выполнения чего-то вроде поиска частиц в некотором объеме.
изменить: извините за расплывчатость в отношении проблем. Стив прав, что это может быть просто проблема структуры данных, а не метода их хранения. Мне нужно бежать сейчас, но я предоставлю более подробную информацию сегодня поздно вечером или завтра.
редактировать 2: Чем больше я изучаю это, тем больше понимаю, что это, вероятно, больше не проблема хранилища данных. Основная проблема с неформатированными двоичными файлами заключалась в головной боли при правильном чтении данных (правильное определение размеров и порядка блоков и уверенность в этом). HDF5 в значительной степени исправил это, и более быстрого варианта не будет, пока ограничения файловой системы не будут улучшены (спасибо Matt Turk).
Новые проблемы, вероятно, сводятся к структуре данных. HDF5 настолько эффективен, насколько это возможно, даже если это не самый лучший интерфейс для запросов. Привыкнув к базам данных, я подумал, что было бы действительно интересно/мощно иметь возможность запрашивать что-то вроде «дайте мне все частицы со скоростью выше x в любое время». Вы можете сделать что-то подобное сейчас, но вам придется работать на более низком уровне. Конечно, учитывая объем данных и то, что вы с ними делаете, было бы неплохо работать на низком уровне ради производительности.
