インデックステーブルについてMLで聞いてみた - スティルハウスの書庫の書庫
App Engineのインデックステーブルについて、いまいち理解できてない部分や細かな疑問がいくつかあったのでMLで聞いてみました。 インデックステーブルの各行はどう構成されてる？ How Entities and Indexes are Storedで説明されているEntitiesByProperty ASC/DESCテーブルは、実際には キー："アプリID／カインド名／プロパティ名／プロパティ値" 値：エンティティのキー という構成か？それとも、 キー："アプリID／カインド名／プロパティ名／プロパティ値／エンティティキー" という構成で、値はとくに無いのか？ という質問に対し、Nickさんは 「後者で正しい」（インデックス行のキーにエンティティキーが含まれる構成） と返答してくれました。 また、インデックスについて詳しくはGoogle I/O 2008のUnder the Cover
BigtableとSmalltable - スティルハウスの書庫の書庫
App Engineによる設計手法でひとつ私が実案件で試してなかなかうまくいったと思ったのは、「Smalltable」って私が勝手に呼んでいるアーキテクチャです。簡単にいうと、「複数クライアントのローカルのSQLite間をDatastoreを介して同期する」仕組みです（こういうの一般に何パターンと言うのでしょう…教えてください！）。 クライアントはHTML5やAIR、iPhone、Android等のリッチクライアントで（実際に実装したのはAIRとiPhoneです）、SQLite等の小規模RDB（以下、Smalltable）をローカルに持つことが前提 Smalltableは、Datastoreが保持するすべてのデータのうち、そのユーザーが常時使用するデータのみ保持するサブセット アプリケーションの大半のロジックをリッチクライアント内のSmalltableだけで実装する すべてのレコードにはク
Memcacheでスピンロックを実装してTask Queue処理結果を集約してみるテスト - スティルハウスの書庫の書庫
TaskQueueで分散処理した結果をまとめるときは、排他を考慮する必要があります。Datastoreを使う場合なら、単に結果を新規エンティティとして追加したり、エンティティグループの楽観排他を使ったりすればOKです。一方、やっぱりMemcacheでスピーディーに集約したいよ、という場合は、Memcache上で排他を実装する必要があります。以前のエントリにちょろっと書いたMemcacheService#incrementでスピンロックという方法について説明してほしいというコメントをid:miztakaさんよりいただいたので、ここに改めて書きたいと思います。 Memcacheでは排他制御が必要 ご存じのとおり、App Engineはデフォルトで複数のApp Serverによるクラスタが構成されており、またMemcacheサービスはクラスタ全体で共有されるグローバルなキャッシュとして機能します
Google App Engineのtips集 - スティルハウスの書庫の書庫
（随時更新中です。間違いなどありましたらコメントをお願いします！） このページの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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
