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

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

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

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

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

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

Спасибо заранее!

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

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

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

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

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

Ответ 1

Amazon "High Memory Extra Large Instance" - это $1.20/hr и 34 ГБ памяти. Вам может показаться, что это полезно, если вы не используете эту программу постоянно.

Ответ 2

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

32 ГБ на самом деле не такой огромный.

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ознакомьтесь с википедией для описания и решите, может ли это соответствовать вашим потребностям: http://en.wikipedia.org/wiki/Sparse_matrix

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Вся технология базы данных - это манипулирование огромными объемами данных, которые не могут поместиться в ОЗУ, так что это может быть вашей отправной точкой (т.е. получить хорошую книгу принципов dbms и прочитать об индексировании, выполнении запросов и т.д.). < ш > Многое зависит от того, как вам нужно получить доступ к данным - если вам абсолютно необходимо прыгать и получать доступ к случайным битам информации, у вас проблемы, но, возможно, вы можете структурировать обработку данных таким образом, чтобы вы сканировали ее по одному ось (размерность). Затем вы можете использовать меньший буфер и непрерывно сбрасывать уже обработанные данные и читать новые данные.

Ответ 11

Первое, что я бы рекомендовал, - это выбрать объектно-ориентированный язык и разработать или найти класс, который позволяет вам манипулировать 4-D массивом, не заботясь о том, как это реализовано.

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

Наконец, как только у меня были отлаженные алгоритмы и данные, я бы посмотрел время покупки на машине, которая могла хранить все данные в памяти. Amazon EC2, например, предоставит вам машину с 68 ГБ памяти за $2,40 в час (меньше, если вы играете с точечные экземпляры).

Ответ 12

Для транспозиций это быстрее, чем просто изменить ваше понимание того, что такое индекс. Под этим я имею в виду, что вы оставляете данные там, где они есть, и вместо этого переносите делегата-ассистента, который меняет b[i][j][k][l] на запрос на выборку (или обновление) a[j][i][k][l].

Ответ 13

Можно ли решить эту проблему с помощью этой процедуры?

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

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

Будет ли это быстрее, чем подход к хранению данных на жестком диске? Или я растрескиваю орехи кувалдой?

Ответ 14

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

Порядок доступа к данным/локальность ссылки: можно ли разделять данные на независимые куски, которые затем обрабатываются независимо или в последовательном/последовательном fashon vs. случайном доступе к данным с небольшим или без заказов?
ЦП против привязки ввода/вывода: больше времени на обработку вычисляется с помощью данных или чтения/записи из/в хранилище?
Частота обработки: будут ли данные обрабатываться только один раз, каждые несколько недель, ежедневно и т.д.

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

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

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