Mapper APIを使用してセッションからデータストアを消去するのにかかる費用

GAEアプリケーションにセッションサポートを含めた人は、セッションが最初にデータストアに記録され、次にセッションから自動的に消えないことを知っています。 古くなったセッションから、どういうわけか自分を取り除く必要があります。



私はどういうわけか色あせたセッションを気にせず、1年半以上で150万個を蓄積しました。 最近、データストアに格納されたデータのサイズが無料の割り当てを超え、99％がセッションで占有されていたため、ファウルを削除することにしました。











もちろん、この目的で最近リリースされたMapper APIを使用しないのは罪です。 シンプルなマッパーを走り書きしました。 まず最初に、削除せずに数えることにしました。

public class SessionCleanupMapper extends AppEngineMapper<Key, Entity, NullWritable, NullWritable> { @Override public void map(Key key, Entity value, Context context) { Object expiresProperty = value.getProperty("_expires"); if (expiresProperty instanceof Long) { long expiresTimestamp = ((Long)expiresProperty).longValue(); if (expiresTimestamp < System.currentTimeMillis()) { context.getCounter("Session", "expired").increment(1); // DatastoreMutationPool mutationPool = this.getAppEngineContext(context).getMutationPool(); // mutationPool.delete(value.getKey()); } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして発売。 ギアが回転し、GAEの4つの手が私のセッションを刺激し始めました。 数時間後、サイトが横たわっており、割り当てを超えていることがわかりました。 彼はコンソールを見て、CPUクォータ（8.5 CPU時間）が使い果たされているのを見ました。 びっくりしました。 クォータを引き上げ、翌日、再びmapreduceを起動し、エンティティを削除する行のコメントを解除しました。



やったー わずか2.5時間の絶対時間で、クラウドメガテクノロジーが仕事を果たし、最終的に22 CPU時間を消費しました。









私はそれについて考えました。 雲の中に何かが間違っています。 私は試していませんが、何らかの理由でMySQLでも処理できると思います

 DELETE FROM _ah_SESSION WHERE _expires < NOW()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

数分で。 100万行でも、200万行でも。 しかし、これは非常に古く、すべて1台のマシン上で、スケーラビリティと冗長性がなく、すべてが...



更新：データストアからセッションを削除するために、mapreduceを記述する必要はありません。マジックサーブレットをプルし、カーソルで手動で繰り返すことができます。 しかし、それらの数が毎日どれだけ悪くなったのかを計算するために（SELECT COUNT（*）FROM _ah_SESSION GROUP BY _expires /（86400 * 1000）のようなもの）誰もサーブレットを作成しなかったので、おそらくmapreduceを駆動する必要があります。プリミティブDBMSの同じ損失。