簡単な例を見てみましょう。1,000,000 人のユーザーを持つサービスがあり、各ユーザーにはいくつかのプロファイル情報があります。アクターを使用して、このプロファイル情報に対する CRUD 操作を管理したいと考えています。
Project Orleansでは、ユーザーごとに 1 つのグレインがあり、同じアクター タイプ (使用された場合にのみ作成される) の 1,000,000 の仮想グレインがあり、各グレインは、その中に格納されている単一のユーザーのプロファイル情報を管理します。州。ユーザーが増えるにつれて、グレインの数も増えます。
Service Fabricでは、ドキュメントを正しく解釈すると、動作が少し異なります。すべてのユーザーに対する CRUD 操作を管理するステートフルなアクター タイプを用意し、スケーラビリティのためにアクターをパーティション分割して、各パーティションにユーザー データのサブセットに対する責任を与えます。パーティション オプションを考えると、Project Orleans と同じようにきめ細かく実装する明確な方法がわかりません。
Project Orleans のアプローチがとても気に入っています。アクターは 1 人のユーザーのデータを処理しているだけであり、スケーラビリティは明らかです (ユーザーが多いほど粒度が高くなります)。メモリ モデルも単純です。単一のアクターが少量の状態でオンデマンドでハイドレートされます。
Service Fabric の実装はもう少し複雑になるようです。各アクターは一連のユーザーを処理します。スケーラビリティのために、作成するパーティションの数を事前に決定する必要があります。これは後で変更できないためです。メモリ モデルに関しては、各アクターが管理するデータの量は、ユーザーの数が増えるにつれて増加します。
私の質問は次のとおりです。Service Fabric のアクターは Project Orleans よりも単純に粗粒度であるという私の理解は正しいですか?
アップデート
答えてくれてありがとう。私の間違いは、パーティションには、パーティション内のすべてのアクター ID の状態を格納および管理する単一のアクター インスタンスが含まれていると考えていたことです。これは完全に間違っています。Michiel は、パーティションには複数のアクター インスタンス (アクター ID ごとに 1 つ) が含まれていると指摘しています。したがって、アクターは Project Orleans と同じ方法で実装できます。これは今でははるかに理にかなっています、ありがとう。