Googleの巨大分散データストアBigtableとDatastoreを理解する
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
GAE/Python - DataStoreの使い方をまとめてみた
DataStoreとは 本記事内のDataStoreは、GoogleAppEngineのデータストアのことを指す。GoogleAppEngineは、ファイルの書き込みが一切できないため、DataStoreを使う以外にデータを永続化する方法はない。短期であればmemcachedに保存することもできるが、memcachedに保存されたデータは保存期間が保証されないため、一時データをキャッシュして高速化(or 負荷軽減)以外には実質つかえない。 DataStoreの特徴 DataStoreの特徴は、スケーラブルであること。データ数が1万件でも1億件でもほぼ同じ時間で結果が返ってくる（らしい）。ただし、通常のRDBでは簡単にできる操作がDataStoreでは非常に重い処理だったり、不可能だったりするので注意。 苦手な処理 件数のカウント ⇒件数のカウントは、データ全体を取ってくる処理に近いだけの処
Google App EngineとPythonでの素直な開発環境の構築(TDDができるように) - Masatomo Nakano Blog
追記: 続編的なものを書いた。 今年は色々なことに手を出してみよう、ってことで少し前からGoogle App Engine(以下GAE)で、あるモノを作っている。モノ自体は近いうちに公表できると思う。 基本的に、Pythonと標準っぽいフレームワークだけでやってみている。作っているものがそれなりにシンプルなのと(だからこそGAE!)、GAEでそれなりの規模の開発をするのが自分自身初めてということもあり、あまり色々なレイヤーを重ねて手こずりたくなかった、ってのがその理由。 ただ、GAE初心者なので、「いやいやそれは今時ないよ」「XXの方が100倍いい」とかあったら教えてくれると嬉しいので今のところの環境を書いておくことにした。今ならスイッチ可能。 今作っているものがJSONファイルを入出力するだけのものなので、HTML生成パートみたいのはない。 1. フレームワーク 上にも書いたように、今回
【クラウドコンピューティング】 エンタープライズとクラウド
先日、ある大手企業のお客様にGoogle App Engineの提案を行った。 Google Apps、Google App Engineには、前記事で書いたようなリスクもあり、いざやってみろと言われると実は困ってしまう。できるならリスクを引き受けたくない。提案の際にはリスクとかデメリットの説明に多くの時間を割くようにしている。どうしてもやりたいなら、すべてのリスクはお客様が持つこと。それが受けるときの最低の条件である。 そんな感じでプレゼンをしたところ、逆にクレームをもらうことになった。 「App Engineのすばらしさを提案してくれると思ったのに、危険なので主業務では使わない方がいいとか、サービスが使えなくなってもお客様の責任でお願いしますって・・・結局、使えないということか！？」 彼は以前から私がApp Engineに熱心なことを知っていて、今回は善意で社内調整して提案機会を作って
App Engineではどの言語を使えばいいのか - ひがやすを技術ブログ
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
Slim3 1.0.0 Released - ひがやすを技術ブログ
Slim3 1.0.0をリリースしました。 リリースノートはこちら http://sites.google.com/site/slim3appengine/release-notes ダウンロードはこちら http://code.google.com/p/slim3/downloads/list Slim3の主な特徴は次のとおりです。 Global Transactions Faster than JDO/JPA Fast spin-up HOT reloading Type safe query 詳しくはこちらをどうぞ http://slim3.org Seasar2譲りのHOT reloadingやS2JDBC譲りのType safe queryなどもありますが、最大の特徴は、Global Transactionsを実装していること。 http://d.hatena.ne.jp/hig
Google App Engine をはじめてみよう
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
Post-mortem for February 24th, 2010 outage
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message Post-Mortem SummaryThis document details the cause and events occurring immediately after App Engine's outage on February 24th, 2010, as well as the steps we are taking to mitigate the impact of future outages like this one in the future. On February 24th, 2010, a
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
Handling downtime: The capabilities API and testing - Nick's Blog
Posted by Nick Johnson | Filed under python, tech, app-engine, coding, capabilities After the unfortunate outage the other day, how to handle downtime with your App Engine app is a bit of a hot topic. So what better time to address proper error handling for situations where App Engine isn't performing at 100%? There's three major topics to cover here: Handling timeouts from API calls, using the Ca
App Engine SDK 1.3.1, Including Major Improvements to Datastore!
News, notes, tips and tricks from the Google App Engine Team We are excited to announce the release of version 1.3.1 of the App Engine SDK for both Python and Java. While this release contains plenty of new features and fixes, we've concentrated on using our very first SDK release of 2010 to improve the heart of many App Engine applications: the Datastore. Here are the three major improvements tha
参考になりそうなオープンソースのGAEアプリ - present
GAE アプリを開発しているけど、Python と GAE の両方とも初心者なので、どう実装したらいいのか迷う。そこで、「オープンソースのGAE向けアプリを参考にすればいいじゃないか」と考え、ネットで探してみた。 kay-framework - A web framework made specifically for Google App Engine - Google Project Hosting GAE に特化して開発された Python フレームワーク。 アプリの開発に使ってもいいし、オレオレフレームワーク開発の参考にするのもアリ。 google-app-engine-oil - Yet another web framework on App Engine - Google Project Hosting Ruby on Rails を意識して作られた GAE/Python 向
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
ここが大変だよ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以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
#appengine でスキーマ変更に対応するバッチ処理を行う
2009/11/05追記ひがさんより指摘を頂いて、30秒制限に関する補足を本文中に青字で追記しました。いつもありがとうございます、助かります＞ひがさん ここから本文 タイトルの処理について、いくつかノウハウを書いておきます。ポイントは以下の2点。 全てのエンティティにスキーマバージョンを保持する ローカル環境からデプロイ環境へ直結してバッチ処理を実行する事で、30秒制限なんて無視してしまう 実例をもとに説明してみます。最近、appengine java night用のまとめページとかに使おうとしているサイトを運営していて、そこに「TwitterでAppEngine関連についてつぶやかれた内容を収集する」という機能を実装しました。しかし、つぶやきを保存する際の投稿者の情報として「Name」を保持しているものの「ScreenName」を保持しておらず、投稿者のタイムラインページへのリンクを作成
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Top Hat | Dynamic Courseware Platform