BigtableをjQueryで操作できる「gaedirect」とは：クラウドとgaedirectでできる緊急対応マッシュアップ（1）（1/3 ページ） 緊急時の“クラウド”の有用性 このたびの東日本大震災で被災された皆さま、ご家族ならびに関係者の皆さまに、心からお見舞いを申し上げます。今回の大震災では、多くのWebサイトでアクセス不能状態が発生したのは、記憶に新しいところです。緊急時こそ、必要な情報を入手するために多くの人がWebサイトにアクセスするわけですが、このような切実に情報が必要とされるときに限って、トラフィック増大によるアクセス不能が発生してしまう状況が多々見られました。 しかし、このような緊急時対応サイトをGoogle App Engine（以後、GAE）などによってクラウド化しておけば、このような問題は解決できたといえます。クラウドを使用すれば、ユーザーアクセスが急激に増加
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
Slim3本の予約が開始されました。本屋で実際に買えるようになるのは、7/28(水)からです。 http://www.amazon.co.jp/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E5%BE%B9%E5%BA%95%E6%B4%BB%E7%94%A8-Slim3-Google-Engine-Java/dp/4798026999/ref=sr_1_2?ie=UTF8&s=books&qid=1280117730&sr=8-2 この本は最初、私一人で書いていたのですが、執筆が進まず、出版は暗礁に乗り上げていました。そこに救いの手を述べてくれたのが、@shin1ogawaです。@shin1ogawaが執筆を担当し、私が監修するというスタイルに変えることによって、無事出版にこぎつけることができました。本当に
App EngineのブログにMigration to a Better Datastoreという記事が出ていたので，野良翻訳してみる． 要約 これまでは，Bigtableの複製機能でデータセンタ間の複製を行っていたが，整合性が無くなる可能性があるため，データセンタがまるごとクラッシュした場合の復旧が遅くなっていた． MegastoreというBigtableの上の機構の複製機構を利用することでこの問題を解決．今後は，データセンタがクラッシュした場合には，ある程度のデータロスはあるが，整合した状態で，別のデータセンタをつかって続行できるようになる． この移行を9/22の太平洋時間5pmにやる．1時間ぐらい落ちるから覚悟しておけ． よりよいデータストアへの移行 App Engine チーム Ryan Barrett Google は，経験的に，すべてのことを健全な懐疑主義であつかうべきだと知っ
はじめに 本連載ではクラウドコンピューティングで利用される分散データベースの技術について紹介しています。第1回はクラウドコンピューティングの技術について概説し、その環境に対応するための新たな分散データベースの必要性について述べました。 今回はクラウド向け分散データベースの具体的な事例として、Googleの「BigTable」とAmazonの「Dynamo」について紹介したいと思います。少し耳慣れない言葉も出てくるかと思いますが、最後までお付き合いいただけると幸いです。 一般にハイスループット（高効率）とローレイテンシー（低遅延）がトレードオフの関係にあることはよく知られていますが、クラウドシステムもその例外ではありません。これらは最近でも、クラウド技術のシステム特性を理解する上で欠かせないトピックですが、分散データベースに関しては、ハイスループット重視のBigTableに対し、ローレイテン
Java Cloud Meeting Fukuoka2010に参加してきた
2/20(土)に クラウドで変わるJava開発 – Java Cloud Meeting Fukuoka 2010 というイベントがSeasarFoundationより開催されました。 今回はGoogle App Engine Javaがメイン、という事でスピーカーとして声をかけていただけたのでスピーカーとして参加してきました。 私は「Google App Engine Java プラットーフォームの勘所」と言うことで、「プラットフォームの説明」「各サービス（機能）の説明」、サービスに付いてはDatastoreサービスを重点的に説明するという事を目的にしました。さらに、Datastoreサービスでは「そろそろJDOを公にDISっても言い時期かな」という判断で、思いっ切りDISる事にしました。今まで勉強会などで発表をするときは、できるだけ「LLAPI, JDO, Slim3」どれを選ぶかは好
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
App Engineのインデックステーブルについて、いまいち理解できてない部分や細かな疑問がいくつかあったのでMLで聞いてみました。 インデックステーブルの各行はどう構成されてる？ How Entities and Indexes are Storedで説明されているEntitiesByProperty ASC/DESCテーブルは、実際には キー："アプリID／カインド名／プロパティ名／プロパティ値" 値：エンティティのキー という構成か？それとも、 キー："アプリID／カインド名／プロパティ名／プロパティ値／エンティティキー" という構成で、値はとくに無いのか？ という質問に対し、Nickさんは 「後者で正しい」（インデックス行のキーにエンティティキーが含まれる構成） と返答してくれました。 また、インデックスについて詳しくはGoogle I/O 2008のUnder the Cover
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
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
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
RESTfulなWebサービスとワンソースマルチビュー 先日行ったプレゼンの請求書DEMOでは、以下のように、HTMLの請求書を直接編集後、PDFを表示させるというところをお見せした。(以下のHTMLを表示させて右クリック、Searchで何かを選択してデータを読み込む、さらに右クリックでPDFを選択して生成） 請求書デモ これは一見、統合されたアプリのように思えるかもしれないが、単なる疎結合なサービスの組み合わせであるにすぎない。つまり、JSONやXMLでCRUDできる機能だけが実装されたRESTfulなGAE上のサービスと、そのサービスに対してAJAXでアクセスするHTMLとJavaScript。そして、GAEのサービスからXMLを取得してPDFを生成するReflex iTextサービスの３つの組み合わせで成り立っているものである。特筆させていただきたいのは、ブラウザで表示させたHTML
前回に引き続き、RESTfulアプリの解説をおこなう。今回はModeling編。本当は最初に説明すべきところ。 Entity設計 外部設計において基本となるのはBCEモデル。３分で分かる設計の話 にもあるように、Entity設計とは項目の整理をすること。項目の抽出は画面設計を行ってからじゃないとできないので、実際には、Boundary＝＞Entity＝＞Controlの順番で設計を進めていくことになる。Entityの設計では、基本的には名前と型と多重度の定義を行うだけでよいのだが、もう少しがんばって、具体的にXMLのインスタンス(項目とデータを含むもの）まで作成するとよいと思う。ちなみに、請求書アプリのXMLインスタンスはこんな感じになった＝＞XML ReflexではModel設計のことを敢えてEntity設計と言うようにしている。Modelは型で、Entityはその型から作ったインスタン
JDOでListなどのコレクションを取得する時の注意点
Listのプロパティを取得しようとしたら以下のような例外が出た。 javax.jdo.JDODetachedFieldAccessException: You have just attempted to access field "tagNameList" yet this field was not detached when you detached the object. Either dont access this field, or detach it when detaching the object. at jp.co.tricell.sonicboom.Mutter.jdoGettagNameList(Mutter.java) at jp.co.tricell.sonicboom.Mutter.getTagKeys(Mutter.java:137) at jp.co.t
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message 下のコードですが、想定する動作を行いません。 retrieveを明示的にいれてあげないと、 キャッシュを読み込まないせいでエラーになるみたいです。 キャッシュ管理って、基本自動だと思ってたのですが、 錯覚なんでしょうか？ なんか予想の斜め上いく動作です。 package xxx; import java.util.List; import javax.jdo.annotations.IdGeneratorStrategy; import javax.jdo.annotations.IdentityType; import
GAEのJDOのモデルは、ざっくりいうと4種類の状態があります(本当はもっといっぱいあるけど、4つをおさえておけば普通はOK)。 transient persistent detached hollow モデルをnewして、PersistenceManager#makePersistent()を呼ぶまでは、transientです。 PersistenceManager#makePersistent()がよばれるとpersistentな状態です。persistentなモデルの状態は、PersistenceManagerをcloseするかTransactionをcommitしたときに、データストアに反映されます。 PersistenceManagerをcloseしたときからが、運命の分かれ目。何の設定もしないとhollowになり、lazy loadingされているオブジェクトに触ろうとするとエ
昨日はlow-level APIでTODOリストサービスを作ってみたんだけど、Slim3のDatastoreの機能が追加されたようなので、そちらを使って同じようなサービスを作ってみた。 Slim3 Datastoreは内部ではlow-level APIを使っているのでJDOを使うよりパフォーマンスがいいらしい。 Google グループ JDOよりも3倍近く早い感じだね。(まだ、パフォーマンスが影響するようなサービスは作ってないんだけど。。どっかで試してみよう) そして、low-level APIとSlim3 Datastoreの最大の違い。Slim3ではlow-level APIのEntityに当たるクラスをモデルとして定義して使えるという所。なので、KindのプロパティにアクセスするときEntityの場合、entity.getProperty(String propertyName)(ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
