Google App Engineデータベースを作成しています。ライブになると、クエリ、挿入、削除がかなり不変で、1,000万を超えるレコードが格納されます。Google App Engineのデータ量の制限
これは多くのデータが問題になりますか？私は、データベースのパフォーマンス（$$$）だけを心配していません。クエリは、StringPropertyと100未満のレコードの両方の2つのフィールドに基づいています。
データベースには2つの 'テーブル'があり、ほとんどのクエリを取得するのは約100バイトのレコードです。大きなテーブルは多くのクエリを取得せず（おそらく小さなテーブルの1/10）、レコードはそれぞれ約30Kです。
削除は高価な操作ですか？古いレコードを削除せず、単に削除してマークして、cronジョブで一括して削除する方が良いでしょうか？
私はGoogle App Engineとレプリケーションの分散的性質を認識しており、これらの問題は問題にはなりません。
1000万のレコードはデータストアにとって大したものではないため、クエリでインデックスを利用できる限り、心配する必要はありません。たとえば、データセット内の特定の位置から開始したいと言っているのではなく、大量のデータセットを100レコードずつ歩かなければならない場合は、ページの末尾にある最後のORDER BYフィールド値を覚えて、それ以降の要素（WHEREフィールド> '...' - 昇順を想定します）。
cronジョブの代わりにタスクキューを使用して削除を行うことができます。これは、どれくらい早くユーザーに戻すかによって異なります。データストアの操作は遅くなる傾向がありますが、削除するレコードが1つだけの場合は、それが受け入れられる可能性があります。ただし、複数の操作を実行する必要がある場合は、処理が遅くなる可能性があるため、このような種類のタスクをタスクキューで実行し、アプリケーションの応答性を維持することをお勧めします。
データストアレコードは1Mbを超えることはできませんが、30KBは大きなレコードサイズですが、問題を引き起こすものではありません。短い文字列（500文字以下）しか索引付けできないことに注意してください。
ありがとうございました。私は多くのデータを歩く必要はありません。私のクエリは、q.filter（ "foo ="、 "bla"）とq.order（ " - submitted"）を使用し、q.fetch（25）を実行して返します。それはかなりシンプルです、ちょうど多くのデータになるでしょう。 –
データストアのクエリのパフォーマンスは、データセットのサイズではなく、結果セットのサイズとともに大きくなります。したがって、多数のエンティティで問題が発生することはありません。削除のパフォーマンスは、独自のマーク・アンド・スイープを実装するには問題ではなく、データセットとともに増加しません。応答性が問題になる場合、データストア操作をタスクに遅らせるというstivloの提案は良い方法です。それを単純に実装すれば、パフォーマンスが問題であれば、ボトルネックがどこにあるのか（AppStatsなど）を見つけて修正します。 –