Передача вычислений в распределенной системе

[metaclass]

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

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

А вычисления нужно или тащить целиком с кодом и его параметрами или передавать что-то аналогичное thunk(т.е. отложенное ленивое вычисление) в виде вызова "рассчитать значение, обратившись к тому, кто передал").

А поскольку система распределенная - нам никто не обещал, что тот кто передал вычисление, на момент обращения к нему(force), вообще включен, доступен по сети, не накрылся ошибкой и прочим свиным гриппом. И что переданные данные не изменились с момента передачи. Соответственно, в таком случае все вычисления далее могут быть задержаны или же вернуть пользователю вместо ожидаемого отчета о поголовье свиней сообщение об ошибке "Schweine-Zähler Server "DOMAIN\\Zuchtsau001" Verbindung kann nicht hergestellt werden".

А все изменения данных тогда изначально должны поддерживать версионность, т.е. любые предыдущие значения должны быть доступны и идентифицируемы извне.

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

Comments

[lionet.livejournal.com]

AMQP + Erlang.

Или просто Erlang. Мы именно так и делаем: передаём код на другую машину, чтобы он там исполнился, вместе с аргументами (которые являются ссылками на процессы на первой машине).

[vp.livejournal.com]

Дык а как это все кладется на реальный мир, когда задание выполнится, первая машина уже сдохнет-подвиснет и т.п. образом изметит свой контекст по отношению к тому, что ей возвращает вычислитель? :)

[lionet.livejournal.com]

Варианты:

1. Если первой машине всё-таки нужен будет этот результат после окончания процессинга, то:
1.1 если нужно обрабатывать только недолгие подвисания, то и так сойдёт (голый Erlang, у него передача сообщений асинхронно)
1.2 если нужно обрабатывать ребуты, то AMQP + Erlang
2. Если машине не нужен будет результат после окончания процессинга, то нужно просто игнорировать возвращённый результат.
3. Если машине нужен будет результат, но другой (ибо контекст поменялся), то метку контекста можно прилагать к возвращаемому значению, чтобы определить, можно ли результат использовать.

Приведи пример процессинга из жизни, я тебе код набросаю.

[metaclass.livejournal.com]

В ерланге нужный процесс, по идее, после этого переселится на другую ноду и ответ придет ему :)

[lionet.livejournal.com]

да, но не автоматом, а через AMQP можно нарисовать такое.

[potan.livejournal.com]

В Erlang, Mozart/Oz и Alice ML замыкания и прочие хитрые вещи сериализуются.
Еще есть императивный язык E, который, кажется, это то же умеет.

[permea-kra.livejournal.com]

>>А вычисления нужно или тащить целиком с кодом
Это видится невыполнимым?

[metaclass.livejournal.com]

Да не особо, но в моем случае, обычно вычисление это обертка вокруг "select Schwein_ID,Schwein_Name from Schweine where Schweine_Art=?", т.е. еще нужно тащить контекст доступа к БД, причем с того места, где нужен результат вычисления, БД недоступна - оно не в этой подсети, а доступ исключительно через 80 порт и веб-сервисы :)

[rmihael.livejournal.com]

Из более близких к реальному миру языков такое умеет Stackless Python.

[blackyblack.livejournal.com]

Что даст такой подход? В принципе, оно реализуется на Ерланге. Да и на шарпе можно выпендриться - передать кусок кода и выполнить его на другой машине.