CCRはどのように＆amp; DSSツールキットモデルと他のスケーラビリティとの比較同時性アプローチ？

Question

スケーラビリティとさまざまなアプローチの比較に興味があります。 CCR＆amp;を含む同時実行DSSフレームワークモデル。 HadoopおよびErlangスタイルの同時実行性との比較に特に興味があります

Answer 1

CCR、DSS、Erlangを見てきましたが、これらのうち、重要な製品コードにはCCRのみを出荷しました。 Hadoopを見たことがない。

Erlangの同時実行性は、Actorモデルの実装に由来します。各「プロセス」にはメールボックスがあり、そこからメッセージを1つずつ取得します。処理するメッセージのないプロセスは、スレッドをブロックしません。逆に、実行する作業のあるプロセスは、使用可能なCPU全体でスケジュールされ、基礎となる機械は公開されません。さらに、プロセスは、P1とP2がそれらの間を通過するメッセージを論理的に共有しないように、クローニング/不変性のいずれかとメッセージ受け渡しを介して通信します。

Erlangに単一（おそらくマルチコア）マシンでのスケーラビリティの評判を与えているのは、メッセージの送受信をブロックしないという性質です。基本的に、実行する作業のあるプロセスは利用可能なリソース全体で効率的にスケジュールされ、静止プロセスはメモリのみを消費します。一度に1つのメッセージを処理することで、それぞれがメッセージの安定性を保証し、開発者は「競合状態」などのことを心配する必要がなくなります。

CCRは、低レベルの非同期メッセージ受け渡しプリミティブのセットです。より単純なものの1つは、受信であり、la Erlangの受信を行います。ただし、Join（一部のチャネルすべてのメッセージを受信）やChoice（一部のチャネルのいずれかからメッセージを受信）など、より高度なプリミティブがあり、興味深い方法でネストおよび構成できます。これらのプリミティブも非ブロッキングです。受信者は（メッセージを処理するための）タスクを1..nのタスクキューに生成し、少数のスレッドで処理します。

（重要！）プラットフォームの違いを無視して、それぞれの基本的なタスクスケジューリングルーチンは基本的に同じボールパークにあると思います。ただし、Erlangは固定された（アクター）モデルが組み込まれた言語およびプラットフォームです。CCRはこれらのものではなく、単なるライブラリであり、より自由に使用/悪用できます。

DSS はプログラミングモデルであり、CCRに基づいています。サービス（Erlang =プロセス）があり、サービス間通信の唯一の形式として非同期メッセージパッシング（デフォルトでは完全なクローン作成）が義務付けられており、外部世界がサービスに対して持つ唯一のハンドルはそのURI（Erlang = PID）です。 Erlangのように、ローカルサービスの呼び出しとリモートサービスの呼び出しには本質的に違いはありませんが、後者の場合は（逆）シリアル化が発生します。

DSSにはRESTfulモデルもあります。つまり、サービスは通常、固定された共通の操作セットを公開し、サービスの状態はこれらの操作によって操作されるリソースと見なされる必要があります。これとは対照的に、Erlangでは、任意のメッセージをプロセスに送信できます。 DSSサービスは、他のサービスと通信するときにCCRプリミティブの完全なセットを使用できます。これは、分散スキャッター/ギャザー操作などに非常に役立ちます。

最終的に、DSSは、言語やVMではなく、サポートライブラリを備えたフレームワークに過ぎないため、Erlangプロセスを作成するのではなく、単一のDSSサービスを作成する場合でも、かなり多くの「儀式」が行われます。

同時実行に関しては、複数の実行スレッドを心配することなく、複数の実行スレッドの下で安全かつ効率的なコードを記述するために必要なプリミティブがすべて提供されます。ほとんどの開発者がそこに行きたいと思っているのはそこだと思います。

スケーラビリティに関しては、使用するツールと同じくらいシステム設計に関することなので、答えるのは難しいです。コアを追加するとき、またはノードを追加するときなど、単一ノードでのスケーラビリティを意味しますか？ CCRは後者については何も言うことはありません。 DSSとErlangは、どちらも有線伝送用のかなり効率的なバイナリ形式をサポートしています。 DSSはhttpからリソース指向の世界観を直接継承します。これにより、その潜在的なスケーラビリティについて何かがわかりますが、プログラムのいくつかの制限でこれを行います。