Google App Engineでの検索パターン - 市中弾き語りの刑
id:higayasuo さんにTwitter上でいろいろ教わったので、メモ。 検索条件が複雑な場合 業務アプリなどでよく見かける、複雑（不特定）な条件で、かつ、特定の並び順でデータを抽出するような場合のパターンです。 例えば、 データを抽出する条件が 「場所」「日時」「部署」「担当者」...と複数あったとして、 それぞれの項目が、 ユーザーによって指定されたり、されなかったりした場合、ソートがあるために、 入力、未入力の組み合わせの数だけ複合インデックスが必要ですが、 （Datastoreではフィルターとソートのプロパティが異なると複合インデックスが必要です。） これを全て静的に（事前に）定義するのは非現実的です。 で、id:higayasuo さんのアドバイス adhokなqueryはeq filterだけqueryで実行してnot_eqやsortはin-memoryでやるのが最も簡単
Distributed Transactions on App Engine - Nick's Blog
Posted by Nick Johnson | Filed under coding, app-engine, cookbook, tech This is the fourth in a series of 'cookbook' posts describing useful strategies and functionality for writing better App Engine applications. As promised, today we're going to discuss Distributed Transactions on App Engine. Distributed transactions are that feature that you didn't know you needed until they were gone: The abil
App Engineのユニーク制限を正しく理解しよう - ひがやすを技術ブログ
Google App EngineではRDBMSのようなUnique Indexをサポートしていません。ユニーク制限を実現する場合は、トランザクション中でKeyを使ったgetとputを組み合わせる必要があります。 ここでは、email addressがユニークだったらそれを確定してtrueを返し、そうでない場合にはfalseを返すコードを考えます。 最初にトランザクションを使わないコードを見てみましょう。KeyFactory.createKeyの最初に引数は、kindといってテーブル名みたいなものです。 public boolean putUniqueEmailAddress(String value) { DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Key key = KeyFactory.cr
ここが大変だよBigtableとGoogle App Engine
ここが大変だよBigtableとGoogle App Engine：分散Key-Valueストアの本命「Bigtable」（3）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 月間3000万PVの大規模サイトの運用費が月額4万円!? 月間3000万PV相当の膨大なトラフィックを楽々とさばく大規模サイトが、月額4万円弱で運用されている。 Google App Engine（以下、App Engine）が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
あしたのオープンソース研究所 -CouchDB 座談会-
しおや「最近クラウド・コンピューティングが流行しているということで、どんな技術があるんだろうとみていくうちに、クラウドのプラットフォームの話、アマゾンのEC2だとかWindows Azureだとかはいっぱい出てるんですけど、それを使って書いたアプリケーションの話はあんまりないな、と。もうひとつは、私はログ管理の製品も担当しているんですが、大量のデータをログとして蓄えないといけないという時に、具体的にクラウドだったらどういうソリューションがあるのかな、と。そう思って色々見渡しているときにクラウドの処理能力を活かしたデータベースということでCouchDBに興味を持ちました。きっかけはIBMのDeveloperWorksの記事を見たことで、今少し使ってみてます」 しおや「この図は結構いろいろ描き込んであるんですけど、CouchDBはErlangというプログラム言語で記述されたデータベースでして、
DBの制約を回避する6つのテクニック
Google App EngineのDBサービスはジョインができないなどの制約があるので，パフォーマンスを高めるには工夫が必要だ。キーワードは「キャッシュ」「非正規化」「分散」「事前計算」など。そのほか，処理性能の予測やフレームワークの利用などに注意したい。 米Googleの「Google App Engine」（以下，GAE）は，Webアプリケーションの開発・実行環境を提供するサービスです。前回はGAEの概要編として，サービスの全体像や開発の流れ，データベース・サービスの概要などを説明しました。Java言語とPython言語で開発でき，各種ライブラリやアプリケーション・フレームワークがそろっている一方で，「データベースのジョインができない」といった制約があることを解説しました。 今回はGAEの設計編として，GAE上で動作するアプリケーションを設計する際のコツを，主にデータベース設計を中心
グーグルのBigtableが耐障害性を強化、Megastoreレプリケーションで
グーグルがGoogle App EngineやGoogle Appsのデータベースなどのデータベースとして利用しているのが、「Bigtable」と呼ばれるキーバリュー型ストアです。 グーグルは以前からこのBigtableを複数のデータセンターにまたがって運用し、万が一障害が発生したとしてもデータを失うことがないように、データセンター間のバックアップなどを行ってきました。 しかし、先月の記事「データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ」で紹介したように、グーグルといえどもこうしたデータセンターにまたがるデータベースを安全に運用する方法については試行錯誤しており、7月には6時間にわたり大規模なデータベースの障害を引き起こしていたことは、「Google App Engineにデータストアの障害発生。復帰まで約6時間、原因は現在も不明」で紹介しました（この件については後日、原
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google BigTable Paper Summarized