Bigtable、Megastoreに続くGoogleの最新世代のデータストアSpannerについての皆さんの考察をまとめました。
![Google Spannerまとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/224aaf745e0ebef417b7c6bfacfa05e89dc36a78/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F5804cebd10efe61f80e2b5408c555cc7-1200x630.png)
Spannerお勉強メモです。かなり久々の技術系エントリだ。。 朝起きてTwitterみてたら@ichiro_satoh先生のこんなつぶやきが。 現時点ではGoogle Spannerの一番詳しい資料かも。berlinbuzzwords.de/sites/berlinbu…— ICHIRO SATOHさん (@ichiro_satoh) 6月 6, 2012 。。やっぱりGoogleのインフラ情報は学会発表で流れてくるケースが多いなぁと思いつつ、先日公開されたF1(Google規模でスケールするRDB。AdWords用に使われてる)でもSpannerが重要なカギを握っているので、ついカッとなってスライドの要点を訳してみました。 原文はこれです:Building Spanner - Better clocks → stronger semantics(セッションのビデオ) 一行に要約すると、
Spanner is Google's scalable, multi-version, globally-distributed, and synchronously-replicated database. It is the first system to distribute data at global scale and support externally-consistent distributed transactions. This paper describes how Spanner is structured, its feature set, the rationale underlying various design decisions, and a novel time API that exposes clock uncertainty. This AP
Hudsonの分散ビルドの実装の肝になっているのは、クロージャをリモートJVMで実行するという仕組み。クラスファイルとかリソースとかも必要に応じてリモートJVMにコピーするので、リモート側にあらかじめプログラムを配備しておく必要がないのがよい点です。 さて、常々Javaのクロージャ(もどき)の文法は冗長だと思っていたので、これにGroovyを組み合わせたらいいんじゃない?、という事で、実験して見たところ意外にうまくいきました。 def pid() { // PIDを取得する。要はどのJVMで動いているかをわかりやすくするだけ return new File("/proc/self").canonicalPath } i=0 (0..<4).each { i++; remote { println "1st from ${pid()} (${i})" remote { println "2n
楽天の研究開発部門である楽天技術研究所とまつもとゆきひろ氏は,Rubyによる大規模分散処理フレームワークを開発する。共同研究として開発し,楽天内で実際の業務に使用する。 楽天ではRuby on Railsを実際に顧客が利用するアプリケーションで採用しており,まつもとゆきひろ氏を2007年6月に楽天技術研究所のフェローに招聘していた(関連記事)。これまで共同研究の方向性について議論を行ってきた。ディスカッションの結果,「エンタープライズ」と「スケーラビリティ」を主要なテーマとする方向性が固まり,間もなくプロトタイプの開発に着手する。まつもと氏が方向性やアイデア,アドバイスを出し,楽天技術研究所が実装を行う。 楽天技術研究所とまつもと氏は2つのタイプの分散処理フレームワークを開発する方針。 一つは,小さくは2~3台から手軽に分散処理が行えるような「簡単さ」を追求したフレームワーク。用途としては
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く