キャッシュされるデータ:
本番およびテストでのCoherenceトポロジの提案が必要(バックアップとともに配布)
質問
読み取り操作が何回行われるかはわかりません。このソリューションは、短い応答時間が (データの一貫性以上に) 重要であり、各ユースケースに依存するクライアントによって使用されます。キャッシュは、一定の頻度でポーリングしてキャッシュにデータを入力することにより、DB から更新されます (キャッシュはデータ マスターであり、キャッシュを使用するシステムではないため)。
Coherence用のJVMのサイジングの経験則では、1つのバックアップを想定すると、データはヒープの1/3です。1/3はキャッシュ・データ、1/3はバックアップ、1/3は索引とオーバーヘッドです。
サイジングの最大の難点は、インデックスのサイズを見積もる適切な方法がないことです。実世界のデータを試して測定する必要があります。
JDK 1.6 JVM の経験則は 4GB ヒープから開始するため、75 のキャッシュ サーバー ノードが必要になります。かなり大きなヒープ (16GB) で成功した人もいるので、試してみる価値があります。大きなヒープ (16GB など) では、オーバーヘッドに 1/3 ほど必要とせず、データ用に 1/3 以上を保持できます。ヒープが 16GB を超えると、ガベージ コレクターのチューニングが重要になります。
最大のパフォーマンスを得るには、ノードごとに 1 つのコアが必要です。
サーバー マシンの数は、管理のしやすさ、容量 (コアとメモリ)、および障害の実際の制限によって異なります。たとえば、32 個のノードを処理できるサーバーがある場合でも、マシンに障害が発生した場合、クラスターはどうなりますか? クラスタはマシン セーフになります (バックアップは同じマシン上にありません) が、大量のデータを新しいバックアップに移動する必要があるため、リカバリは非常に遅くなります。一方、75 台のマシンは管理が困難です。
Coherence では、ネットワーク ホップとバックアップを含めて、1K オブジェクトのプットに対して 250 マイクロ秒 (ミリ秒ではない) のレイテンシがあることがわかりました。したがって、探している挿入と更新の数は達成可能なはずです。複数のスレッドの挿入/更新でテストし、テスト クライアントがボトルネックになっていないことを確認します。
いくつかの「経験則」:
1) 高可用性を実現するには、最低でも 3 つのノードが適切です。
2) Java 7 では、より大きなヒープ (27GB など) と G1 ガベージ コレクタを使用できます。
3) 100GB のデータの場合、David のガイドラインを使用すると、合計 300GB のヒープが必要になります。128GB のメモリを搭載したサーバーでは、それぞれ 27GB のヒープを持つ 4 つの JVM を実行する 3 台の物理サーバー (合計で最大 324GB) で実行できます。
4) インデックスのメモリ使用量は、データ型とアリティによって大きく異なります。インデックスの有無にかかわらず、代表的なデータ セットを使用してテストし、メモリ使用量の違いを確認することをお勧めします。