11

今日、Google App Engine のシャード カウンターについて読みました。この記事では、データ ストア内のエンティティごとに 1 秒あたり約 5 回の更新が最大になると予想する必要があると述べています。しかし、このソリューションは、1 秒あたりに実行している更新の数を知る方法がない限り、「スケーリング」しないように思えます。たとえば、10 個のシャードを割り当てることができますが、1 秒あたり 50 回の更新で窒息し始めます。

では、更新の速さをどのように把握し、その数をシャードの数に戻すにはどうすればよいでしょうか?

私の推測では、カウンターと一緒に最近のアクティビティの記録を保持することができ、スパイクを検出した場合はシャードの数を増やすことができます. それは一般的にどのように行われますか？もしそうなら、サンプルコードでそれが行われていないのはなぜですか? コードで自動的に行うのではなく、ウェブサイトのアクティビティを監視し、トラフィックの増加に応じてシャード数を更新する方が一般的な方法ですか?

更新:破片が少なすぎたり窒息したりすると、実際にはどのような影響がありますか? Web サイトが応答しなくなったということですか、それともタイムアウトのためにカウンターの更新が失われる可能性がありますか?

余談ですが、この質問はシャーディングなしでカウンターを実装することについて述べていますが、回答の 1 つは、トラフィックが多い場合は memcache もシャーディングする必要があることを示唆しています。したがって、シャードの割り当てとチューニングの問題は重要なようです。

4

3 に答える 3

4

Web サイトの人気を手動で監視し、必要に応じてシャードの数を増やす方が明らかに簡単です。ほとんどのサイトがこのアプローチを取っていると思います。プログラムでそれを行うのは難しいだけでなく、最近のすべてのアクティビティの記録を保持し、それを分析して使用しているシャードの数を動的に調整しようとすると、許容できない量のオーバーヘッドが追加されるように思えます。

選択したシャードの数を高くして少しだけ間違えるという、より単純なアプローチをお勧めします。

シャードが少なすぎることによる実際的な結果については、あなたは正しいです。データストア エンティティを可能な限り頻繁に更新すると、最初は一部のリクエストに時間がかかります (書き込みの再試行中)。それらが十分に積み重なると、リクエストがタイムアウトすると失敗し始めます。これは確かに見逃されたカウンターにつながります。良い面としては、ページが非常に遅くなり、ユーザーが離れ始める必要があるため、データストアへのプレッシャーが軽減されます:)。

于 2010-06-29T23:36:57.300 に答える
3

質問の最後の部分に対処するには：memcache値はシャーディングを必要としません。単一のmemcacheサーバーで数万QPSのフェッチと更新を処理できるため、おそらく大きなアプリでmemcacheキーをシャーディングする必要はありません。

于 2010-06-30T09:15:05.710 に答える
2

例外が発生し始めたら、シャードの数を増やしませんか?

このGAEの例に基づいて：

try{
  Transaction tx = ds.beginTransaction();
  // increment shard
  tx.commit();           
} catch(DatastoreFailureException e){
   // Datastore is struggling to handle the current load, increase it / double it
   addShards( getShardCount() );

} catch(DatastoreTimeoutException to){
   // Datastore is struggling to handle the current load, increase it / double it 
   addShards( getShardCount() );

} catch (ConcurrentModificationException cm){
   // Datastore is struggling to handle the current load, increase it / double it 
   addShards( getShardCount() );             

}
于 2012-01-24T20:18:01.520 に答える