Azure Service Fabric は、すべてのデータが RAM 内に収まり、永続性がバッキング ストアとして使用されるシナリオに重点を置いているようです。Reliable Services は、ログに記録された情報が RAM に書き込まれるログチェックポイント システムを使用する Reliable Collections に情報を格納するように設計されています。一方、Reliable Actors の場合、既定のアクター状態プロバイダーは "Service Fabric プラットフォームによって提供される分散型の Key-Value ストア" です。これは、同じ制限が適用されることを示しているようです。
ただし、"ホット データ" には Service Fabric を使用し、"コールド データ" を何らかの形式の永続的なストレージに書き込みたい場合があります。この移行を処理するためのベスト プラクティスは何ですか?
Orleans では、Azure テーブルなどの永続ストアを使用して、これが自動的に処理されるようです。しかし、Service Fabric と Reliable Collections の主な設計目的は、外部サービスを必要としないようにして、データの局所性を高めることであるようです。現在のドキュメントでは、障害復旧と分析のためにデータを何らかの永続的なストアに移動する可能性を想定していますが、永続性に支えられたインメモリ アクターとより永続的な形式のストレージの間でデータをやり取りする可能性については説明していません。 .
考えられる答えは、Service Fabric が既にこれを行っているということです。おそらく、Reliable Dictionary には、永続性に裏打ちされたメモリ内ストレージと永続ストレージを切り替えるためのメカニズムが組み込まれています。
あるいは、答えは、自分で管理しなければならないということかもしれません。1 つのアプローチは、アクターがどの程度「ホット」であるかを追跡し、必要に応じて永続ストアを切り替えることです。しかし、これはアクター モデルの利点の 1 つであるアクターの自動割り当てと割り当て解除を犠牲にします。同様に、定期的に Reliable Dictionary からアイテムを削除し、それを他の永続ストアに追加してから、再度追加することもできます。繰り返しになりますが、これには、いつ移行を行うのが理にかなっているかについての知識が必要です。
いくつかの例がこれを具体化するのに役立つかもしれません:
(1) 多くの異なる「部屋」を持つマルチプレイヤー ゲームを実装しているとします。すべてのルームを一度にメモリに格納する必要はありませんが、それらをメモリに移動し、プレイヤーがルームに参加したらバックアップとしてローカル永続性を使用する必要があります。
(2) データベースの一部として追加専用の B ツリーを実装するとします。各 B ツリー ノードをステートフルなアクターにしたくなるでしょう。ホット B ツリーをメモリに残しておきたいのですが、もちろんインデックス全体をメモリに残すことはできません。これは、DocumentDB などで既に実装されているコア シナリオのようですが、ドキュメントからは、これを行う方法が明確ではありません。
私が見つけた関連する質問はこちらです。しかし、その質問は、Azure Service Fabric と外部サービスをいつ使用するかということに焦点を当てています。私の質問は、それらの間で移行する必要があるかどうか、または Azure Service Fabric がここで必要なすべての機能を既に備えているかどうかです。