Как манипулировать * огромными * объемами данных

Question

У меня следующая проблема. Мне нужно хранить огромное количество информации (~ 32 ГБ) и иметь возможность манипулировать ею как можно быстрее. Мне интересно, как лучше всего это сделать (комбинации языка программирования + ОС + все, что вы считаете важным).

Структура информации, которую я использую, представляет собой массив 4D (NxNxNxN) с плавающей запятой двойной точности (8 байт). Сейчас мое решение состоит в том, чтобы разделить массив 4D на двумерные массивы и сохранить их в отдельных файлах на жестком диске моего компьютера. Это действительно медленно и манипулирование данными невыносимо, так что это совсем не решение!

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

Альтернативное решение, о котором я думаю, - это купить выделенный сервер с большим количеством оперативной памяти, но я не знаю точно, решит ли это проблему. Поэтому сейчас мое невежество не позволяет мне выбрать лучший путь.

Что бы вы сделали, если бы оказались в такой ситуации? Я открыт для любой идеи.

Заранее спасибо!

---

РЕДАКТИРОВАТЬ: Извините, что не предоставил достаточно информации, я постараюсь быть более конкретным.

Я храню дискретизированную математическую функцию 4D. Операции, которые я хотел бы выполнить, включают транспонирование массива (изменение b [i, j, k, l] = a [j, i, k, l] и т.п.), умножение массива и т. Д.

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

---

РЕДАКТИРОВАТЬ (2):

Я также хотел бы иметь возможность хранить больше информации в будущем, поэтому решение должно быть как-то масштабируемым. В настоящее время цель 32 ГБ состоит в том, что я хочу иметь массив с N = 256 точками, но было бы лучше, если бы я мог использовать N = 512 (что означает 512 ГБ для его хранения !!).

Answer 1

Экстремальный большой экземпляр Amazon с большой памятью составляет всего $ 1,20 / час и имеет 34 ГБ памяти . Это может оказаться полезным, если вы не запускаете эту программу постоянно ..

Answer 2

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

Посетите Википедию, чтобы получить описание и решить, может ли это удовлетворить ваши потребности: http://en.wikipedia.org/wiki/Sparse_matrix

Answer 3

Если вы можете представить свою проблему как MapReduce, рассмотрите систему кластеризации, оптимизированную для доступа к диску, такую ​​как Hadoop.

Ваше описание звучит более математически, и в этом случае вы, вероятно, захотите, чтобы все ваши данные были в памяти сразу. 32 ГБ ОЗУ на одной машине не является необоснованным; Amazon EC2 предлагает виртуальные серверы до 68 ГБ.

Answer 4

Как указал Крис, что вы собираетесь делать с данными.

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

Answer 5

Любой достойный ответ будет зависеть от того, как вам нужен доступ к данным. Случайный доступ? Последовательный доступ?

32ГБ не так уж и огромен.

Как часто вам нужно обрабатывать ваши данные? Один раз в (время жизни | год | день | час | наносекунда)? Часто вещи нужно делать только один раз. Это сильно влияет на то, сколько вам нужно для оптимизации вашего решения.

Какие операции вы будете выполнять (вы упоминаете умножение)? Можно ли разбить данные на куски так, чтобы все необходимые данные для набора операций содержались в чанке? Это облегчит разделение для параллельного выполнения.

Большинство компьютеров, которые вы покупаете в эти дни, имеют достаточно ОЗУ для хранения ваших 32 ГБ в памяти. Для этого вам не понадобится суперкомпьютер.

Answer 6

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

Answer 7

Вот еще одна идея:

Попробуйте использовать SSD для хранения ваших данных. Поскольку вы собираете очень небольшие объемы случайных данных, SSD, вероятно, будет намного, намного быстрее.

Answer 8

Пока есть много разных ответов. Есть две хорошие отправные точки, упомянутые выше. Дэвид предлагает кое-какое оборудование, а кто-то упомянул об изучении С. Оба эти аспекта хороши.

C даст вам то, что вам нужно с точки зрения скорости и прямой подкачки памяти. Последнее, что вы хотите сделать, это выполнить линейный поиск данных. Это будет медленно - медленно - медленно.

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

Answer 9

Без дополнительной информации, если вам нужен как можно более быстрый доступ ко всем данным, которые я бы использовал, используя C для вашего языка программирования, используя некоторую разновидность * nix в качестве O / S и покупая RAM, сейчас это относительно дешево. Это также зависит от того, с чем вы знакомы, вы также можете пойти по маршруту Windows. Но, как уже упоминали другие, это будет зависеть от того, как вы используете эти данные.

Answer 10

Как обрабатывать большие объемы данных, как правило, зависит от следующих факторов:

• Порядок доступа к данным / местность ссылок: можно ли разделить данные на независимые порции, которые затемобрабатывается независимо или в последовательном / последовательном режиме против произвольного доступа к данным с небольшим или нулевым порядком?

• CPU против ввода / вывода:время обработки, потраченное больше на вычисления с данными или чтение / запись их из / в хранилище?

• Периодичность обработки: Будут ли данные обрабатываться только один раз, каждые несколько недель, ежедневно и т. д.?

Если порядок доступа к данным в основном случайный, вам потребуется либо получить доступ к как можно большему объему оперативной памяти, и / или найти способ хотя бы частичной организации порядка, чтобы нестолько же данных должно находиться в памяти одновременно.Системы виртуальной памяти замедляются очень быстро после того, как физические ограничения ОЗУ превышены и происходит значительный обмен.Решение этого аспекта вашей проблемы, вероятно, является наиболее важной проблемой.

Кроме проблемы с порядком доступа к данным, приведенной выше, я не думаю, что ваша проблема связана со значительными проблемами ввода-вывода.Чтение / запись 32 ГБ обычно измеряется в минутах в современных компьютерных системах, и даже размер данных до терабайта не должен превышать нескольких часов.

Выбор языка программирования на самом деле , а не критичны, если это скомпилированный язык с хорошим оптимизирующим компилятором и достойными нативными библиотеками: C ++, C, C # или Java - все это разумный выбор.Самое вычислительное и интенсивное программное обеспечение для ввода-вывода, над которым я работал, на самом деле было на Java и развернуто на высокопроизводительных суперкомпьютерных кластерах с несколькими тысячами ядер ЦП.