Комментарии 14
Как Ignite соотносится с Akka? Похоже, что Ignite < Akka, но вопрос рекомендаций — в каких случаях применять Ignite?
Я не знаю Akka, но читал сравнения
Разница в концепте:
Akka — distributed actors
Ignite — distributed closures
Akka и Erlang для реалтайма. Они быстро гоняют сообщения между нодами.
Т.е. используются в Massively Concurrent Application.
Ignite гоняет код между нодами, т.е. это для MapReduce и BigData
В Ignite есть Zero Deployment. (нет необходимости деплоить код на все ноды, сам расползается)
В Erlang нет zero deploymenta. (Но можно сделать через метапрограмминг)
Не знаю есть ли он в Akka. Думаю что нет.
В Ignite есть много другой функциональности: distributed caching, service grid, streaming, etc.
Затрудняюсь ответить есть ли она в Akke.
Разница в концепте:
Akka — distributed actors
Ignite — distributed closures
Akka и Erlang для реалтайма. Они быстро гоняют сообщения между нодами.
Т.е. используются в Massively Concurrent Application.
Ignite гоняет код между нодами, т.е. это для MapReduce и BigData
В Ignite есть Zero Deployment. (нет необходимости деплоить код на все ноды, сам расползается)
В Erlang нет zero deploymenta. (Но можно сделать через метапрограмминг)
Не знаю есть ли он в Akka. Думаю что нет.
В Ignite есть много другой функциональности: distributed caching, service grid, streaming, etc.
Затрудняюсь ответить есть ли она в Akke.
Ignite и Akka слишком разные продукты, чтобы знаки неравенства между ними ставить. Достаточно взглянуть на API.
Ignite — это распределенная SQL+noSQL БД в памяти + map/reduce и прочие виды кластерных вычислений.
Akka решает несколько другие задачи, насколько я понимаю.
Ignite — это распределенная SQL+noSQL БД в памяти + map/reduce и прочие виды кластерных вычислений.
Akka решает несколько другие задачи, насколько я понимаю.
Тысячу лет назад GridGain позиционировался как IMDG — грубо говоря распределенная мапа, «все данные в памяти». Прошло много лет, они уже ушли от этого термина, но в-целом главный юзкейс остается прежним — данные, распределенные по узлам в виде ключ-значение (лучшего пока не придумали), которые можно обрабатывать локально на узле. Если бы автор не использовал расшаренный диск, то правильным сценарием было бы — распределить данные по узлам, запустить код, обрабатывающий данные, а локальность (affinity) была бы достигнута автоматически
П.с. не туда ответил, веткой выше хотел
П.с. не туда ответил, веткой выше хотел
Маленькие поправки внесу для pom.xml: секция repositories не нужна, зависимости вытягиваются из апачевского репозитория; для ignite-spring и ignite-examples м.б. версия 1.4.0 (не уверен реально нужна ли зависимость на examples)?
Так а сколько по времени занял тот же объём работы, но уже распределённо?
Для распараллеливания выполнения процессов можно использовать еще gearman
Интересно, пиши еще про другие распределенные штуки, только исходники можно в спойлеры заворачивать?
Спасибо за статью, главное преимущество GG — их специализированный classloading through network, в противном случае деплоймент был бы геморойным.
Только вот что такое «кастовать»? Ужасное слово, режет слух, во всем программном мире «cast» понимается как «приводить тип» все-таки, а не что-то иное
Только вот что такое «кастовать»? Ужасное слово, режет слух, во всем программном мире «cast» понимается как «приводить тип» все-таки, а не что-то иное
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Параллельный парсинг большого количества HTML-страниц с помощью Apache Ignite (GridGain) в 200 строк кода