弊社ブログは2010年4月26日からURLを変更いたしました。 ブックマークやRSSで登録されている方は、下記URLへ変更願います。 http://www.conit.co.jp/blog/ 今後とも宜しくお願い申し上げます。 2010年4月26日 株式会社コニット こんにちは。ヘビが大嫌いPython好きの高浦です。 最近GAEのPythonを使っているので今日はちょいテクを綴ってみようと思います。 GAEのデータストアには動的にプロパティを追加、削除できるExpandoモデルというのがあります。 RPGのゲームを作ろうと思ったときに、次のようにExpandoモデルで持っているアイテムのクラスを作ったとします。 class ItemData(db.Expando): sword = db.IntegerProperty() shield = db.IntegerPr
Python Overview CGI Environment Storing Data Overview Entities and Models Creating, Getting and Deleting Data Keys and Entity Groups Queries and Indexes Transactions Types and Property Classes GQL Reference Statistics Reference Model Expando PolyModel Property Query GqlQuery Key Functions Exceptions Services Blobstore Overview Reference BlobInfo BlobKey BlobReader Functions Exceptions Images Overv
Matcher APIはあるオブジェクトが登録したクエリーにマッチするかをスケーラブルにチェックしてくれるサービスです。 クエリーが既に登録しているから、あるオブジェクトが一つ一つの登録したクエリーにマッチするかが他のクエリーに依存しないので、 Map-Reduce で簡単に平行で処理を分担してスケールできる。 何に使うか これが少し分かり辛いところかもしれないので、少し説明します。クエリーを未然に登録するので、 Prospective Search (プロスペクティブ検索、展望検索、予測検索?) と言います。 みんな使っている、普段の検索は、Retrospective Search (遡及検索) です。クエリーが決まってないので、データをインデクスを作って、後でユーザーがデータを クエリーする形になっています。 プロスペクティブ検索は、未然にクエリーを決めて、そのクエリーにマッチするデー
Background work with the deferred library Nick Johnson October 15, 2009 Introduction Thanks to the Task Queue API released in SDK 1.2.3, it's easier than ever to do work 'offline', separate from user serving requests. In some cases, however, setting up a handler for each distinct task you want to run can be cumbersome, as can serializing and deserializing complex arguments for the task - particul
Nick Johnson さんの deferred についての記事では、簡単にバックグラウンドタスクを実行する方法が紹介されています。 Kay でも使用したいので専用のハンドラを用意しました。changeset: 8dff0f839164 以降の Kay で作成したプロジェクトであれば何も考えずにこのハンドラが有効になっているはずです。具体的には app.yaml の元々ある main.py より上に下記のように - url: /_ah/queue/deferred script: kay/main.py login: admin - url: /.* script: kay/main.py 追加しまた、プロジェクトディレクトリ直下の urls.py には下記のように def make_url(): return Map([ Rule('/_ah/queue/deferred', end
Built in the cloud. Engineered for your enterprise.
Posted by Nick Johnson | Filed under app-engine, memcache, storage, datastore, task-queue App Engine provides a number of ways for your app to store data. Some, such as the datastore, are well known, but others are less so, and all of them have different characteristics. This article is intended to enumerate the different options, and describe the pros and cons of each, so you can make more inform
我らが尊敬して止まない Guido が appstats というソフトをアナウンスしていました。GAE の RPC Call を可視化してくれるツールです。パフォーマンスチューニングなどに重宝しそうです。 このツールは二つのパーツから出来ています。記録する部分と ui 部分です。記録の設定をするには二種類の設定方法があります。一つ目は appstats に用意してある Django の middleware を使用するというもの。もう一つは WSGI middleware を設定するという方法です。インストールは前者の方が圧倒的に簡単なので、Django 用 middleware が使えたら嬉しいなあと思い試してみました。
precompileでGoogle App Engineのspin upが約2.5倍速くなるようです。 方法は、app.yamlのderived_file_type:に- python_precompiledを指定するだけ。 app.yaml derived_file_type: - python_precompiled これだけで、約2.5倍も速くなるなんて素敵。 後で試してみよう。 情報源 1 #appengine app.yaml で derived_file_type: に – python_precompiled と指定すると precompile するようになったとかならないとか http://twitter.com/tmatsuo/status/14584252857 情報源 2 precompile すると spin up が 2.5倍くらい速い #appengine ht
(随時更新中です。間違いなどありましたらコメントをお願いします!) このページのtinyurl: http://tinyurl.com/gaetips Datastoreのtips Bigtableの内部構造 BigtableによるDatastoreの実装 Datastoreによるクエリの実装 トランザクションとエンティティグループ Datastoreのtips List Proprtyとmerge joinの使い方 GAE一般のtips GAEのサーバー構成とリクエストの流れ Task Queue APIの使い方 開発環境とプロダクション環境の違い Flex/AIR+GAEのtips GAE/JにBlazeDSを組み込む BlazeDSの本番環境へのデプロイでハマる Datastore APIの取り扱いでハマる App Engine開発の便利な参考ページ TOPGATEさんのGoogle
GAEを導入しようとしてダウンタイムがどの程度なのか気になったので、 公式アナウンスをもとにまとめた(2009/04 -2010/05)。 雑感 ざっくり 定期メンテナンス:毎月1回程度。最近は日本の早朝に行われることが多い。5:00AM-6:00AM(13:00PST-14:00) DS障害:1ヶ月 〜 3ヶ月に一度はありそう。数時間書き込み停止。 App障害:最近はほとんどない Cron障害:最近はほとんどない その他API障害:ほとんどない なのかな。 要するに 毎月数時間、突発的に起こるDS書込遅延を受け入れられるかどうか がGAE採用するかどうかのポイントになりそう。 例えば、SNSやCGMサイトとかreadがwriteよりも圧倒的に多いサイトはOKだけど、ECサイトとか業務アプリみたいに書き込みが直接課金やサービスの質に繋がってるサイトでは慎重に考えた方がいい。お金を払ったら多
Google App Engineでmany-to-many(多対多)2kindと接続用モデルで 2010/05/07 09:35:00 「many-to-many(多対多)」をGAE上で表現してみる。 ネット上にこの手法の記事が少ないことからあまりメジャーなやり方でないかもしれないが、確実に言えることは接続用モデルを作ることで1kind増えるので関連データを引っ張ってくるのにデータストアの呼び出し回数が増える=パフォーマンスに影響するということ。 それを踏まえた上で参考までに。 app.yamlapplication: jinling-ren version: 1 runtime: python api_version: 1 handlers: - url: .* script: main.py main.py#!/usr/bin/env python #!-*- coding:u
今日は、Google App Engine(GAE)の地理データ処理について書きます。GAEによるクラウドマップのAPI化を試みているのですが、その中で多少特殊なテクニックが必要とされる部分がこれでした。 まず目的は、x,y,z (latitude,longitude,elevation)で表される点の集合を地理的な範囲で絞り込むことです。具体的には、xmin<x<xmax, ymin<y<ymax,zmin<zの範囲の中にある点集合を取り出すことです。 普通のデータベースなら何の問題もないのですが、GAEの場合、範囲指定が一つの変数にしか使えないという制約があるので、この絞込みを素直に実行できません。つまり、xmin<x<xmaxのみならいいが、それに加えて, ymin<y<ymaxやzmin<zなど行うことはできないということです。 結論から言うと、xmin<x<xmax, ymin<
グーグルは「Google App Engine Blog」にて、データストアに2つの新機能、Eventual Consistency(結果整合性)とDatastore Deadline(データストアデッドライン)を追加したことを明らかにしました。これにより開発者は、データの一貫性と可用性のどちらを重視するのか、選べるようになりました。 プライマリが落ちていたらコピーを他のデータストアから取得 Google App Engine Blog: Read Consistency & Deadlines: More control of your Datastore Eventual Consistency(結果整合性)オプションは、プライマリのデータストア以外のデータストアにコピーされたデータを読み込むことを許すオプションです。 グーグルの解説によると、これまでのGoogle App Engin
Datastoreはシンプルな仕組みなので、新たに使い方を覚えるのは、それほど難しくはないと思います。しかし、一般的なRDBMSとはだいぶ違うので、別モノだと思った方が良いかもしれません。 ここでは主に一般的なRDBMSとの比較で、Datastoreがどのようなものかを説明していきます。 一般的なRDBMSと大きく違うのは 主キーを自由に選べない(文字列か自動採番のIDの二択) 複数のテーブルをクエリで自由にJOINできない フィルタ条件の不等号は同時に1つのプロパティに対してしか使えない 不等号のフィルタ条件がある場合、並べ替えの1番目には同じプロパティしか使えない JOINが使えないので、テーブル設計は正規化しすぎない方が良いようです。 主キー(ID/key_name) Datastoreでは、主キーはシステムが自動採番する数値型のIDか、ユーザが指定する文字列型のkey_nameの二
Category java(11) Photoshop(14) 遊戯王(154) 雑記(1200) お絵描き(71) ポケモン(13) 遊戯王・大会レポ(19) 遊戯王・大会日程(6) 遊戯王・デッキ集(12) 特集(6) ブログRSS(1) c言語(31) 無料ブログ比較(2) 本(1) ソフトウェア(8) chrome(5) R(1) プレシャスメモリーズ(19) Python(54) javascript(101) New Articles 10.28: 劇場版まどマギ叛逆の物語についてちょっとだけ感想05.27: NicoNico Audio Extractor 0.4.004.25: 東芝のKIRA03.26: うわっ...私の電車賃、高すぎ03.10: どこでも動くマークダウンエディタ md everywhere03.05: Zopfli 新しいzlib実装12.31: 巳年1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く