Я работал над приложением для построения графиков / обработки данных ( вы можете увидеть скриншот здесь ), используя Clojure (хотя часто мне кажется, что я использую больше Java, чем Clojure), и начал тестировать мое приложение с большими наборами данных. У меня нет проблем с примерно 100 тысячами очков, но когда я начинаю подниматься выше этого уровня, я сталкиваюсь с проблемами кучи.
Теперь, теоретически, около половины ГБ должно быть достаточно для хранения около 70 миллионов дублей. Конечно, я делаю много вещей, которые требуют некоторых накладных расходов, и на самом деле я могу одновременно хранить 2-3 копии данных в памяти, но я еще не оптимизировал много, и 500k или около того все еще * На 1005 * порядков меньше, чем я должен быть в состоянии загрузить.
Я понимаю, что у Java есть искусственные ограничения (которые могут быть изменены) на размер кучи, и я понимаю, что они могут быть частично изменены с помощью параметров, которые вы можете указать при запуске JVM. Это приводит меня к моим первым вопросам :
Могу ли я изменить максимально допустимое пространство кучи, если я использую Swank-Clojure (через Leiningen), который JVM имеет при запуске?
Если я упакую это приложение (как я планирую) как Uberjar, смогу ли я убедиться, что у моей JVM есть какое-то минимальное пространство кучи?
Но я не довольствуюсь тем, что полагаюсь на кучу JVM для поддержки моего приложения. Я не знаю размера данных, с которыми я мог бы в конечном итоге работать, но он мог достигнуть миллионов пунктов, и, возможно, куча не могла вместить это. Поэтому мне интересно найти альтернативы тому, чтобы просто накапливать данные. Вот несколько идей, которые у меня были, и вопросы о них:
Можно ли было бы читать только части большого (текстового) файла за раз, чтобы я мог импортировать и обрабатывать данные в виде "кусков", например, n строк за раз? Если так, то как?
Есть ли какой-нибудь более быстрый способ доступа к файлу, из которого я буду читать (потенциально быстро, в зависимости от реализации), кроме простого чтения из него поочередно? Полагаю, я спрашиваю здесь какие-либо советы / хаки, которые работали для вас в прошлом, если вы делали подобное.
Могу ли я "пробовать" из файла; например читать только каждые z строк, эффективно уменьшая мои данные?
Прямо сейчас я планирую, если будут ответы на вышеперечисленное (я буду продолжать поиск!), Или предложения, предлагаемые, которые приводят к эквивалентным решениям, считывать порцию данных за раз, отображать их на временной шкале ( см. Скриншот - шкала времени выделена зеленым) и позволяла пользователю взаимодействовать только с этим битом, пока он не нажмет next chunk (или что-то еще), затем я сохраню изменения, внесенные в файл, и загрузлю Следующий «кусок» данных и его отображения.
В качестве альтернативы, я бы отображал всю временную шкалу всех данных (с пониженной выборкой, чтобы я мог их загрузить), но разрешал бы доступ только к одному «чанку» за раз в главном окне (той части, которая просматривается). выше зеленой временной шкалы, как обведено прямоугольником области просмотра на временной шкале).
Больше всего хотя есть ли лучший способ ? Обратите внимание, что я не могу уменьшить выборку данных основного окна, так как мне нужно иметь возможность обрабатывать их и позволить пользователю взаимодействовать с ними (например, щелкните точку или рядом с ней, чтобы добавить «маркер» к этой точке: этот маркер отображается как вертикальное правило над этой точкой).
Буду признателен за любые идеи, ответы, предложения или исправления! Я также готов разъяснить
на мой вопрос любым способом, который вы хотели бы.
Мы надеемся, что это будет, по крайней мере, частично, с открытым исходным кодом; Мне нужен простой в использовании, но быстрый способ создания xy-графиков с большим количеством данных в мире Clojure.
EDIT Понижение частоты возможно только при построении графика, а не всегда, в зависимости от графических элементов.Мне нужен доступ ко всем данным для анализа.(Просто проясните это!) Хотя я определенно должен рассмотреть вопрос о понижающей дискретизации, я не думаю, что это решит мои проблемы с памятью в меньшей мере, поскольку все, что я делаю для построения графиков, это рисование на BufferedImage.