Как управлять *огромный* объемы данных
У меня есть следующая проблема. Я должен сохранить огромные объемы информации (~32 ГБ) и смочь управлять им максимально быстро. Я задаюсь вопросом, что лучший способ состоит в том, чтобы сделать это (комбинации языка программирования + ОС + независимо от того, что Вы думаете его важное).
Структура информации, которую я использую, 4D массив (NxNxNxN) двойных-precission плаваний (8 байтов). Прямо сейчас мое решение состоит в том, чтобы нарезать 4D массив в 2D массивы и сохранить их в отдельных файлах в жестком диске моего компьютера. Это действительно медленно, и управление данными невыносимо, таким образом, это не решение вообще!
Я думаю при перемещении в Супервычислительное средство в моей стране и храню всю информацию в RAM, но я не уверен, как реализовать приложение для использования в своих интересах его (я не профессиональный программист, таким образом, любая книга/ссылка поможет мне много).
Альтернативное решение, на котором я думаю, состоит в том, чтобы купить выделенный сервер с большим количеством RAM, но я не знаю наверняка, если это решит проблему. Таким образом, прямо сейчас мое незнание не позволяет мне выбрать лучший способ продолжиться.
Что Вы сделали бы, если бы Вы были в этой ситуации? Я открыт для любой идеи.
Заранее спасибо!
Править: Извините за не предоставление достаточной информации я попытаюсь быть более конкретным.
Я храню дискретизированный 4D математическая функция. Операции, которые я хотел бы выполнить, включают перемещение массива (измените b [я, j, k, l] = [j, я, k, l] и подобные), выстройте умножение и т.д.
Поскольку это - моделирование предложенного эксперимента, операции будут применены только однажды. После того как результат получен это привычка быть необходимым выполнить больше операций на данных.
РЕДАКТИРОВАНИЕ (2):
Я также хотел бы смочь хранить больше информации в будущем, таким образом, решение должно быть так или иначе масштабируемым. Текущая цель на 32 ГБ состоит в том, потому что я хочу иметь массив с точками N=256, но будет лучше, если я могу использовать N=512 (что означает 512 ГБ хранить его!!).
14 ответов
Если вы можете представить свою проблему как MapReduce, рассмотрите систему кластеризации, оптимизированную для доступа к диску, например Hadoop.
Ваше описание кажется более сложным с математической точки зрения, и в этом случае вы, вероятно, захотите хранить все свои данные в памяти одновременно. 32 ГБ оперативной памяти в одной машине не лишено смысла; Amazon EC2 предлагает виртуальные серверы объемом до 68 ГБ.
Amazon's "High Memory Extra Large Instance" стоит всего $1.20/hr и имеет 34 GB памяти. Вы можете найти это полезным, если вы не запускаете эту программу постоянно...
Вся технология баз данных заключается в манипулировании огромными объемами данных, которые не помещаются в ОЗУ, так что это может быть вашей отправной точкой (т.е. получить хорошие базы данных книгу принципов и прочтите об индексировании, выполнении запросов и т. д.).
Многое зависит от того, как вам нужно получить доступ к данным - если вам абсолютно необходимо прыгать и получать доступ к случайным частям информации, у вас проблемы, но, возможно, вы сможете структурировать свою обработку данных таким образом, что вы будете сканировать его по одной оси (измерению). Затем вы можете использовать буфер меньшего размера и постоянно выгружать уже обработанные данные и читать новые данные.
Можно ли это решить таким способом?
Сначала создайте M дочерних процессов и выполните их паралельно. Каждый процесс будет выполняться на выделенном ядре кластера и загружать некоторую информацию из массива в оперативную память этого ядра.
Отцовский процесс будет менеджером массива, вызывая (или подключая) соответствующий дочерний процесс для получения определенных фрагментов данных.
Будет ли это быстрее, чем подход с хранением на жестком диске? Или я раскалываю орехи кувалдой?
.Без дополнительной информации, если вам нужен максимально быстрый доступ ко всем данным, я бы использовал C для вашего языка программирования, используя некоторую разновидность * nix как O / S и покупка RAM, сейчас это относительно дешево. Это также зависит от того, с чем вы знакомы, вы также можете пойти по маршруту Windows. Но, как уже упоминали другие, это будет зависеть от того, как вы используете эти данные.
На данный момент существует множество очень разных ответов. Есть две хорошие отправные точки, упомянутые выше. Дэвид предлагает какое-нибудь оборудование, и кто-то упомянул об изучении C. Оба эти момента являются хорошими моментами.
C даст вам то, что вам нужно, с точки зрения скорости и прямого разбиения памяти на страницы. Последнее, что вам нужно сделать, это выполнить линейный поиск данных. Это будет медленно - медленно - медленно.
Определите свой рабочий процесс - если ваш рабочий процесс линейный, это одно. Если рабочий процесс не является линейным, я бы разработал двоичное дерево, ссылающееся на страницы в памяти. В Интернете есть масса информации о B-деревьях. Кроме того, с этими B-деревьями будет намного проще работать на C, поскольку вы также сможете настраивать и управлять разбивкой по страницам памяти.
Для транспонирования быстрее просто изменить свое понимание того, что есть индекс. Под этим я подразумеваю, что вы оставляете данные там, где они есть, и вместо этого оборачиваете делегат доступа, который изменяет b [i] [j] [k] [l] ] в запрос на выборку (или обновление) ] a [j] [i] [k] [l] .
Как указал Крис, что вы собираетесь делать с данными.
Кроме того, я думаю, что хранить его в (реляционной) базе данных будет быстрее, чем читать с жесткого диска, поскольку СУБД выполнит для вас некоторые оптимизации, например кэширование.
Любой достойный ответ будет зависеть от того, как вам нужно получить доступ к данным. Произвольный доступ? Последовательный доступ?
32 ГБ - это не так уж и много.
Как часто вам нужно обрабатывать свои данные? Один раз за (время жизни | год | день | час | наносекунду)? Часто дело нужно сделать только один раз. Это сильно влияет на то, сколько вам нужно для оптимизации вашего решения.
Какие операции вы будете выполнять (вы упомянули умножение)? Можно ли разбить данные на части, чтобы все данные, необходимые для набора операций, содержались в одном фрагменте? Это упростит разделение для параллельного выполнения.
Большинство компьютеров, которые вы покупаете в наши дни, имеют достаточно оперативной памяти, чтобы вместить 32 ГБ памяти. Для этого вам не понадобится суперкомпьютер.
В зависимости от того, как вы используете, некоторые математические и физические проблемы, как правило, сводятся к нулю (например, модели с конечными элементами). Если вы ожидаете, что это будет верно для ваших данных, вы можете получить серьезную экономию места, используя разреженную матрицу вместо фактического хранения всех этих нулей в памяти или на диске.
Посмотрите описание в Википедии и решите, может ли это удовлетворить ваши потребности: http://en.wikipedia.org/wiki/Sparse_matrix
Вот еще одна идея:
Попробуйте использовать SSD для хранения данных. Поскольку вы собираете очень небольшие объемы случайных данных, SSD, вероятно, будет намного быстрее.
Вы можете попробовать использовать mmap вместо чтения данных в память, но я не уверен, что это будет работать с файлами размером 32 ГБ.
Первое, что я бы порекомендовал, - это выбрать объектно-ориентированный язык и разработать или найти класс, который позволит вам управлять четырехмерным массивом без забота о том, как это на самом деле реализовано.
Фактическая реализация этого класса, вероятно, будет использовать файлы с отображением памяти просто потому, что они могут масштабироваться от машин разработки с низким энергопотреблением до реальной машины, на которой вы хотите запускать производственный код (я предполагаю, что вы захотите запускать это много раз, поэтому производительность важна - если вы можете позволить ему работать на ночь, тогда может быть достаточно обычного ПК).
Наконец, как только мои алгоритмы и данные будут отлажены, я хотел бы выиграть время на машине, которая могла бы хранить все данные в памяти. Amazon EC2 , например, предоставит вам машину с 68 ГБ памяти за 2,40 доллара США в час (меньше, если вы играете со спотовыми инстансами).
Обработка больших объемов данных обычно зависит от следующих факторов:
Порядок доступа к данным / местонахождение ссылки: могут ли данные быть разделены на независимые фрагменты, которые затем обрабатываются либо независимо или последовательно / последовательно vs. произвольный доступ к данным с небольшим порядком или без него?
ЦП против ограничений ввода-вывода: тратится ли время обработки больше на вычисления с данными или их чтение / запись из / в хранилище?
Частота обработки : Будут ли данные обрабатываться только один раз, каждые несколько недель, ежедневно и т. Д.?
Если порядок доступа к данным в основном случайный, вам нужно будет либо получить доступ к как можно большему объему ОЗУ, и / или найти способ хотя бы частично организуйте порядок, чтобы в памяти одновременно находилось не так много данных. Системы виртуальной памяти очень быстро замедляют , когда превышаются ограничения физической памяти и происходит значительная подкачка. Решение этого аспекта вашей проблемы, вероятно, является самой важной проблемой.
Помимо проблемы с порядком доступа к данным, описанной выше, я не думаю, что у вашей проблемы есть серьезные проблемы с вводом-выводом. Чтение / запись 32 ГБ обычно измеряется в минутах в современных компьютерных системах, и даже размер данных до терабайта не должен занимать больше нескольких часов.
Выбор языка программирования на самом деле не критичен, если это скомпилированный язык с хорошим оптимизирующим компилятором и приличными нативными библиотеками: C ++, C, C # или Java - разумный выбор. Программное обеспечение с наибольшей вычислительной нагрузкой и интенсивным вводом-выводом, над которым я работал, на самом деле было на Java и развернуто на высокопроизводительных суперкомпьютерных кластерах с несколькими тысячами ядер ЦП.