Чем в данном случае помогут кеши, при обработке данных в память?
БД тоже врядли будут сравнимы по скорости. На этапе импорта достаточно сильна обратная связь с уже загруженными данными, потому прийдётся как много писать, так и много читать.
Поправте меня, если я не прав.
Товарищи уже отписывались, правда в небольших количествах :)
Правда в том же разделе мы видим, что произведена оптимизация для работы с массивами boolean, которые преобразуются в массив байт, что даёт прирост доступной памяти в 4 раза.
Т.е. по моим данным: 1 байта на 500 000 000 = 500 000 000 / 1024 / 1024 = 476,837158203125 Мб.
А вот, про 5 часов загрузки в память перед вычислениями — Вы ошиблись, как описано в комментариях выше, 5 часов — это полный цикл обработки сырых данных.
Дело в том, что во время повседневного функционирования приложения создание/удаление данных не происходит в таком кол-ве, в котором эти данные в памяти хранятся — замерять работу GC не было особого смысла до сих пор. А переход на битовые массивы не ударил по скорости, поскольку битовые данные носят абсолютно второстепенный характер и используются при построении HTTP ответа.
Касательно статьи с цифрами — посмотрим, что можно сделать.
Исходя из нижеприведенного, я посчитал, что это оптимизация:
Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java virtual machine int data type.
The Java virtual machine does directly support boolean arrays…
Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java virtual machine int data type.
The Java virtual machine does directly support boolean arrays
Хм, ну начнём с того, что эту часть системы создавал не я, хотя на данном этапе отвечаю за неё именно я.
Повествование иногда буду упрощать, дабы не вдаваться в дебри слишком глубоко:
Данные приходят в формате XML, заархивированные. В зависимости от формата архива создаётся дочерний процесс с командой на разархивирование (например «zcat <имя_файла>.gz»), выходной поток которого читается в исходном процессе и парсится. Буферизированные данные ложаться в основном в массивы long и int, хотя некоторая атрибутика кладётся в коллекции — но таких данных не много. Связка данных в основном идёт по индексам соответствующих массивов, но иногда приходится делать вспомагательные «переходные» массивы с индекса одной сущности на индекс другой. Поиск бинарный, т.к. есть возможность создать упорядоченные массивы данных.
Поверте, массив булеанов из 500 миллионов элементов не забивает 15GB RAM.
А касательно: «а надо прибегнуть к каким-то другим схемам данных», я Вам скажу, что массивы простых типов в джава будут занимать гораздо меньше памяти, чем коллекция классов с аналогичными полями
Нет, это обработка огромного кол-ва текстовых данных, как это ни странно :)
Дисковый кеш в данном случае служит только для подъёма новых инстансов сервера. Т.е. импортированные единожды данные позволяют запускать несколько веб серверов. Потоковая же обработка затруднена тем, что на данном этапе обработка зависит от уже полученных данных — т.е. пока не удалось построить алгоритм, который бы использовал потоковую обработку (в несколько этапов/прогонов, чтобы учесть зависимость данных) при суммарной разумной скорости всей операции.
Реимпорт естественно проходит единожды при поступлении новых данных, правда данные очень часто обновляются.
Иногда даже спички стоит считать. Да и задача, как понятно из топика, стояла запустить остановленный сервер в короткое время. Для этого оптимизация boolean[] -> BitSet подходит просто идеально.
Как я и написал, под «запуском» в данном топике я подразумевал полный цикл запуска. Старт веб-сервера, конечно проходит за секунды (точных значений даже не знаю, поскольку они всех устраивают), а вот импорт и препроцессинг отъедают порядка 5ти часов.
Вы действительно думаете, что на ПХП будет быстрее/легче?
БД тоже врядли будут сравнимы по скорости. На этапе импорта достаточно сильна обратная связь с уже загруженными данными, потому прийдётся как много писать, так и много читать.
Поправте меня, если я не прав.
Товарищи уже отписывались, правда в небольших количествах :)
Т.е. по моим данным: 1 байта на 500 000 000 = 500 000 000 / 1024 / 1024 = 476,837158203125 Мб.
А вот, про 5 часов загрузки в память перед вычислениями — Вы ошиблись, как описано в комментариях выше, 5 часов — это полный цикл обработки сырых данных.
Касательно статьи с цифрами — посмотрим, что можно сделать.
Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java virtual machine int data type.
The Java virtual machine does directly support boolean arrays…
The Java virtual machine does directly support boolean arrays
Повествование иногда буду упрощать, дабы не вдаваться в дебри слишком глубоко:
Данные приходят в формате XML, заархивированные. В зависимости от формата архива создаётся дочерний процесс с командой на разархивирование (например «zcat <имя_файла>.gz»), выходной поток которого читается в исходном процессе и парсится. Буферизированные данные ложаться в основном в массивы long и int, хотя некоторая атрибутика кладётся в коллекции — но таких данных не много. Связка данных в основном идёт по индексам соответствующих массивов, но иногда приходится делать вспомагательные «переходные» массивы с индекса одной сущности на индекс другой. Поиск бинарный, т.к. есть возможность создать упорядоченные массивы данных.
Еще вопросы?
А касательно: «а надо прибегнуть к каким-то другим схемам данных», я Вам скажу, что массивы простых типов в джава будут занимать гораздо меньше памяти, чем коллекция классов с аналогичными полями
Дисковый кеш в данном случае служит только для подъёма новых инстансов сервера. Т.е. импортированные единожды данные позволяют запускать несколько веб серверов. Потоковая же обработка затруднена тем, что на данном этапе обработка зависит от уже полученных данных — т.е. пока не удалось построить алгоритм, который бы использовал потоковую обработку (в несколько этапов/прогонов, чтобы учесть зависимость данных) при суммарной разумной скорости всей операции.
Реимпорт естественно проходит единожды при поступлении новых данных, правда данные очень часто обновляются.