Например, у моего пользователя есть большой файл (несколько GB).
Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще).
Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке.
Естественно, алгоритм должен быть параллельным.
Вижу проблемы:
1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются.
2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для
этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
Или "облака" для этого не предназначены? И тогда нужен "кластер"?
Здравствуйте, GhostCoders, Вы писали:
GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются. GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
Все уже давно придумано. В случае ажура, к примеру, называется azure storage.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"?
Предусмотрены, ровно как и не в облаках. Там обычный IP у каждой машины, ставишь любое удобное решение и вперед. Ну а всякие готовые PaaS/SaaS уже зависят от конкретики — Storage/SQL/NoSQL/Message Bus/etc.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, GhostCoders, Вы писали:
GC>Например, у моего пользователя есть большой файл (несколько GB). GC>Он хочет его как-то обработать с использованием моей службы, запущенной, скажем в Azure (или где-то еще). GC>Обработка этого файла, скажем, на одном компе (локальном) заняла бы несколько суток. Допустим, там тяжелые вычисления.
GC>Хотелось бы это дело ускорить используя несколько (или несколько десятков\сот\тысяч) узлов в облаке. GC>Естественно, алгоритм должен быть параллельным. GC>Вижу проблемы: GC>1) В передачи входных данных от пользователя на все запущенные узлы. Это случай когда входные данные дублируются. GC>2) В случае если входные данные распиливать на небольшие части, проблема в распилке. Кто это будет делать? Допустим, будет какой-то выделенный для GC> этого узел, "монитор". Монитор, собственно, должен синхронизировать работу остальных узлов.
GC>Вопрос: Вообще, синхронизация, обмен данными между узлами предусмотрены в "облаках"? GC>Или "облака" для этого не предназначены? И тогда нужен "кластер"?
на такую задачу проситься hadoop кластер. допустим в google cloud заказываешь 400 VMs с предустановленным хадупом и запускаешь map-reduce таск, после расчета убиваешь кластер. счет будет лишь за затраченное кластером время. файл порубит и раскидает по нодам map-reduce фреймворк по сути автоматом. файл кластер может читать/писать прямо с гугловского сториджа, через какие-то коннекторы.
альтернативный вариант hadoop + spark, еще есть варианты server less: spark или map-reduce job можно запускать не создавая отдельный кластер.
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, GhostCoders, Вы писали:
GC>>Например, у моего пользователя есть большой файл (несколько GB).
S>Это всё вместе выглядело как задача, которая может быть не для облака, а для GPU. Зависит, конечно, от конкретной задачи, но тем не менее.
GPU В облаках тоже есть и их там можно набрать штук 10, например.
