Google App Engineデータストレージ

この記事は、Nick Johnsonによるブログ投稿に基づいています。 それに加えて、現時点で関連するいくつかの図が示され、いくつかのメモが追加されています。



App Engineには、情報を保存する多くの方法が用意されています。 いくつか（たとえば、データウェアハウス）はよく知られていますが、他のものはほとんど存在せず、すべてが異なる特性を持っています。 この記事では、さまざまな可能性をリストし、それぞれの長所と短所について説明します。これにより、データストレージ機能に関する詳細情報を使用して意思決定を行うことができます。

データウェアハウス（データストア）

最も有名で使用済みの柔軟なデータウェアハウス。 DatastoreはApp Engineの非リレーショナルデータベースであり、信頼性の高い長期ストレージを提供し、データの保存、受信、処理に最大限の柔軟性を提供します。

• 利点：
  
  
  • 信頼性-データは深刻かつ永続的に保存されます。
  • 読み取りと書き込み-アプリケーションは、データストア内のデータの読み取りと書き込みの両方を行うことができます。 また、データストアは、整合性を確保するためのトランザクションメカニズムを提供します。
  • 一貫性-ストレージのタイプは、アプリケーションのすべてのインスタンスで同じです。
  • 柔軟性-クエリとインデックス作成により、データをクエリおよび取得する多くの方法が提供されます
• 短所：
  • 速度-データストアはデータをディスクに保存し、信頼性を保証するため、書き込みプロセスではデータが保存されたことの確認を待つ必要があり、読み取りプロセスではディスクからデータを取得する必要があります。
• 使用方法と場所：
  
  
  
  特別に訓練されたデータストアの説明はこちらです。
  
  データストアは、アプリケーションが将来使用するデータを確実に保存する必要がある場合に使用する必要があります。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  多くの場合、開発者は必要なデバッグ情報と技術情報をデータベースに書き込みます。 そのような場合には、組み込みのApp Engineログの方がはるかに適しています。以下でそれらについて説明します。
  
  

Memcache

Memcacheは、「セカンダリ」データストレージのメカニズムとして知られています。 memcache APIを使用すると、アプリケーションはデータを楽観的にキャッシュして、コストのかかる操作を回避できます。 Memcacheは、データストアなどの他のAPIのキャッシュレベルとして、または計算の結果をキャッシュするためによく使用されます。

• 利点：
  • 高速-memcacheのアクセス時間は通常数ミリ秒です
  • 一貫性-ストレージのタイプは、アプリケーションのすべてのインスタンスで同じです。 Memcacheはアトミック操作も提供するため、アプリケーションはそこに格納されているデータの整合性を保証できます。
• 短所：
  • 信頼できない-データはいつでもmemcacheから削除できます。
  • 常に利用可能ではありません-memcacheはApp Engineのメンテナンス期間中は利用できません。
• 使用方法と場所：
  
  
  
  データストア、urlfetch、または計算結果のキャッシュとして。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  重要なデータを保存するには、それらがいつでもmemcacheから消えることを忘れないでください。

インスタンスメモリ

アプリケーションインスタンスは、グローバル変数またはクラスメンバーを使用してデータをキャッシュすることもできます。 この方法は最高の速度を提供しますが、いくつかの欠点があります。

• 利点：
  • 高速-文字通り、可能な限り高速で、データは要求したプロセスと同じプロセスに保存されます。
  • 便利-APIは不要で、データは単にグローバル変数またはクラスメンバーに保存されます。
  • 柔軟性-データは、プログラムが処理できる任意の形式で保存できます。 それらのシリアル化/逆シリアル化の必要はありません。
• 短所：
  • 信頼できない-インスタンスはいつでも開始または停止できるため、アプリケーションはインスタンスメモリのみをキャッシュとして使用する必要があります。
  • 一貫性のない-各インスタンスには独自の環境があるため、グローバル変数があります。 1つのインスタンスでの変更は、他のインスタンスには反映されません。
  • 制限された容量-インスタンスはメモリ消費に制限があり、その後は破棄されます。 インスタンスメモリ内のデータの制限は約50MBです。大量に使用すると、インスタンスは頻繁に破棄されます。
• 使用方法と場所：
  
  
  
  セッション情報、アプリケーション設定、ゲストページなど、頻繁に使用され、めったに変更されないデータをキャッシュするため dict変数でインスタンスメモリを使用すると特に便利です。さまざまなタイプのデータに対して一意のキーデータリポジトリを作成できます。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  頻繁に変更されるデータまたはユーザーが操作するデータをキャッシュするため。 1人のユーザーの異なる要求は異なるインスタンスによって処理される可能性があり、この場合のキャッシュは大きな混乱を引き起こします。
  
  

ブロブストア

BLOBストレージを使用すると、ユーザーがアップロードした大量のデータを簡単かつ効率的に保存および転送できます。

• 利点：
  • 大きなファイルをサポート-BLOBごとに最大2 GB。
  • ハンドラを記述する必要がなくなります。
  • 高性能のblobメンテナンス、特に画像のメカニズムを提供します。
  • アプリケーションは、BLOBをローカルファイルであるかのように読み取ることができます。
• 短所：
  • 読み取り専用-アプリケーションはBLOBを作成したり、既にロードされているBLOBを変更したりできません。 2011年3月30日、Files APIがApp Engineに登場しました-現在、blobstoreのデータを変更できます。
  • Blobstoreを使用するには、課金を有効にする必要があります。
• 使用方法と場所：
  
  
  
  カスタム画像、ファイル、その他の大きなオブジェクトを保存します。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  アプリケーションとのやり取りが予定されている小さなファイルの場合、データストア内のBlobPropertyの方が適しています。
  
  

ローカルファイル

アプリケーションは、標準のファイルシステム操作を使用して、アプリケーションと共にダウンロードされ、静的コンテンツとしてマークされていないファイルを読み取ることができます。 これにより、アプリケーションに必要な読み取り専用データが追加されます。

• 利点：
  • 高速-ローカルファイルの読み取りには、アプリケーションインスタンスが実行されているマシンでの標準的なディスク操作のみが含まれるため、速度はmemcacheとほぼ同じです。
  • 信頼性-アプリケーションが機能する場合、ローカルファイルは常に利用可能です。
  • 柔軟性-任意の形式またはメカニズムを使用してローカルファイルにアクセスできます。
• 短所：
  • 読み取り専用-アプリケーションはファイルを変更できません。
  • 制限サイズ-制限はファイルごとに10MB、アプリケーションごとに150MBです。
• 使用方法と場所：
  
  
  
  アプリケーション設定、テンプレートなどの保存
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  禁忌なし
  
  

タスクキューペイロード

これは、従来の意味でのストレージではなく、データをタスクキューからタスクにアタッチできます。これにより、他のストレージシステムの必要性を排除できます。

• 利点：
  • 高速-データはタスクの開始時にタスクに送信されるため、データを受信するために追加のAPI呼び出しは必要ありません。
  • 正しく使用すると、他の場所にデータを保存する必要がなくなります。
• 短所：
  • 1つのタスクのみ-タスクキューに送信されるデータのストレージとしてのみ負荷が役立ちます
  • 制限されたサイズ-負荷を含むタスクのサイズは10 KBを超えてはなりません
• 使用方法と場所：
  
  
  
  データのバックグラウンド処理、メールの送信、キャッシュの更新-すべての作業、バックグラウンド実行への転送は、ユーザーへの応答の処理を高速化し、ユーザーが受信したサーバーの応答に影響を与えません。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  10Kbを超えるデータを処理するには、他の保存方法を使用する必要があります。 また、場合によっては、taskqueueのタスクを大幅に遅延させて実行できることを忘れないでください。
  
  

メール

App Engineでは、メールはユーザーとの通信だけでなく、技術的な目的にも使用できます。 この場合、データを転送する方法はタスクキューペイロードを使用するのと似ていますが、電子メールを使用すると、たとえば別のApp Engineアプリケーションにデータを転送するなど、より多くのオプションが提供されます。

• 利点：
  • 柔軟-メールクォータに影響を与えずに「通常」メールを送信するか、「管理」メールを送信することで、大量に送信できます。
  • 便利-データレターは、標準のInboundMailHandlerがある処理の利便性のために、POST要求として到着します。
  • アプリケーション間でデータを交換する機能。
• 短所：
  • スパム-予定外の文字がアプリケーションのアドレスに届く場合があります。受信データの追加検証が必要です。
  • 送信時には、データの量に応じて異なる方法を使用する必要があります-管理者は16 KB以下の文字を送信でき、通常の文字の送信は比較的高価です。
  • 「管理者」メールを完全に使用するには、請求書を含めることが望ましいです。 課金が有効になっているアプリケーションでは、管理者に1日に3,492,979文字を送信できますが、5,000では無効になります。
  • 管理者としてアプリケーションアドレスを接続するという簡単なプロセス-このアドレスでGoogleアカウントを作成し、管理者のリストに含めるには、一時的なハンドラが必要です。
• 使用方法と場所：
  
  
  
  アプリケーション間で少量のデータ（最大16 KB）を転送します。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  大量のデータを頻繁に転送すると、メールクォータがすぐに使い果たされます。これらの目的にはURLFetchの方が適しています。
  
  

URLfetch

URL取得APIを使用すると、HTTPおよびHTTPS要求を使用して他のホストから情報を取得できます。

• 利点：
  • 他のアプリケーション/サーバーからデータを受信する機能。
  • 非同期-待機中に非同期でデータを受信する場合、他の計算を実行できます。
  • サイズ-アプリケーションは1回のリクエストで最大32MBを受信できますが、このAPIを介した送信は1MBを超えることはできません。
• 短所：
  • 速度は、別のホストの速度に依存します。
  • トラフィック-URLFetchサービスとユーザーの場合、単一のトラフィッククォータ。 URLFetchを過度に使用すると、ユーザーのサービス拒否につながる可能性があります。
• 使用方法と場所：
  
  
  
  RSSなどのバックグラウンドダウンロードとデータ処理。 reCaptchaなどのサードパーティアプリケーションとの相互作用。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  より高速なメソッドを実装できる場合に、ユーザーのデータを取得します。
  
  

アプリケーションログ

通常、この方法は忘れられがちであり、アプリケーションの操作に関する情報を収集するためにデータストアが使用されます。 ただし、技術情報やデバッグ情報を収集する際にアプリケーションのパフォーマンスを低下させたくない場合は、この方法の方がはるかに優れています。

• 利点：
  • 高速-ロギングには数ミリ秒かかります。
  • 優先度によるメッセージの便利な分離。
• 短所：
  • 記録のみ-アプリケーションはログにアクセスできません。
  • ログ内のキリル文字のテキストデータのみがエラーの原因となります。
  • 解析の必要性-開発者のツールにrequest_logs関数が存在すると、ログをテキスト形式で取得できます。ログを処理するには別のパーサーが必要です。
• 使用方法と場所：
  
  
  
  アプリケーションの動作に関する情報を収集するには、リクエストの実行時間を測定し、機能の遅い動作や緊急事態について通知します。
  
  
  
  
• 使用しない方が良い場合：
  
  
  
  場合によっては、データストアにアプリケーションの統計情報を保存した方が良い場合があります。 このような場合、データをタスクキュータスクに転送し、バックグラウンドでデータストアに書き込むことをお勧めします。
  
  

おわりに

App Engineには、一見思われるよりもはるかに多くの方法でデータを保存できます。 それぞれに妥協点があるため、そのうちの1つ（またはそれ以上）がアプリケーションに適合する可能性があります。 多くの場合、最適なソリューションには、データストアとmemcacheなどのメソッドの組み合わせ、またはローカルファイルとインスタンスメモリが含まれます。