Как модель инструментария CCR & DSS сравнивается с другими подходами масштабируемости и совместимости?

Question

Я заинтересован в сравнении различных подходов к масштабируемости. & параллелизм, включая CCR & DSS framework model. Мне было бы особенно интересно сравнить с совпадением стиля Hadoop и Erlang

Answer 1

Я смотрел CCR, DSS и Erlang, хотя из них я отправил только CCR в значительный производственный код. Я никогда не смотрел на Хадоопа.

Параллелизм Erlang происходит от реализации модели Actor. Каждый «процесс» имеет почтовый ящик и получает от него сообщения по одному за раз. Процесс без сообщений для обработки блоков без потока. И наоборот, процессы с выполнением работ запланированы через доступный процессор, при этом ни один из основных механизмов не подвергается воздействию. Кроме того, процессы взаимодействуют посредством передачи сообщений с помощью клонирования/неизменности, гарантируя, что P1 и P2 никогда не логически разделяют сообщения, которые проходят между ними.

Я чувствую, что это неблокирующий характер отправки и получения сообщений, что дает Erlang свою репутацию масштабируемости на одной (возможно, многоядерной) машине. По сути, процессы с выполнением работы эффективно распределяются по доступным ресурсам, а покоящиеся процессы не потребляют ничего, кроме памяти. Обрабатывая одно сообщение за раз, гарантируя стабильность сообщения, разработчику больше не нужно беспокоиться о таких вещах, как «условия гонки».

CCR представляет собой набор примитивных примитивов для передачи асинхронных сообщений низкого уровня. Одним из самых простых является получение, которое получает a la Erlang. Но есть более сложные примитивы, такие как Join (получать сообщение по всем каналам) и Choice (получать сообщение от любого из некоторых каналов), которые могут быть вложены и составлены интересными способами. Эти примитивы также не блокируются. Ресиверы создают задачи (для обработки сообщений) в очереди задач 1..n, которые обслуживаются небольшим количеством потоков.

Мое предположение заключается в том, что, игнорируя (важные!) Различия в платформе, основные процедуры планирования задач каждого из них находятся в основном в одном и том же шаровом парке. Тем не менее, Erlang - это язык и платформа с фиксированной (Actor) моделью, запеченной в. CCR не является ни одной из этих вещей, ее просто библиотекой, и вы можете использовать/злоупотреблять ею более свободно.

DSS является модель программирования, основанная на CCR. Он имеет службы (Erlang = процессы), он предусматривает передачу асинхронного сообщения (с полным клонированием по умолчанию) в качестве единственной формы межсервисной связи, и единственным средством, которым должен обладать внешний мир, является его URI (Erlang = PID) , Как и Эрланг, по существу нет разницы между вызовом локальной службы и удаленной, хотя сериализация (de) происходит в последнем случае.

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

В конечном счете, DSS - это всего лишь инфраструктура с поддерживающими библиотеками, а не язык или виртуальная машина, поэтому существует гораздо больше «церемоний», связанных с написанием даже одной службы DSS, а не написанием процесса Erlang.

С точки зрения параллелизма, все предоставляют примитивы, необходимые для написания кода, который является безопасным и эффективным в соответствии с несколькими потоками исполнения, не беспокоясь об этих потоках исполнения. Я думаю, именно там большинство разработчиков хотят двигаться.

С точки зрения масштабируемости, это более сложный ответ, так как это касается дизайна системы, так как это используемые инструменты. Вы имеете в виду масштабируемость на одном узле, т. Е. При добавлении ядер или при добавлении узлов? CCR нечего сказать о последнем. И DSS, и Erlang поддерживают довольно эффективные двоичные форматы для проводной передачи. DSS наследует свой ресурсо-ориентированный взгляд на мир непосредственно с http, который должен рассказать вам что-то о его возможной масштабируемости, но он делает это при некоторых ограничениях в модели программирования.

Пара технических точек. Одна служба DSS потребляет больше памяти (~ 2K), чем один процесс erlang (300-400 байт). Кроме того, каждая служба DSS получает свою собственную очередь задач и есть верхний предел (~ 10000) от числа очередей задач, которые могут быть эффективно обработаны CCR. У меня нет номеров на таких верхних границах для Erlang, но подозреваю, что это может быть выше этого.

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