App Engineについて（おそらく）知らなかった10のこと

9つのクールなApp Engineチップを説明するよりも優れているものはありますか？ もちろん、10の説明。 グループディスカッションに参加して、App Engineの一部の機能がしばしば見過ごされていることに気づいたので、プログラムを異なる方法で記述できる興味深い事実を11個より少し少なく選択しました。 しかし、十分な言葉で、最初のチップを見てください。

1.アプリケーションのバージョンは数字ではなく文字列です

ほとんどの例では、app.yamlおよびappengine-web.xmlの「version」フィールドに番号がありますが、これは単なる合意事項です。 アプリケーションのバージョンは、URLで使用できる任意の文字列にすることができます。 たとえば、バージョンに「live」と「dev」という名前を付けると、アドレス「live.latest」で使用できるようになります。 yourapp .appspot.com "and" dev.latest。 yourapp .appspot.com。」

2.アプリケーションの複数のバージョンが同時に動作している場合があります

パラグラフ1で示唆したように、App Engineを使用すると、アプリケーションの複数のバージョンをデプロイし、それらを並行して操作できます。 すべてのバージョンは同じデータウェアハウスとmemcacheを使用しますが、異なるインスタンスで実行され、異なるURLを持ちます。 'live'のバージョンはyourapp.appspot.com（および接続した他のすべてのドメイン）のアドレスを提供し、アプリケーションの他のすべてのバージョンはversion.latest.yourapp.appspot.comの形式のアドレスで利用できます。 複数のバージョンを使用すると、実際のデータで作業環境で新しいリリースをテストしてから、誰にでも公開できます。

アプリケーションの異なるバージョンが同じ言語を使用する必要さえないことはあまり知られていません！ Javaで記述されたアプリケーションの1つのバージョンとPythonで記述されたもう1つのバージョンがある場合、それはかなり面白いです。

3. Javaランタイムは、Javaバイトコードにコンパイルされるすべての言語をサポートします

ランタイムはJavascriptと呼ばれますが、実際には、JVMバイトコードにコンパイルされる言語でAppEngineアプリケーションを書くことを妨げるものはありません。 一般に、すでにJRuby、Groovy、Scala、Rhino（JavaScriptインタープリター）、Quercus（PHPインタープリター/コンパイラー）、さらにはJythonでAppEngineアプリケーションを作成する人々がいます。 このWikiページでは 、コミュニティで何が機能し、何が機能しなかったかについての知識を共有しています。

4.演算子「IN」および「！=」は、データウェアハウスに対して複数のクエリを生成します

Python環境の演算子「IN」と「！=」は実際にSDKに実装され、「ボンネットの下」はいくつかのクエリに変換されます。

たとえば、「SELECT * FROM People WHERE name IN（ 'Bob'、 'Jane'）」というクエリは、「SELECT * FROM People WHERE name = 'Bob'」および「SELECT * FROM People WHERE name = '」の実行に相当する2つのクエリに変換されますジェーン「」と結果を組み合わせます。 同時に複数の演算子を使用すると、必要なクエリの数がさらに増加するため、クエリ「SELECT * FROM People WHERE name IN（ 'Bob'、 'Jane'）AND age！= 25」は、条件のすべてのバリアントに対して4つの実際のクエリを実行します（年齢はまたは25歳以上で、名前は「Bob」または「Jane」です）、それらを1つの結果に結合します。

そのため、これらの演算子のいくつかを単一のクエリで使用しないようにすることをお勧めします。 たとえば、不等式でクエリを使用し、少数のレコードのみが基準を満たすと予想する場合（上記の例では、25歳の人がほとんどいないことがわかっている場合）、不等式なしでクエリを実行する方が効率的です。結果を自分で繰り返し、適切でないレコードを破棄します。

5.効率を高めるために、パッケージで挿入、クエリ、および削除の操作を組み合わせることができます

フェッチやget（）操作など、データウェアハウスにリクエストを行うたびに、アプリケーションはこのリクエストをデータウェアハウスに送信し、そこでリクエストが処理されて応答が返されます。 この要求と応答のサイクルには時間がかかり、次々と多くの操作を行うと、ユーザーが結果を待つまでに、かなりの付加物が追加される可能性があります。

幸いなことに、前後のモーションの数を減らす簡単な方法があります：バッチ操作。 db.put（）、db.get（）、db.delete（）の各関数は、通常の単一の呼び出しに加えて、入力リストを受け取ることができます。 リストを指定すると、データウェアハウスへの1回の呼び出しでリスト内のすべての要素を使用して操作が実行され、並行して多くの時間を節約できます。 たとえば、次の典型的なソリューションを見てください。

 for entity in MyModel.all().filter("color =", old_favorite).fetch(100): entity.color = new_favorite entity.put() 

このスタイルの更新では、データを取得するためのリポジトリへのアクセスに加えて、オブジェクトの更新ごとに1つの追加アクセスが必要です。結果としてリポジトリへの101アクセスを取得します。 比較のために、この例を見てください：

 updated = [] for entity in MyModel.all().filter("color =", old_favorite).fetch(100): entity.color = new_favorite updated.append(entity) db.put(updated) 

2行追加することで、リポジトリへのアクセス数を101から2に減らしました！

6.データウェアハウスのパフォーマンスは、格納されているオブジェクトの数に依存しません。

多くの人は、100,000、100万、または1000万のオブジェクトを保存した場合のストレージの動作を尋ねます。 ストレージの主な利点の1つは、そのパフォーマンスが、アプリケーションによって保存されるオブジェクトの数に完全に依存しないことです。 さらに、App Engineのすべてのアプリケーションの実質的にすべてのオブジェクトは、1つのBigTableテーブルに保存されます！ さらに、クエリに関しては、「ネイティブに」実行できるすべてのクエリ（演算子「IN」と「！=」を使用するクエリを除く-上記参照）の実行コストは同じです。クエリの実行コストはレコードの数に比例します。彼が返します。

7.インデックスの作成に必要な時間は、そのサイズに完全には依存しません

App Engineアプリケーションに新しいインデックスを追加すると、作成に時間がかかることがあります。 この理由について尋ねると、多くの人がデータ量に言及し、それを費やした時間と比較します。 ただし、新しいインデックスを作成するリクエストは、すべてのAppEngineアプリケーションのインデックスを作成する集中システムによってキューに入れられ処理されます。 ピーク時には、他の人がインデックス作成のリクエストの前にいる可能性があります。インデックスの作成は少し後で開始できます。

8.保存データの量（「保存データ」）は1日に1回計算されます。

1日1回、アプリケーションの「Stored Data」の値を再計算するタスクを実行します。 この時点でのデータウェアハウスの実際の使用の値が使用されます。 その間に、おおよそリポジトリの使用方法を考慮して、図を更新します。これにより、使用法のすべての変更を非常に迅速に確認できます。 これは、多くのオブジェクトが多数のオブジェクトを削除した後、ストレージがしばらく「満杯」のままであるときに、そのような効果を観察した理由を示しています。 もちろん、支払い時には、確認済みの値のみが使用されます。

9.ハンドラーがapp.yaml、web.xml、およびappengine-web.xmlファイルにリストされる順序は重要です

アプリケーションを構成する際、多くの場合、構成ファイル内のハンドラーが上から下に順番に処理されることを忘れてしまい、微妙なエラーが発生します。 たとえば、remote_apiを設定するとき、多くの人がこれを行います。

 handlers: - url: /.* script: request.py - url: /remote_api script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py login: admin 

一見、すべてはここで問題ありませんが、ハンドラーが順番に処理されるため、request.pyハンドラーが最初に検出され、すべての要求（remote_apiを含む）がrequest.pyを通過します。 request.pyはremote_apiについて何も知らないため、404 Not Foundエラーを返します。 解決策は簡単です-「catch everything」ハンドラーが最後にあることを確認してください。

Java実行環境にも同じことが当てはまりますが、もう1つの制限があります。appengine-web.xmlのすべての静的ハンドラーは、web.xmlの動的ハンドラーよりも早く処理されます。

10. GQLクエリを手動で記述する必要はありません

次のような非常に頻繁なアンチパターンが1つあります。

 q = db.GqlQuery("SELECT * FROM People " "WHERE first_name = '" + first_name + "' AND last_name = '" + last_name + "'") 

コードをインジェクションに対して脆弱にすることに加えて、文字のエスケープ（ユーザーの名前にアポストロフィが含まれている場合はどうすればよいでしょうか）に対処する必要があります。 幸いなことに、GqlQueryはパラメーター置換を行うことができます。これは、明示的な文字列の追加を避けるための標準的な方法です。 パラメータの置換により、上記のクエリは次のように書き換えることができます。

 q = db.GqlQuery("SELECT * FROM People " "WHERE first_name = :1 " "AND last_name = :2", first_name, last_name) 

GqlQueryは、番号付きパラメーターに加えて、名前付きの名前と値のペアを引数として渡すこともサポートしています。

 q = db.GqlQuery("SELECT * FROM People " "WHERE first_name = :first_name " "AND last_name = :last_name", first_name=first_name, last_name=last_name) 

これにより、よりクリーンなコードが生成されるだけでなく、興味深い最適化を使用することもできます。 同じクエリを異なる値で何度も実行する必要がある場合は、GqlQueryの.bind（）を使用して、各リクエストのパラメーター値を「接続」できます。 これは、リクエストを一度だけ解析する必要があるため、毎回新しいリクエストを作成するよりも高速です。

 q = db.GqlQuery("SELECT * FROM People " "WHERE first_name = :first_name " "AND last_name = :last_name") for first, last in people: q.bind(first, last) person = q.get() print person 

投稿者：Nick Johnson、App Engineチーム

Javaは、Sun Microsystems、Incの商標または登録商標です。 米国およびその他の国。

PS。 奇妙なことに、私は「ドラフト」と「プレビュー」だけで申し訳ないと感じました。保証付きの「公開」は残念ではありませんでしたが、トピックはまだ公開されていました（もちろん、未完成）。 私は恥ずかしかったすべての人に謝罪します-そしてそれほど緊張しないでください:-)