Google AppEngineについて思うところ
早すぎる最適化オジサン @makotokuwata まずAppEngineがいまいちブレークしないのは、お金を集める仕組みが用意されていないことと、Datastore (Bigtable) の使い方が難しいことの2点だと思う。 2010-11-05 23:11:32 早すぎる最適化オジサン @makotokuwata 1点目の、集金システムについて。AppEngineと比べて、たとえばiPhoneアプリは十分ブレークしているといえるけど、これはやはりiPhoneアプリは販売して収益を出せる可能性があることが大きい。 2010-11-05 23:12:58 早すぎる最適化オジサン @makotokuwata それに比べて、GAEはインフラと開発環境は提供するけど、集金の仕組みは提供できてない。言い方を変えると、無料で使える環境は提供しているけど、収益を上げるための環境は提供できてない。そこが
appengine ja night #4 Transaction Puzzlers
#ajn4 で発表したスライド。 app engineでのトランザクションでビルディングブロックとなることを期待したパターン集。Read less
Song of Cloud: グローバルトランザクション処理のパターン
送金のトランザクション処理パターンでは、Google App Engine (GAE)のEntity Groupにまたがるトランザクション処理を行う方法について紹介しました。また、それに少しだけ最適化を施した結果、下図のような処理になりました。 しかし、このトランザクション処理はいくつかの制約があります。 (a) 送金中に合計金額がずれる (b) 送金先の口座に制約をかけられない このトランザクションはEventual Consistency (結果整合性)というレベルの整合性保証しかしないため、2つのEntity Groupの値にずれが発生する場合があります(a)。たとえば、口座(A)から口座(B)に1000円だけ送金する場合、(1)と(2)の間は「口座(A)から出金したが、口座(B)に入金されていない」という状態になります。 また、送金元の口座に制約はかけられますが、送金先の口座に制約
Cursorをつかったページング - hidemonのブログ
1.3.1までは，データストアからの読み出し個数が1000個以下に限られていた．なので，1000個以上のデータを取り出すときに，rangeを使ってやろうとするとうまく動かなかった．というのは，range(990, 1010) とやると，0から1100までのキーをとりだして，その後，990から1010までの中身を取りに行く，という実装なので，0から1100までのキーを取りだすという時点で，落ちてしまうからだ．また，そもそも20個だけ読みたいのに，1100個キーを取りだしてしまうので非効率． これまでの方法 そこでよく知られているテクが，これ．条件式を組み合わせることで，rangeのオフセットを常に0にしたままスキャンする方法．このサンプルはPythonだけど，JDOで書いてもそのまま動く． 1.3.1 ところが，1.3.1になって事情が変わった．1000個の制約が無くなったので，とりあえず性
Google App EngineでGlobal Transaction - ひがやすを技術ブログ
Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
