App Engineで大量のデータを並列処理するフレームワーク ElShard を作っています。batch addとdeleteのサンプルができたので、とりあえずまとめてみます。 ElShardは、入力リストを分割して処理して集約する考え方に基づいています。並列処理はApp EngineのTaskQueueで実現しています。タスク間では10kBのペイロードしかやり取りできないため、データをやり取りする用途には適していません。そのため、実際のデータはDatastoreに格納しておき、キーをタスク間でやり取りすることになります。 現段階では集約をどうやって実現するか未定ですが、キーでソートされるというDatastoreの性質をうまく利用できる気がします。Matcher APIが使えるといいなぁ。 リストを処理する ElShardでは、InputとTaskの2種類のタスクを組み合わせてジョブネッ
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー Guidoがここ数ヶ月関わっているというGoogle App EngineのDatastore Plusについてブログで紹介しています。 App Engine標準のdbモジュールの代替として使われるべく開発されているモジュール。dbモジュールで提供されているKeyやqueryが変更可能(mutable)であるなど，デザイン上の不合理を解決したより明確な設計を採用(Guidoが直したかったんですね)。 またdatastoreへの非同期アクセスを可能にしています。重たいクエリ，相対的に遅い書き込みにかかる時間や，レイテンシを回避できるようになります。datastore非同期への非同期アクセ
So, something I’ve spent a lot of time doing recently, is waiting for the AppEngine Bulk Loader to finish. At the moment, there’s nothing in the admin console to bulk add, edit or delete entries in your Datastore – you can create or edit entities singly, and you can tick off and delete up to 20 at a time, but that’s your lot. The officially-sanctioned bodge for this is the Bulk Loader. Though not
先日App Engine SDK 1.2.8 for Javaがリリースされました。 公式のリリースノートに記載されていない非常に重要な機能追加がありますので、ここで紹介します。基本的にすべてデータストアのお話です。しかもLow-Level API。 ご指摘いただきまして、ミスリードしそうな個所について修正しました。今後もわかったことがあれば追記していく予定です。 プロダクション環境でカーソルが予想外の動きをしました。このため、開発環境と両方で動くコードに更新しました カーソルの追加 これまでデータストアでページング処理を行う場合には、ページング用のプロパティを用意したり、ページング用のインデックスを用意したりと、様々な力技が提案されてきました。 しかし、今回のアップデートでCursorという「クエリの現在位置を覚えておくオブジェクト」がひっそりと追加されました。これを利用すると簡単にペー
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
早すぎる最適化オジサン @makotokuwata まずAppEngineがいまいちブレークしないのは、お金を集める仕組みが用意されていないことと、Datastore (Bigtable) の使い方が難しいことの2点だと思う。 早すぎる最適化オジサン @makotokuwata 1点目の、集金システムについて。AppEngineと比べて、たとえばiPhoneアプリは十分ブレークしているといえるけど、これはやはりiPhoneアプリは販売して収益を出せる可能性があることが大きい。 早すぎる最適化オジサン @makotokuwata それに比べて、GAEはインフラと開発環境は提供するけど、集金の仕組みは提供できてない。言い方を変えると、無料で使える環境は提供しているけど、収益を上げるための環境は提供できてない。そこがiPhoneアプリと違うところ。
データストアで時系列データをカレンダー表示したい場合、どのような設計が最適でしょうか。下記のモデル（Event）を考えます。 プロパティ 型 説明 key com.google.appengine.api.datastore.Key キー（userId/time） userId java.lang.String ユーザID time java.util.Date 日時 value int 数値 下記のアクセスパターンを考えます。 カレンダーに1ヶ月間のデータ（日毎の平均値など）を表示する。 カレンダーの日付をクリックすると、1日のデータを表示する。 最新10件のデータを表示する。 ログインユーザのデータを対象とする。 私の考える設計 まず、下記のモデル（EventCalendar）を作成します。 プロパティ 型 説明 key com.google.appengine.api.datasto
GAEのSDKを1.3.3にバージョンアップしたら、データストアの単体テストがコンパイルエラーに! ドキュメントを見ると、どうやらテストケースの書き方が変わったらしい。(1.3.1 - 1.3.2はスルーしていたので、実はずっと前からかもですが) ということで、SDK1.3.0の頃に書いたテストケース作成手順を1.3.3での手順に更新しておきます。ユーティリティクラスが用意されて、以前より少ないコードで済むようになってますよ。 単体テストとは? 単体テストでは、 ローカルでGoogle App Engineのサーバーを起動することなしに、 データストアにアクセスするモジュールのテストを記述できます。 公式なドキュメントはこちら。日本語のドキュメントはまだ更新されていない(2010-05-01 現在)ようなのでご注意。 概要 必要なモジュールをプロジェクトに追加 テストケース内でLocalS
TaskQueueで分散処理した結果をまとめるときは、排他を考慮する必要があります。Datastoreを使う場合なら、単に結果を新規エンティティとして追加したり、エンティティグループの楽観排他を使ったりすればOKです。一方、やっぱりMemcacheでスピーディーに集約したいよ、という場合は、Memcache上で排他を実装する必要があります。以前のエントリにちょろっと書いたMemcacheService#incrementでスピンロックという方法について説明してほしいというコメントをid:miztakaさんよりいただいたので、ここに改めて書きたいと思います。 Memcacheでは排他制御が必要 ご存じのとおり、App Engineはデフォルトで複数のApp Serverによるクラスタが構成されており、またMemcacheサービスはクラスタ全体で共有されるグローバルなキャッシュとして機能します
Google App EngineのWebサイトに「App Engine Product Roadmap」と名付けられた、文字通り今後のApp Engineのロードマップを説明したページがあります。 このページに書かれている説明によると、ロードマップとして挙げられている項目はApp Engineチームによって開発が進められており、多くは6カ月以内に実現することを意図しているとのこと。また、項目はつねに更新されているとのことです。 ただし、このページに書かれているロードマップの項目はすべてが具体的に書かれているわけではないため、実際にどのような実装として登場するのか分からないものもあります。 Javaのプログラミングなどに詳しいスティルハウスの佐藤一憲氏は、このロードマップを独自に解釈したエントリ「 #appengine の未来はこうなる！」を2日前にブログにアップしています。今後Googl
Google App Engineのsession情報はDatastoreを使っているため若干遅い。セッションを使わないアプリならセッションを無効にしておいた方が良い。 appengine-web.xmlにてfalseする ※デフォルト（sessions-enabledの記述がない場合）ではセッションは無効になっている。 Datastoreを使うということはDatastoreTimeoutExceptionが発生する可能性があるということ。なので極力切っておいたほうがいいようだ。 あと、jspはセッションがデフォルトでは有効になっているようなので無効にしておいた方がよい。 <%@page pageEncoding="UTF-8" session="false"%>今日のエントリは全部twitterの情報メモ。 追記 いくつかtwitterでツッコミを頂けたのでjspのセッション無効が意味が
Kindless Ancestor Queryをローカル環境で使用する #appengine
AppEngineで実装されているQueryで、Kind指定なしで親キーのみ指定して、親キーに属するEntityGroupをKindをまたいでゴッソリ持ってくるという便利なクエリがあるのですが、開発環境で動かないという問題を抱えています。開発環境で動いてくれないって事はデプロイ前にテストできないって事で、結局プロダクトコードに含めることもできずまだ使えないカンジで勿体無いです。 makeSyncCallという仕組みで開発環境とProduction環境のDatastoreを直結するとテストできない事も無いですが、無理矢理過ぎるのでそれは考慮してません ApiProxy.Delegateの出番このブログを読んでくれている方はもう聞き飽きておられる事でしょうから詳しく説明しませんが、アレです、フックします。んでProtocolBufferをゴリゴリと触ります。 今回は、以下のようにいじってやる作
JDOをそのまま使うとPagingができないことは前記事で述べたとおりだが、DatastoreAPIを使えば可能なので、今回はその方法について述べたいと思う。前記事と同様、請求書アプリを元に説明する。 KeyとCounter まず、基本となるEntityのInvoiceBaseとInvoiceの構造から。 InvoiceBaseは、Invoiceレコードを保持するする親のEntityだ。InvoiceBase（親）に紐づくInvoice（子）は１：ｎのOwnedな関連である。また、Invoiceレコードの件数を格納するcounterプロパティをもつ。InvoiceのKeyは、トランザクションで括る必要があってKeyを連結させているが、拙作ライブラリReflex GAEのAPI、keyUtils.getChildKey()を使って、連結されたInvoiceのKeyを取得している。（Refle
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
