Я посмотрел на CCR, DSS и Erlang, хотя из них я отправил только CCR в значительный производственный код. Я никогда не смотрел на Hadoop.
Параллельность Эрланга вытекает из его реализации модели Actor. Каждый «процесс» имеет почтовый ящик и извлекает из него сообщения, по одному за раз. Процесс без сообщений для обработки блоков без потока. И наоборот, процессы, над которыми нужно работать, планируются на доступном процессоре, и ни один из базовых механизмов не отображается. Кроме того, процессы обмениваются сообщениями с помощью клонирования / неизменности, гарантируя, что P1 и P2 никогда не будут логически обмениваться сообщениями, которые передаются между ними.
Мне кажется, что неблокирующая природа отправки и получения сообщений дает Erlang репутацию масштабируемой на одной (возможно, многоядерной) машине. По сути, процессы, над которыми нужно работать, эффективно распределяются между доступными ресурсами, а процессы в состоянии покоя занимают только память. Обрабатывая по одному сообщению за раз, каждое из которых гарантирует стабильность сообщения, разработчику больше не нужно беспокоиться о таких вещах, как «условия гонки».
CCR - это набор низкоуровневых асинхронных примитивов передачи сообщений. Одним из более простых является прием, который получает а-ля Эрланг. Но есть и более сложные примитивы, такие как Join (получение сообщения по всем некоторым каналам) и Choice (получение сообщения по любому из некоторых каналов), которые могут быть вложенными и составленными интересными способами. Эти примитивы также неблокирующие. Получатели генерируют задачи (для обработки сообщений) в очереди задач 1..n, которые обслуживаются небольшим количеством потоков.
Я предполагаю, что, игнорируя (важно!) Различия в платформах, основные процедуры планирования задач каждой из них находятся в основном в одном и том же парке. Тем не менее, Erlang - это язык и платформа с фиксированной (актерской) моделью. CCR - не из этих вещей, а просто библиотека, и вы можете использовать / злоупотреблять ею более свободно.
DSS - это модель программирования, основанная на CCR. У него есть сервисы (Erlang = процессы), он предписывает асинхронную передачу сообщений (с полным клонированием по умолчанию) в качестве единственной формы межсервисной связи, и единственный дескриптор, который внешний сервис имеет для сервиса, - это его URI (Erlang = PID) , Как и в случае с Erlang, между вызовом локальной и удаленной службы, по сути, нет разницы, хотя в последнем случае происходит (де) сериализация.
DSS также имеет модель RESTful, что означает, что службы обычно предоставляют фиксированный и общий набор операций, и что состояние службы следует рассматривать как ресурс, управляемый этими операциями. Сравните это с Erlang, где произвольные сообщения могут быть отправлены процессу. Службы DSS могут использовать полный набор примитивов CCR при взаимодействии с другими службами, что может быть очень полезно для таких вещей, как распределенные операции сбора рассеяния.
В конечном счете, DSS - это просто платформа с поддержкой библиотек, а не языка или виртуальной машины, поэтому в написании даже одной службы DSS значительно больше «церемоний», чем в написании процесса Erlang.
С точки зрения параллелизма, все предоставляют примитивы, необходимые для написания кода, который является безопасным и эффективным при нескольких потоках выполнения, не беспокоясь об этих потоках выполнения. Я думаю, что именно к этому стремится большинство разработчиков.
С точки зрения масштабируемости ответить сложнее, так как это касается как проектирования системы, так и используемых инструментов. Вы имеете в виду масштабируемость на одном узле, то есть когда вы добавляете ядра или когда вы добавляете узлы? CCR ничего не говорит о последнем. И DSS, и Erlang поддерживают довольно эффективные двоичные форматы для проводной передачи. DSS наследует свое ресурсно-ориентированное представление о мире непосредственно из http, что должно сказать вам кое-что о его потенциальной масштабируемости, но оно делает это с некоторыми ограничениями в модели программирования.
Пара технических моментов. Одна служба DSS потребляет больше памяти (~ 2 КБ), чем один процесс erlang (300-400 байт). Кроме того, каждая служба DSS получает свою очередь задач, и существует верхний предел (~ 10000) количества очередей задач, которые могут быть эффективно обработаны CCR. У меня нет чисел на любых таких верхних границах для Эрланга, но подозреваю, что это может быть выше, чем это.
Сказав все это, если вы работаете на платформе .NET, вы сделаете себе одолжение, серьезно взглянув на CCR. Я обнаружил, что он очень мощный, особенно для программ, реагирующих на события.