Google App Engineに簡単に移行するための設計

Question

まもなくWebアプリの設計を開始しますが、SQLの世界で多くの経験がありますが、近くでGAEに移住することを目標に、何を考慮に入れる必要があるかわかりません。将来。

あるいは、最初からGAE用のアプリを設計することもできます。その場合、考慮に入れる必要がある違いは何ですか？言い換えれば、過去のリレーショナルデータベースから来るGAEのアプリを書くDOSとDOTSは何ですか。

Answer 1

私の頭の上のすぐ外：

• それは本当にキー - >バリューストアだけです、ようなものにだまされないでください GQL （これはSQL Selectの単なるサブセットです）
• 参加しない - 多くの場合、あなたは非定型または忘れなければなりません
• 多かれ少なかれ頻繁なタイムアウト
• （非常に）ローカルSQLベースと比較して、遅いアクセス。
• 非常に高価な数を数えます
• クライアント側に実装されているオフセット（select） - 実際、すべてのレコードを取得してオフセットするまで - コメントの1つでニックジョンソンが指摘したように、それはクライアント側ではないので、今では1000の制限がなくなっているため、SQLデータベースに似ています。
• （最近削除された）1000枚のフェッチ列の制限
• 選択した列の数が増えると、選択のパフォーマンスが大幅に減少します
• 移行は、通常のHTTP要求を使用してそれらを行う必要があり、各リクエストが30秒後に殺されるため、移行を行うのは困難です。バッチで行を処理するタスクキューに頼る必要があります
• Python APIにはReferencePropertiesと呼ばれる擬似外部キーがありますが、それらはいかなる方法でも強制されていません - 誰か/何かがターゲットオブジェクトを削除すると、C ++でぶら下がっているポインターとして知っているものがあります
• クエリに使用するフィールドはインデックス付けする必要がありますが、それでも使用する必要があります 鍵 （各行/インスタンスの一種の主キー）クエリをより速く実行する
• ライブインスタンスにインデックスを構築するには、多くの時間がかかります（そしてそれを減らすことはできません）。ビールと忍耐強くお勧めします。
• 多くの人為的な制限（既に削除されている最大制限1000のように）。 eg gql 'in'演算子は、複数のor-sの単なる構文糖であり、使用される30の値の上限があります。

それは、おそらく一貫性のない状態をユーザーに公開することを避けることができず、データの一貫性のない状態を持つことを避けることはほとんどできないことを意味します（たとえば、手動で結合するデータの変更など、半列が移動し、半分は移動しません））