最近、すっかり python になれてしまいましたが、SDK の Django(ジャンゴ)フレームワークは、相変わらず、0.96.4 です。
現在、オフィシャルなバージョンは 1.1.1 で、google App Engine でも 1.0 以上を推奨しています。
http://code.google.com/intl/ja/appengine/docs/python/tools/libraries.html#Django
SDK 収録のバージョンが上がってないということは、それなりにリスキーなのかなぁ。
時間があったら 1.1.1 を組み込んで見たいが、Django 自体まだ到底理解できていません。
なにしろ、師走。時間がなかなかとれません。
時間が取れたら挑戦してみましょう。
少し早いですが、みなさんよいお年をお迎え下さい。
2009/12/25
2009/12/24
当たり前といえばそうですが...
クラウドでは、どこで処理が行われているか(というかどの位遅延するか)は全く保証されていないため、
ああ悲しい...。
- フェッチはタイムアウトするもの
- データストアはアクセスに失敗するもの
- キャッシュは無くなってしまうもの
ああ悲しい...。
2009/12/22
IT技術者はいつでも不足気味?
経済産業省によれば、IT技術者はいつでも不足気味だそうです。「これから経済が上向けば」でしょ?。これからどんどん厳しさはましていくんじゃないだろか?とちょっと思った。
google ネタを書かないと、開発日記にならないのでちょっと最近あせったこと。
google app engine/Python で、appcfg.py を使ってデプロイするとき、
Error 403: --- begin server output ---
You do not have permission to modify this app.
--- end server output ---
と 403 Error となってデプロイできなくなったことがありました。
あれ、でも E-mail と password は聞いてこなかったよね???。
たしかに、自分のテスト環境から、本番環境へデプロイ先をかえたけど...
う~ん。appcfg.py も cookie を保持しているのね。
--no_cookies をオプションにつければ、よかったのでした。ちゃんとドキュメント読めよ>自分。
google ネタを書かないと、開発日記にならないのでちょっと最近あせったこと。
google app engine/Python で、appcfg.py を使ってデプロイするとき、
Error 403: --- begin server output ---
You do not have permission to modify this app.
--- end server output ---
と 403 Error となってデプロイできなくなったことがありました。
あれ、でも E-mail と password は聞いてこなかったよね???。
たしかに、自分のテスト環境から、本番環境へデプロイ先をかえたけど...
う~ん。appcfg.py も cookie を保持しているのね。
--no_cookies をオプションにつければ、よかったのでした。ちゃんとドキュメント読めよ>自分。
2009/12/21
TaskQueue なかなかいい感じなのですが
先週から、いろいろ調整して TaskQueue 実装をしてみました。
なかなかいい感じなのですが...
WebHook 実装なので、関数のようには使えません。Task 処理側にデータを渡す場合は、永続オブジェクトを使用するか、POST出きるようデータの加工が必要です。
それでも、どんどんキューへ放り込めば、さっさと Return 出きるので 30 秒タイムアウトの呪縛からは逃れられます。urlfetch などもうまく平行して行えばそれなりに早くなるし...。
しかし、処理を放り込むのは簡単ですが、終わり方の方が問題。当たり前ですが、自分で処理が終了したかちゃんと見る必要があります。
Task は、放り込んでしまえば後は、勝手に実行されるためエラーがあっても、ただリトライし続けるだけで消滅しません。というか、TaskQueue には Add しかメソッドがない!。
正常に動いているように見えて、膨大な Queue がたまっていることがありますのでご注意ください。私はこれでハマりました。
なかなかいい感じなのですが...
WebHook 実装なので、関数のようには使えません。Task 処理側にデータを渡す場合は、永続オブジェクトを使用するか、POST出きるようデータの加工が必要です。
それでも、どんどんキューへ放り込めば、さっさと Return 出きるので 30 秒タイムアウトの呪縛からは逃れられます。urlfetch などもうまく平行して行えばそれなりに早くなるし...。
しかし、処理を放り込むのは簡単ですが、終わり方の方が問題。当たり前ですが、自分で処理が終了したかちゃんと見る必要があります。
Task は、放り込んでしまえば後は、勝手に実行されるためエラーがあっても、ただリトライし続けるだけで消滅しません。というか、TaskQueue には Add しかメソッドがない!。
正常に動いているように見えて、膨大な Queue がたまっていることがありますのでご注意ください。私はこれでハマりました。
2009/12/18
TaskQueue を使ってみる
まだ Lab 扱いですが、TaskQueue を使用することで大量のデータを効率よく Download できないか調査中です。
デフォルトでは 5/s、5bucket(毎秒5タスク/5タスク制限(Limits the burstiness of the queue's processing)ですが、TaskQueue の設定 で最大毎秒20タスクまで増やすことができます。
この実装により、大量のデータ処理もキューにつんで 30秒以内に応答できるようになります。しかし...
・WebHook でタスクが呼ばれるため、自分で終了判定をしなければならない。
・失敗した場合リトライを自動でおこなう。のはいいですがどうやって止めるの?
と苦戦中です。
デフォルトでは 5/s、5bucket(毎秒5タスク/5タスク制限(Limits the burstiness of the queue's processing)ですが、TaskQueue の設定 で最大毎秒20タスクまで増やすことができます。
この実装により、大量のデータ処理もキューにつんで 30秒以内に応答できるようになります。しかし...
・WebHook でタスクが呼ばれるため、自分で終了判定をしなければならない。
・失敗した場合リトライを自動でおこなう。のはいいですがどうやって止めるの?
と苦戦中です。
2009/12/17
エンティティとトランザクション続き
Google App engine SDK が 1.3.0 になりましたね。
Blobstore で 50MBytes までの upload に対応したとのこと。
それはさておき、昨日は、まったくボケたことを書いていましたm__m。
一度、作成したエンティティに親を持たせることはできませんね。
エンティティグループに属さないエンティティ間のトランザクションを保証するのは
大変そうです。
一旦、お金を預ける方式など Google-App-Engine-Japan のディスカッションで検討させています。
http://pastebin.com/f603c0b13
また、一度エンティティグループ(親子関係)を持つと親が消滅しても、子は元親の情報
を引き継いだ状態で、明示的な親を指定しないとデータが特定でない状態になります。
ID は、データモデル毎、また共通の親を持つ子孫で一意ならいいということらしい。
(つまり、データモデルが違う、or 子孫は ID を 1 から振りなおしてもいいということ)
普通の RDB モデルで考えると絶対はまりそう。
Blobstore で 50MBytes までの upload に対応したとのこと。
それはさておき、昨日は、まったくボケたことを書いていましたm__m。
一度、作成したエンティティに親を持たせることはできませんね。
エンティティグループに属さないエンティティ間のトランザクションを保証するのは
大変そうです。
一旦、お金を預ける方式など Google-App-Engine-Japan のディスカッションで検討させています。
http://pastebin.com/f603c0b13
また、一度エンティティグループ(親子関係)を持つと親が消滅しても、子は元親の情報
を引き継いだ状態で、明示的な親を指定しないとデータが特定でない状態になります。
ID は、データモデル毎、また共通の親を持つ子孫で一意ならいいということらしい。
(つまり、データモデルが違う、or 子孫は ID を 1 から振りなおしてもいいということ)
普通の RDB モデルで考えると絶対はまりそう。
2009/12/16
Google App Engine エンティティとトランザクション
本日は至極まじめな話
GAE でデータストアを扱う場合、トランザクションには縛りがあって、エンティティグループ内でしか1トランザクションとして扱えない。
このエンティティグループというのが曲者で、こいつらは1トランザクションとして作成/更新/削除できるが、データストアとしては分散できないため、あまり大きなエンティティグループを作成するのはよくないらしい。
話は前後するが、このエンティティグループというやつは、DBモデルの親子関係を結ぶことで(つまり共通の親を持つ)ことで作成される(相手へのリファレンスとは別物)。
エンティティグループでないトランザクションは、一度に処理できない。
以下、a,b は同一エンティティグループに属さないため、1トランザクションで処理できない。
class Sample(db.Model):
counter = db.IntegerProperty()
def inc_counter(a, b):
a = Sample(counter=a)
b = Samble(counter=b)
a.put()
b.put()
db.run_in_transaction(inc_counter, 1, 2)
トランザクション処理が必要ないときは、エンティティグループを使用しないで、リファレンスを使用する。
例外:
トランザクションが必要な場合、エンティティグループとする。
Aさん から Bさん へお金の移動をしたい。でも100万人もユーザーがいる場合、全員をエンティティグループにしたくない。
この場合、Aさん Bさん の親を仮に作成してエンティティグループにし、1トランザクションで実行した後、親エンティティを消せばいいのかな?。ビックテーブルでは親が消えても子のエンティティは存続するし。
簡単に試せそうだけど、面倒くさいので必要になったとき検証します。ぐだぐだ...
GAE でデータストアを扱う場合、トランザクションには縛りがあって、エンティティグループ内でしか1トランザクションとして扱えない。
このエンティティグループというのが曲者で、こいつらは1トランザクションとして作成/更新/削除できるが、データストアとしては分散できないため、あまり大きなエンティティグループを作成するのはよくないらしい。
話は前後するが、このエンティティグループというやつは、DBモデルの親子関係を結ぶことで(つまり共通の親を持つ)ことで作成される(相手へのリファレンスとは別物)。
エンティティグループでないトランザクションは、一度に処理できない。
以下、a,b は同一エンティティグループに属さないため、1トランザクションで処理できない。
class Sample(db.Model):
counter = db.IntegerProperty()
def inc_counter(a, b):
a = Sample(counter=a)
b = Samble(counter=b)
a.put()
b.put()
db.run_in_transaction(inc_counter, 1, 2)
ビックテーブルの性格上、ある程度しょうがないとして推奨例が
http://code.google.com/intl/ja/appengine/docs/python/datastore/keysandentitygroups.htmlにこっそり書いてあります。
- トランザクションに必要なときにだけ、エンティティ グループを使用します。その他のエンティティ間の関係には、ReferenceProperty プロパティと、クエリで使用できる Key 値を使用します。
トランザクション処理が必要ないときは、エンティティグループを使用しないで、リファレンスを使用する。
例外:
トランザクションが必要な場合、エンティティグループとする。
Aさん から Bさん へお金の移動をしたい。でも100万人もユーザーがいる場合、全員をエンティティグループにしたくない。
この場合、Aさん Bさん の親を仮に作成してエンティティグループにし、1トランザクションで実行した後、親エンティティを消せばいいのかな?。ビックテーブルでは親が消えても子のエンティティは存続するし。
簡単に試せそうだけど、面倒くさいので必要になったとき検証します。ぐだぐだ...
2009/12/15
インターネットの注意事項
先日、NHK-BS の "今日の世界" を見ていてイギリス(だったかな?)の学童児童へのインターネット教育についての話題があった。
曰く、
知らない人に話しかけられても返事をしない。
不確か(自分で判断できない)情報は、両親、先生などに相談する
て、実世界の普通の教育だよなぁ。
インターネットがバーチャルだとよく言われるが、その先にいるのは実世界の人間で、その実世界の延長上にインターネットというツールがあるだけだものね。
曰く、
知らない人に話しかけられても返事をしない。
不確か(自分で判断できない)情報は、両親、先生などに相談する
て、実世界の普通の教育だよなぁ。
インターネットがバーチャルだとよく言われるが、その先にいるのは実世界の人間で、その実世界の延長上にインターネットというツールがあるだけだものね。
2009/12/14
GAE 1.2.8 へ updae
だから、どうなるという訳ではないですが...
urlfetch のタイムアウトと、処理全体のタイムアウト(30秒)に悩んでいる方が多いみたい
(に思える)。私もその一人。
パーツの多いページを取得しつつ、データストアに入れているとすぐ30秒くらい立ってしまう。大体、urlfetch 中も cpu 時間を使っているのか、cpu の使用時間が多すぎとコンソールに警告がでてますよ。
という訳で、いまさらながら、非同期 urlfetch を読んで実装を変更してみる。
しかし、30秒の応答縛りをどうするか?。元々 GAE は、単レスポンスが基本だからなぁ。
urlfetch のタイムアウトと、処理全体のタイムアウト(30秒)に悩んでいる方が多いみたい
(に思える)。私もその一人。
パーツの多いページを取得しつつ、データストアに入れているとすぐ30秒くらい立ってしまう。大体、urlfetch 中も cpu 時間を使っているのか、cpu の使用時間が多すぎとコンソールに警告がでてますよ。
という訳で、いまさらながら、非同期 urlfetch を読んで実装を変更してみる。
しかし、30秒の応答縛りをどうするか?。元々 GAE は、単レスポンスが基本だからなぁ。
2009/12/11
現在 Google App Engine にハマり中
現在、Google App Engine を使用したソフト開発を行っています。
開発言語は Python を使っております。う~ん。覚えやすい言語なのですが、
他国語の扱いに癖がありますね。(文字列が acsii なのか unicode なのか明確に区別が必要)
久しぶりに Web 系のプログラムで、浦島太郎状態です。
開発言語は Python を使っております。う~ん。覚えやすい言語なのですが、
他国語の扱いに癖がありますね。(文字列が acsii なのか unicode なのか明確に区別が必要)
久しぶりに Web 系のプログラムで、浦島太郎状態です。
登録:
投稿 (Atom)