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

Когда лет 5 назад мы спросили коллег, где ваше место в CAP, они не нашли, что ответить. И понятно почему. Нигде. Если возникает разделение, то кластер просто разваливается. Система становится и не доступна, и не консистентна. Для решения периодически (иногда) расчётов в памяти, особенно для решения исследовательских задач, это не страшно.

Сейчас, когда есть потоковая обработка для вычислений во времени близком к реальному (малый объем горячих данных в памяти) и пакетная распределённая обработка для расчётов на больших объемах (исторических данных на дисковых массивах) место гридов вообще не понятно. С учётом того, что они они не очень толерантны к падениям узлов и задержкам.

на сях был MPI
загрузить все в память надо откуда-то. соответственно время загрузки может быть чудовищным..
исследовательские задачи да согласен. ну так нет таких тулов которые не сгодятся в этих задачах. это 360* направлений…

В исследовательских задачах применяют все если/где надо.
Мне кажется аргумент что штука X там все же сгодится очень специфичный.

Использование грида в качестве распределенного кэша. Не?

Оффтоп, но все же:
Вот почему абсолютно разные понятия, в разных сферах, средствами арго приводят в одно звучание/написание? Я минуту пытался понять что тут написанно выше, так как до этого вышел из беседы про банки, где в том числе был разговор и про "кэш" т.е. "кэш флоу" по счету. 🤦‍♂ Я в печали.

Ну может увидев англоязычное написание, быстро бы переключился. Хотя все еще ужаснее с "печеньками" будет, если до этого рецепты обсуждать, а потом в баузеры и веб переключиться. Звоночек, может пора завязывать с ИТ.

А почему не распределённый кэш в качестве распределённого кэша?

Если дополнительно можно будет хранить не только ключ-значение, а ещё и табличные данные с возможностью использовать sql, а ещё и агрегаты считать, то не вижу почему от этого надо отказываться

У архитектора должна быть хорошая фантазия :) была бы возможность, а то как это применить всегда можно придумать

Альтернативы есть всегда, вопрос компромисса. Проще быстрее, дешевле

Какие конкретно кейсы, когда необходимо выполнять SQL поверх кэша и когда нужно считать агрегаты на данных из кэша? Причём, такие кейсы, когда других альтернатив нет

кол-во лайков и просмотры на ютубе именно так и считаются