「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
Google Drive
どこからでもアクセスできます。Google ドライブは、ウェブ上、自宅、職場、外出先など、どこでも利用できます。どこからでも自分のデータにアクセスして、編集、共有できます。5 GB を無料でご利用いただけます。 Google ドライブは次の端末でご利用いただけます:Windows と MaciPhone and iPad (coming soon)Android 搭載端末 安全な場所に ファイルを保管します。災難は思いがけず訪れます。携帯電話が水没したり、ノートパソコンが故障することがあります。ご使用の端末に何があっても、Google ドライブならファイルが安全に保存されています。 ただ保存できるだけでなく、共同編集が可能です。Google ドライブでは単にファイルを保存するだけではなく、あらゆる端末から目的の相手にだけファイルを共有したり、共同編集することができます。 Google ドラ
中小企業では、社員のアカウント管理がGoogleやセールスフォースなどクラウドに移行していくのではないか
中小企業では、社員のアカウント管理がGoogleやセールスフォースなどクラウドに移行していくのではないか 「社員のアカウントを社内システムで管理するのは大企業だけになって、中小企業ではセールスフォース・ドットコムやGoogle Appsなどクラウドに移行していくのではないか」。8月5日に開催されたイベント「OpenID TechNight #7」で、企業のアカウント管理に関する予想を語ったのは工藤達雄氏。7月に米国で行われた「Cloud Identity Summit 2011」の報告の中でのことでした。 一般に多くの企業は社員のアカウントを社内で管理しています。社内のディレクトリサーバで社員情報を管理し、それを元にシングルサインオンの仕組みを用いて業務アプリケーションやメール、グループウェア、ファイル共有などへログインできるシステムを構築している企業もあるでしょう。 しかしこうした規模の
Song of Cloud: 送金のトランザクション処理パターン
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
データセンターが「落ちる」ことを想定したグーグルのアーキテクチャ
サーバを安全に運用する施設として構築されるデータセンターですが、グーグルではそのデータセンターですら"落ちる"ことがあると想定してアーキテクチャを構築しています。 米グーグルが今年の5月に行ったイベント「Google I/O」で、同社のGoogle App Engine datastore leadであるRyan Barett氏が行った講演「Transactions Across Datacenters (and Other Weekend Projects)」のビデオがYouTubeで公開されました。 Barett氏は、担当しているGoogle App Engineのデータベースに関してグーグルが「multihoming」（マルチホーミング）と呼ぶ複数のデータセンターを用いた処理を実現している理由として、データセンターが自然災害や停電に見舞われたり、メンテナンスなどによるデータセンターの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
［速報］Google Cloud「東京GCPリージョン」がついに今日から正式運用を開始。日米間を毎秒60テラビットでつなぐ最新の海底ケーブルと接続
TechCrunch | Startup and Technology News