remote_api_shell.pyの使い方 - たごもりすメモ
手元の端末からGAE production環境のデータストアに接続する GAE/pythonのSDKについているDatastoreモドキ(datastore_file_stub)は実に機能が貧弱で、トランザクションの衝突を手元でシミュレートしたりできない。これは本物のDatastoreの理解には割と困る。 で、本番環境のDatastoreに手元のコンソール(Pythonの対話実行環境)から繋ぎたいよね、と誰しも思うはずだ。思うよね。 この方法はGAE Python SDKに用意されている。自分で作ってみようと思うと色々面白いけどけっこう大変だし完璧に車輪の再生産なのであまりやらない方がいい。(と思う。自分は後悔した。) ただしWebのドキュメントには使い方がないし、SDK内にもない。該当のスクリプトのコメントを見ればわかるがそれもアレなので、ここに一応書いておく。ていうか「remote_a
GAE/P DataStore vs Memcached « python練習帳
csv2table この結果から、Memcachedの性能は、DataStoreと比べてReadで3倍程度、Writeで8倍程度高速であることが分かる。Memcachedのキャッシュヒット率が50％を超えるようなサービスであれば、Memcached導入によるパフォーマンスアップが期待できそうだ。 測定用プログラム 測定に用いたプログラムを掲載しておく。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 #!/usr/bin/env python from google.appengine.e
AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
GAE/Python 入門者向けTips « Stop Making Sense
August 2011 (1) July 2011 (1) June 2011 (2) April 2011 (2) March 2011 (2) February 2011 (2) January 2011 (6) December 2010 (6) November 2010 (5) October 2010 (8) September 2010 (2) August 2010 (3) July 2010 (9) June 2010 (4) March 2010 (1) February 2010 (7) January 2010 (2) はじめに この数ヶ月、GAE/Python の勉強を兼ねて幾つかのGAEアプリを作りました。 その過程で気づいたこと／ハマったことをまとめました。 Tips一覧 今回取り上げる Tips は次の通りです。 開発環境 Python2.5 を使う 最新の
Tools and Tips - Google App Engine - Google Code
Tools and Tips This page summarizes many useful tools and resources for working in App Engine. Use this document to find tools related to the following common uses or APIs. Index of topics (expand for full list) App Development AppStats Datastore SQLite Stub Local Unit Testing Samples for Google App Engine App Management Capabilities API DoS Protection Service Configuration Quota API Zipserve App
masayang's diary
連邦下院 州知事・副知事・司法長官・州務長官・その他州の要職 州上院 州下院 上記の選挙と同時に、州や自治体の条例に関する可否も投票する。カリフォルニアの場合以下の法案が挙がっている。 Prop 2 州予算安定化に関する法案 →州税の半分を債務返済に当てることを義務付ける法案。 Prop45 医療保険業者の料金改定に関する法案 →医療保険掛け金等の料金変更は事前に州による承認が必要とする法案。 Prop46 医師に対する薬物検査義務付け・医療過誤による賠償金上限引き上げ・濫用が懸念される薬物のデータベース化 →合わせ技法案なのでややこしい (1) 医療過誤に対する賠償金を現状の25万ドルから110万ドルに引き上げ、さらにインフレ調整を加える (2) 痛み止め等、濫用の可能性がある薬物の利用状況を州レベルでデータベース化し、処方箋を発行する前に医療保険会社がチェックすることを義務付ける (3
Datastore に泣いたアナタに捧ぐ（中編①） - Google App Engine - 暗号、数学、時々プログラミング
Google App Engine | 05:04 | 1つのエントリにどのくらいの分量を詰め込むか？を考えるのは結構難しい。勿論、仕事の片手間でやっている作業なので1回で全てを片付けるのは無理なのだが、そもそも記事として読んでもらうのに適切な長さというものがありそう。あんまり長いと「あとで読む」扱いになって後はそのまま、、なんてコトになりがちなんじゃないだろうか。。。せっかくGoogle App Engine って面白いオモチャに興味を持ってくれた人がいるのに、それは少し残念。もちろん、何かを学ぶ時に出来る限り楽しくするよう心がける事は出来ても、ラクにすることは無理な話なんだろうと思う。継続する為に自分のペースで好きに区切りをつけるのは受け手の自己責任って言っても良いのかも知れない。でも、せっかく起こった「ヤル気」を持続させる為に、自分に何か出来ないんだろうか？と考えずにはいられない。（
2008-04-17 - 暗号、数学、時々プログラミング
Google App Engine | 15:36 | トランザクション 引き続いてトランザクションについてチェックしていくぞ。ちなみに、オリジナルのドキュメントはココだ。App Engine のdatastore ではトランザクションをサポートしてる。コイツは1つ以上の処理をひとまとめにして、その全てが成功するか、或いは全てが失敗する、という結果になるものだ。アプリケーションは１つのトランザクション中で複数の処理を実施するコトが可能になってるぞ。この場合、関数オブジェクトとdb.run_in_transaction()関数を使う事になる。では、いつもの通りこれから説明する流れを先に見てみるとするか。 トランザクションの利用 トランザクションにおいて可能なこと トランザクションの用途準備はいいか？ トランザクションの利用 上でも述べたとおり、トランザクションってのはdatastoreの操
エンティティとモデル - Google App Engine - Google Code
Python æ¦è¦ CGI ç°å¢ ãã¼ã¿ã®æ ¼ç´ æ¦è¦ ã¨ã³ãã£ãã£ã¨ã¢ãã« ãã¼ã¿ã®ä½æãåå¾ãåé¤ ãã¼ã¨ã¨ã³ãã£ã㣠ã°ã«ã¼ã ã¯ã¨ãªã¨ã¤ã³ããã¯ã¹ ãã©ã³ã¶ã¯ã·ã§ã³ åã¨ãããã㣠ã¯ã©ã¹ GQL ãªãã¡ã¬ã³ã¹ ãªãã¡ã¬ã³ã¹ Model Expando PolyModel Property Query GqlQuery ãã¼ é¢æ° ä¾å¤ ãµã¼ãã¹ Memcache æ¦è¦ Memcache ã®
Datastoreのtips - スティルハウスの書庫の書庫
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
datastoreをちゃんと理解するための目次 - urekatのスカンク日記３
構造と仕組みをちゃんと理解する。いきなりJDOとかダメって。 http://songofcloud.gluegent.com/2009/11/slim3-datastore1.html 間違い、追加等ありましたらおしえてください。 1.概要 http://www.atmarkit.co.jp/fjava/index/index_bigtable.html 分散KeyValueストア:「巨大なハッシュ=datastore」に「小さなハッシュ=Entity」をたくさん詰め込む get/putの速度:データが無限に増えても遅くならない 全体図 2.スキーマレス Entity = Hashみたいなもの : Valueには全プロパティがシリアライズされて保存される Key / Kind プロパティの型 : int / string / date / list / ... 3.インデックス / クエリ
DBの制約を回避する6つのテクニック
Google App EngineのDBサービスはジョインができないなどの制約があるので，パフォーマンスを高めるには工夫が必要だ。キーワードは「キャッシュ」「非正規化」「分散」「事前計算」など。そのほか，処理性能の予測やフレームワークの利用などに注意したい。 米Googleの「Google App Engine」（以下，GAE）は，Webアプリケーションの開発・実行環境を提供するサービスです。前回はGAEの概要編として，サービスの全体像や開発の流れ，データベース・サービスの概要などを説明しました。Java言語とPython言語で開発でき，各種ライブラリやアプリケーション・フレームワークがそろっている一方で，「データベースのジョインができない」といった制約があることを解説しました。 今回はGAEの設計編として，GAE上で動作するアプリケーションを設計する際のコツを，主にデータベース設計を中心
DataStoreのスナップショットをとってバックアップする手順 - urekatのスカンク日記３
を考えてみました。どうでしょう。 サービスは止めずに（だいたい）整合性のあるスナップショットを取ります。 そもそも分散DBだから厳密なのは難しいんですよね？ 各サーバの時計はほとんどずれていない前提。 全体バックアップ [スナップショット時刻]を設定してdeploy put/delete時に updated_at < [スナップショット時刻] かつ [スナップショット時刻] <= 現時刻 なら [変更前のEntity]をシリアライズして保存する(Entity内でも別Entityでも。子にすればいいかも) [全Entity]をダウンロード [スナップショット時刻]の設定を解除してdeploy 保存しておいた[変更前のEntity]をダウンロード [全Entity]+[変更前のEntity]から「updated_at < [スナップショット時刻]」なデータを抽出 差分バックアップ 『[全Ent
DjangoやKayを使って新しいアプリを作る方法の自分用メモ - 西尾泰和のはてなダイアリー
何事も始める時が一番腰が重いものであり、腰を軽くするためには考えずに作業出来る必要があり、その為には手順を記録してなんども修正して洗練させる必要がある、だからとりあえず記録。DjangoやKayを使ってウェブアプリを作る方法 サービス名称を決める 他人に話してみる。「ダサッ」とか「え、何々って意味？(誤解)」とか言われたら考え直す。 ドメインが取れるかどうかを調べる。Google App Engineならその名前のアプリを作れるか調べる。取れないなら考えなおす。 ドメインを取る。アプリの名前をとる。作ってから取れなくなってたらガッカリするから。 プロジェクトフォルダを作る 僕はBitbucketでホスティングされているプライベートのMercurialのリポジトリの中に作る。 フォルダの中でstartprojectする RATIONALE: ここで作られるフォルダのルートにはapp.yaml
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google App Engine Anti Patterns