Комментарии 8
Может стоит рассказать что это вообще за проект и что он делает. Чтобы понять что именно ускоряется. И чем лучше, например, какой-нибудь системы контроля версий для исторических исследований
В статье есть утверждения типа «значительно снизит потребление ОЗУ» и что-то про неэффективность другого подхода и ускорение, но я так нигде и не увидел цифр, которые бы наглядно показали читателю каких результатов удалось добиться.
У меня раньше, когда я использовал findAll() типа List<T>, NodehistJ мог сожрать огромное количество ОЗУ (требовался сервер с 8+ Гб ОЗУ). Потом перешёл на пагинацию - но это приводило к замедлению уже на стороне СУБД (из за LIMIT+OFFSET), и нодлисты могли грузиться по несколько часов (на слабых серверах) из за полного перебора по всему БД. Сейчас же индексация проходит намного шустрее, и не требует значительного объема ОЗУ (NodehistJ требует теперь 3-4 гига ОЗУ, из за своей микросервисной сущности).
Сервер для фидо, жрущий 8гб.. Вот они современные технологии!

Ну, сейчас оно где-то 2 гига жрёт в чистую. И то это связано с микросервисной архитектурой, где нужно несколько раз пихать практически один и тот же спринговый контекст в ОЗУ.
Индексация же сейчас проходит намного быстрее - в среднем, индексация диффов на Cloud.ru Free Tier, без managed DBMS, занимает 5 минут максимум.
Сейчас проект перевожу на GraalVM, и очень надеюсь, что это снизит расход ОЗУ на порядок. Уже сейчас GraalVM позволило уменьшить размер Docker-образа за счёт использования native build вместо JRE, а если будет ещё и значительное уменьшение траты ОЗУ, будет вообще класс.

Ускоряем индексацию нодлистов Фидонета при помощи Java Streams и Spring Data JDBC: перебираем нодлисты прямиком с СУБД