2

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

4

1 に答える 1

9

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

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

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

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

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

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

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

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

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

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

いくつかの技術的なポイント。単一のDSSサービスは、単一のerlangプロセス（300〜400バイト）よりも多くのメモリ（〜2K）を消費します。また、各DSSサービスは独自のタスクキューを取得し、CCRで効率的に処理できるタスクキューの数には上限（〜10000）があります。Erlangのそのような上限の数値はありませんが、これよりも高い可能性があると思われます。

とはいえ、.NETプラットフォームを使用している場合は、CCRを真剣に検討することで自分に有利に働くことになります。特にリアクティブなイベント駆動型プログラムの場合、非常に強力であることがわかりました。

于 2009-05-06T12:02:19.507 に答える