Вопрос

Итак, у меня есть «большое» количество «очень больших» ASCII-файлов числовых данных (всего гигабайты), и моей программе придется хотя бы один раз обработать их целиком последовательно.

Есть какие-нибудь советы по хранению/загрузке данных?Я подумал о преобразовании файлов в двоичный формат, чтобы уменьшить их размер и ускорить загрузку.

Должен ли я загрузить все в память сразу?
Если нет, то является ли открытием хорошего способа частичной загрузки данных?
Какие есть советы по повышению эффективности, связанные с Java?

Это было полезно?

Решение

А что, если обработка потребует перебора данных для нескольких файлов и нескольких буферов?Станет ли дорого постоянное открытие и закрытие двоичных файлов?

Я большой поклонник 'ввод-вывод, отображенный в памяти', он же 'прямые байтовые буферы'.На Java их называют Сопоставленные байтовые буферы являются частью java.nio.(По сути, этот механизм использует систему подкачки виртуальной памяти ОС для «сопоставления» ваших файлов и программного представления их в виде байтовых буферов.ОС будет управлять перемещением байтов на/с диска и в память автоматически и очень быстро.

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

Как бы вы использовали MBB в вашем контексте?Просто создайте MBB для каждого из ваших файлов и читайте их по своему усмотрению.Вам останется только сохранить результаты..

КСТАТИ:С каким объемом данных вы имеете дело в ГБ?Если он больше 3-4 ГБ, то на 32-битной машине это не сработает, поскольку реализация MBB является ответчиком адресуемого пространства памяти архитектурой платформы.64-битная машина и ОС позволят вам получить 1 или 128 ТБ отображаемых данных.

Если вы думаете о производительности, познакомьтесь с Кирком Пеппердайном (несколько известным гуру производительности Java). Он участвует в создании веб-сайта www.JavaPerformanceTuning.com, на котором есть еще некоторые подробности MBB: Советы по производительности NIO и другие вещи, связанные с производительностью Java.

Другие советы

Возможно, вам захочется просмотреть записи в Широкий проект Finder (поищите в Google «широкий искатель» Java).

Поиск Wide включает в себя чтение большого количества строк в файлах журналов, поэтому посмотрите реализации Java и посмотрите, что там работало, а что не работало.

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

Может оказаться целесообразным создать какой-то индекс поверх исходных данных ascii, чтобы, если вам понадобится снова просмотреть данные, вы могли бы сделать это быстрее в последующие разы.

Чтобы ответить на ваши вопросы по порядку:

Должен ли я загрузить все в память сразу?

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

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

BufferedReaders/etc является самым простым, хотя вы можете глубже изучить FileChannel/etc, чтобы использовать ввод-вывод с отображением памяти для одновременного просмотра окон данных.

Какие есть советы по повышению эффективности, связанные с Java?

Это действительно зависит от того, что вы делаете с самими данными!

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

  1. Напишите прототип вашего приложения (возможно, даже «тот, который можно выбросить»), который выполняет произвольную операцию с вашим набором данных.Посмотрите, как быстро это происходит.Если самая простая и наивная вещь, которую вы можете придумать, работает достаточно быстро, не беспокойтесь!

  2. Если простой подход не работает, рассмотрите возможность предварительной обработки данных, чтобы последующие прогоны выполнялись в течение приемлемого периода времени.Вы упоминаете, что вам придется довольно часто «прыгать» в наборе данных.Есть ли способ предварительно обработать это?Или одним из шагов предварительной обработки может быть создание еще большего количества данных — индексных данных, которые предоставляют информацию о местонахождении критических и необходимых разделов вашего набора данных с точностью до байта.Затем ваш основной процесс обработки может использовать эту информацию для перехода непосредственно к необходимым данным.

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

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

Это во многом зависит от данных в файле.Большие мэйнфреймы уже давно выполняют последовательную обработку данных, но обычно они не используют произвольный доступ к данным.Они просто вытягивают его по очереди и обрабатывают это, прежде чем продолжить.

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

Вы действительно не предоставили нам достаточно информации, чтобы помочь вам.Вам нужно загружать каждый файл целиком, чтобы его обработать?Или можно обрабатывать построчно?

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

Я считаю Informatica исключительно полезным инструментом обработки данных.Хорошей новостью является то, что более поздние версии даже допускают преобразования Java.Если вы имеете дело с терабайтами данных, возможно, пришло время потратиться на лучшие в своем классе инструменты ETL.

Я предполагаю, что вы хотите что-то сделать с результатами обработки здесь, например, сохранить их где-нибудь.

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

Я рекомендую настоятельно использовать регулярные выражения и изучить «новый» пакет IO nio для более быстрого ввода.Тогда все должно идти настолько быстро, насколько вы реально можете ожидать, что гигабайты данных будут переданы.

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

Если вам нужно получить доступ к данным более одного раза, загрузите их в базу данных.Большинство баз данных имеют своего рода утилиту массовой загрузки.Если все данные могут поместиться в памяти, и вам не нужно их хранить или часто обращаться к ним, вы, вероятно, сможете написать что-нибудь простое на Perl или на вашем любимом языке сценариев.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top