6

間もなくWebアプリの設計を開始します。SQLの世界で多くの経験を積んでいますが、すぐ近くでGAEに移行するために、何を考慮に入れる必要があるのか​​わかりません。将来。

または、最初からGAE用のアプリを設計することもできますが、その場合、どのような違いを考慮する必要がありますか？言い換えれば、過去のリレーショナルデータベースから得られた、GAE用のアプリを作成する際の推奨事項と禁止事項は何ですか。

4

1 に答える 1

7

頭のてっぺんから：

  • これは実際には単なるキー->値ストアであり、GQL（SQL SELECTのサブセットにすぎない）のようなものにだまされないでください
  • 結合なし-多くの場合、非正規化または忘れる必要があります
  • 多かれ少なかれ頻繁なタイムアウト
  • （非常に）ローカルSQLベースと比較してアクセスが遅い。
  • 非常に高価なCOUNT
  • クライアント側に実装されたOFFSET（SELECT内）-実際には、オフセットまでのすべてのレコードをフェッチします-コメントの1つでNick Johnsonが指摘しているように、クライアント側ではないため、1000のLIMITがなくなったため、SQLと同様になりますデータベース。
  • （最近削除されました）フェッチされた行の1000の制限
  • 返される行の数が増えると、SELECTのパフォーマンスは大幅に低下します。
  • 通常のhttpリクエストを使用して移行を行う必要があり、各リクエストは30秒後に強制終了されるため、移行を行うのは困難です。行をバッチで処理するタスクキューに頼る必要があります
  • Python APIではReferencePropertiesと呼ばれる疑似外部キーがありますが、それらは決して強制されません-誰か/何かがターゲットオブジェクトを削除した場合、C++ではダングリングポインタとして知られているものがあります
  • クエリに使用するフィールドにはインデックスを付ける必要がありますが、キー（各行/インスタンスの主キーの一種）を使用すると、クエリの実行が速くなります
  • ライブインスタンスでのインデックスの作成には多くの時間がかかる可能性があり（インデックスを減らすことはできません）、インデックスがないとアプリが機能しないことがよくあります。ビールと忍耐を強くお勧めします。
  • 多くの人工的な制限（すでに削除された最大制限1000など）。たとえば、GQLの「IN」演算子は複数のORの構文糖衣であり、使用される値の上限は30です。

つまり、一貫性のない状態をユーザーに公開することは避けられず、ほぼ確実に、データの状態に一貫性がないことを避けることはできません（たとえば、手動でJOINデータを変更するときに、半分の行が移行され、半分が移行されないなど）。

于 2010-03-02T18:42:43.637 に答える