Send feedback Java on Google App Engine Stay organized with collections Save and categorize content based on your preferences. App Engine offers you a choice between two environments for Java applications: standard environment and flexible environment. Both environments have the same code-centric developer workflow, scale quickly and efficiently to handle increasing demand, and enable you to use G
Googleが提供する、Google App Engineというサービスを知っていますか? Amazon EC2などと同じで、Googleが用意するクラウドサーバー環境で アプリケーション開発ができるというサービスです。 (レンタルサーバーのようなもの) その大きな特徴は、なんといっても月間500万PV相当まで"無料"ということです。 ※有料で制限を拡張することも可能 ※2011/09/07 注 Google App Engineの新料金体系が発表されました。 新料金体系では無料で使える枠が大幅に削減されています。 この記事の無料での使用制限に関する記述は、新料金体系では 正しくありませんのでご注意ください。 「App Engine は無料で始めることができます。最大 500 MB の永続性ストレージに加え、月間約 500 万ページ ビューに対応できる十分な CPU と帯域幅を、すべてのア
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース(RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Full-text search — on App Engine, for Django — Try the demos — Buy now minimal code :: scalable :: with auto-completion The "Search documentation" function in the navbar is based on gae-search. Please try it! Features You get the following features, including a basic support package and a free 6 months upgrade period (after which you can, of course, continue to use gae-search). Index only specific
Revised 2009-07-12 to include addition of stemming, multi-word exact matching, multiple search entities, and stowing of designated parent titles in index entity keys. After rewatching Brett Slatkin's Building Scalable, Complex Apps talk at Google I/O, I came across the old SearchableModel module and realized it could be greatly improved by using the "Relation Index" technique described in the talk
The Python Datastore API The App Engine datastore is a schemaless object datastore, with a query engine and atomic transactions. The Python interface includes a rich data modeling API and a SQL-like query language called GQL. This reference describes the Python API for the App Engine datastore. It has the following sections: Overview Entities and Models Creating, Getting and Deleting Data Keys and
…という視点で@ashigeruさんとつぶやいたまとめ。 kazunori_279scalabilityやスループットの高さよりも、すべてのアプリをpartition-tolerantに書くよう強制して巨大インフラに細粒度で集約し、桁違いの全体最適を実現できることが重要と思う。でないと大規模サービス以外はあまり必要ない>NoSQLとかKVSlink ashigeru@kazunori_279 エコノミックにするコツはCPU Usageを平均70%以上くらいにするとからしいですねwlink kazunori_279@ashigeru 発電所の発電機だってそんな感じの運用ですよねlink ashigeru@kazunori_279 そうだとおもいます。 #appengine 関係の社内向けメモでは、fine-grain distributed app hostingによるロードの均一化みたいな
Google App Engine(GAE)でCPU Timeを使い切りました。 GAEは従量制のサービスで、あらかじめ設定した金額内で利用できるリソースが決まっています。これはQuotaと呼ばれていて、CPU、ネットワーク流量、保存データ、API呼び出し回数等々で制限があります。 よく言われる「GAE=無料」というのは、無料(課金しない)なら、そのQuotaが適用されるということです。 GAE+Pythonでとあるサイトの動作確認をやっていたところ、無料分のCPU Timeを使い切りました。 実際に使い切るとこんな感じになります。 サイト ブラウザでアクセスすると、どのページを見ても503が返ってきて、Googleのエラー画面が表示されます。 HTTPレスポンスヘッダは以下。 HTTP/1.x 503 Service Unavailable Date: Sat, 16 Jan 2010
調べた限りGAEには(日本語を)全文検索する機能はついてない。なのでちょっくら作ってみました。一応動くのは出来たけど、いろいろ不満な点が多い。転置インデックスはN-gramでN=2で作成。サンプルをサイトで公開してますが、検索は完全一致で結果の順位は考慮してません。最もシンプルなシステムで、検索語句を入力すると、Datastoreに格納されているその語句が含まれる文章を表示し、検索語句を強調表示します。また、100文字以下の文章ならDatastoreに格納できます。何故100文字以下かというと、文字数が多くなるとそれに伴い転置インデックスの作成量を増えていきます。となると、処理時間も長くなってGAEの処理時間オーバーのエラーが発生してしまう。うーん、もっと効率のよい転置インデックスの作成方法がないものか。全文検索の心臓部分のコードは以下の通り。GitHubにも置いてます。 http://g
Google App Engineを使った最初の作品 Tiny Message (http://tinymsg.appspot.com)をリリースしてまだ20時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
ご存じのとおり、App EngineのJVM(App Server)はクラスタ化されていて負荷分散される――というのがGoogleの説明です。しかし、WebブラウザからApp Engineに届くHTTPリクエストや、Task Queueのタスクによって呼び出されるHTTPリクエストは、実際にどのような感じで複数のJVMに配られるのでしょうか? どれくらいの量のリクエストが届いたとき、何台のノードに負荷分散される? 負荷分散のアルゴリズムは?(単純ラウンドロビン、sticky session/session affinity、負荷状況に応じた転送など) 新しいJVMの追加や、既存のJVMの削除のタイミングは? これらについてはGoogleから情報が公開されておらず、謎です。そこでApp Engine利用者の皆さんが実際の経験やテストを通じて情報を交換しながら想像たくましくするしかないわけです
いまコーディング中の案件で、Task Queueにぴったりハマる要件があったので、飛びついてみました。 課題:Datasource上の大量のデータをクライアントにダウンロードしたい。30秒内では終わらないので複数のリクエスト/レスポンスに分割してダウンロードする実装にした。しかしデータ量によっては何10分もかかってしまう。 原因:データ量の多さもあるが、それを取得するためのDatastoreのクエリ、および関連エンティティの取得にもっとも時間がかかっている 書こうとしているソリューション:クエリと関連エンティティ取得をTask Queueのタスクに分割して並列処理(map)し、取得したデータを集約(reduce)してクライアントに渡す …んん、これってMapReduceではないですか。1つのリクエストでは重い処理は、たくさんのタスクに細切れにして、キューにどんどん入れる。App Engin
とても遅かった以前の実装をTask Queueを使って書き換えることができました。感想をまとめると、 Task Queueはすばらしい。30分かかってた処理が3分で終わるようになった(前の実装がヘボいのではという疑惑はさておき) 処理を複数のタスクに分割して並列処理する(map)は簡単だけど、memcacheを使ってその結果をまとめる(reduce)のは面倒 reduce不要な用途(一括削除とか)や、reduceが簡単な場合(数の集計とか)、あとmemcache使わずにDatastoreに集約する使い方なら、そんなに苦労しないだろう memcacheを介してデータの配布や収集をするとき、とくに収集時の排他を書く必要あり(こういうバグりそうな/バグを再現できなさそうなコードは書きたくない) MemcacheService#incrementを使ってスピンロックを実装した memcacheはい
Datastoreのパフォーマンス Datastoreのパフォーマンスは、エンティティの数とは無関係 保存されているエンティティが1件でも、1000件でも、1000万件でも、パフォーマンスに変化はない Datastore performance doesn't depend on how many entities you have 個々のエンティティに対する更新処理のスピードは、1〜10回/秒程度 個々のエンティティの更新処理は遅い アプリケーションのパフォーマンスを決めるのは、更新処理の実装方法。参照処理は桁違いに速い low-level APIを使えば少し速くなるが、ドキュメントがあまりない http://groups.google.com/group/google-appengine-java/browse_thread/thread/e717f7ba37749ea4/0b37a3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く