есть ощущения что где то косячим, но пока непонятно где

само по себе хранение в памяти еще не гарантирует скорости, надо этой памятью правильно пользоваться

H2 (которая внутри каждой ноды игнайта обрабатывает SQL) не создавался как аналитическая СУБД, мягко говоря

внутри Ignite SQL насколько я помню это Map Reduce на кучке H2, но внутри ноды там нет никакого параллелизма, и если у вас не огромный кластер то больших скоростей не ждите

ну и потом все СУБД, даже самые дисковые, очень любят и умеют использовать память, так что игнайт может выиграть только когда все точно в памяти, когда план не очень сложный, и если запросы с селективными where-clause - когда есть индексы

а есть тут живые пользователи вот этого? https://docs.cubonacci.com/

Если все - таки это у вас косяк и после фикса станет все супер быстро работать, то, пожалуйста, опишите что было не так и что сделали, чтобв стало так.

Потому что я тоже ковыряд ignite года 2 назад для примерно этих же целей и быстрых скоростей не получил вообще. Но мне не сильно надо было, поэтому я не стал особо ковырять.
А так вообще интересно было бы услашть реальные кейсы построения очень быстрой отчётности на игнайте, потому что у меня есть ощущение, что слишком много у них маркетинга про суперскорость...

обязательно, сейчас ковыряем в сторону структуры таблицы

да, почитаешь их сайт и складывается впечатление что он супер быстрый и серебряная пуля)

Поясните пож что имеется ввиду? Почему плохо паблишить fat jar?

отсюда вот https://github.com/sbt/sbt-assembly#publishing-not-recommended

У нас их ливи батч оператор забирает из нексуса, чтобы толкнуть на кластер.

bullshit

1. сэднесс вызывает
2. Если кто-то решить это испольловать как зависимость в общем случае это проблема - решил сувать в артифактори- суй как пакет тогда

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

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

Вообще зависимости можно передавать в pom формате для спарковских джобов. И они сами будут подтягиватьсч, но это опять же не всегда работает (закрытый   сетевой контур, например)

в 2020 как раз время думать о каких-то мегабайтах

В авс трафик платный)

Если внешний

сидеть в aws и думать о мегабайтах внешнего трафика, тоже так себе занятие

чо за изврат тягать артефакт в авс извне?
разве сложно CI с артефактницей в ec2 засунуть?