Is Amazon's Dynamo not DHT ?
Miko Yoshida
> といいながらも、DHTは Amazon Dynamo やら（他にも楽天やら）イントラベー
> スでプチブレイクし始めてますよね。よい傾向です。
と Dynamo の話題を出したら、首藤さんのスライド
http://www.shudo.net/publications/ComSys2007-churn-resilience/slide02.png
にすでに例としてあがってました。
私はこれは絶対DHTだと思っていたんですが、違うんでしょうか？
---
吉田 幹 y...@bbr.jp
Kazuyuki Shudo
> > といいながらも、DHTは Amazon Dynamo やら（他にも楽天やら）イントラベー
> > スでプチブレイクし始めてますよね。よい傾向です。
>
> と Dynamo の話題を出したら、首藤さんのスライド
> http://www.shudo.net/publications/ComSys2007-churn-resilience/slide02.png
> にすでに例としてあがってました。
cloud なり、ネットの「あちら側」を支えるシステムソフトウェアが
プチブーム (私だけ?) のようなので、
ハッシュ表は応用範囲が広い → DHT の研究には価値がある、
とアピールするために、Dynamo を引き合いに出してみました。
出してみたんですが、実は
> 私はこれは絶対DHTだと思っていたんですが、違うんでしょうか？
Dynamo は DHT じゃないんですよね。
Dynamo は、クライアント (サービス利用側) との間で、例えば、
「500 リクエスト / 秒という状況でも読み書き要求の 99.9% に対して
300 ミリ秒以内に応答する」
といった SLA を結ぶそうです
(論文 Section 2.2 Service Level Agreements (SLA))。
このことにも表れてるように、
低遅延が重要なアプリを対象としているため、
要求が複数ホップに渡ってルーティング (正確には forwarding ?) されることは
避ける必要があった (論文 Section 3.3 Discussion)、とのことです。
論文中にはこんな文もあります:
"Dynamo can be characterized as a zero-hop DHT"
DHT でも、ホップ数の上限を保証することは可能だとは思うのですが、
クラスタ (→ churn なし) で、せいぜい 10^3 とか 10^4 というノード数では、
DHT を持ち出すまでもない、というのは自然な結論かと。
(Chord のベースとなってる) consistent hashing は、
Dynamo でも重要なアイディアです。
virtual nodes ありの consistent hashing です
(論文 4.2 Partitioning Algorithm)。
首藤一幸
KOBARA Makoto
小原です。
首藤さんが書いていらっしゃるように
この論文はDHTそのものの論文ではないと考えます。
(フルメッシュのルーティングテーブルを構成する方法としてDHTを使う、
というのは検討できるかもしれませんけどね)
が、いろいろと面白い(背中を押される)ことが書いてありますね。
私にとっては、この論文のキモの1つは、
"eventually-consistent storage"
かなと思っています。
(先のChurn耐性の話題にも通じる話)
1.Intrduction より抜粋
It demonstrates that an eventually-consistent storage system can be
used in production with demanding applications. It also provides insight
into the tuning of these techniques to meet the requirements of
production systems with very strict performance demands.
------------------------------
KOBARA Makoto
kobara...@gmail.com
Miko Yoshida
ありがとうございます。
吉田です。
おかげで理解が深まりました。
どうやら、amazon S3 から DHTと信じてしまっていた私の盲信のようですね。
分散化したハッシュ表（英語で書くと、distributed hash table か。DBと言
った方がよい？ もちろん、技術用語であるDHTではありません）の機能を構造
化オーバレイと異なるアプローチで実現している感じですね。
＃でも、こちらの方がアプローチとしては、普通か。
小原さんのおっしゃるよう、分散DBの概念として、
eventually-consistent はアリかもしれません。
DHTにも応用できそう。
In message, KOBARA Makoto <kobara...@gmail.com>-san wrote on
Tue, 04 Dec 2007 09:04:52 +0900...
---
吉田 幹 y...@bbr.jp
丸山不二夫
>> クラスタ (→ churn なし) で、せいぜい 10^3 とか 10^4 というノード数では、
>> DHT を持ち出すまでもない、というのは自然な結論かと。
そうなんですよね。
個人的には、今、データベースの分散が、マイ・プチブレイクなんですが、
そこで必要とされているscale-outの規模の見積もりがデザインを決めるんでしょうね。
エンタープライズ・システムのパフォーマンスのネックはデータベースです。
現在のデータベースは、10年後くらいには、メモリー上のKey-Value Mapを中心と
したシステムに姿を変えると思っています。もちろん、ノードの分散は必須です。
その意味では、データベースは、分散ハッシュに置き換わるだろうと思っているのです
が、それが、現在のDHTと同じかどうかは、面白いところだと思っています。
Kazuyuki Shudo さんは書きました:
Kazuyuki Shudo
> Message-ID: <4755E8FA...@wakhok.ac.jp>
> From: 丸山不二夫 <maru...@wakhok.ac.jp>
> Date: Wed, 05 Dec 2007 08:55:38 +0900
> 丸山です。
> 個人的には、今、データベースの分散が、マイ・プチブレイクなんですが、
> そこで必要とされているscale-outの規模の見積もりがデザインを決めるんでしょうね。
論文中の「scale out」を検索すると、まず、こういう文が見つかります:
Dynamo has a simple key/value interface, is highly available with a
clearly defined consistency window, is efficient in its resource
usage, and has a simple 『scale out』 scheme to address growth in data
set size or request rates.
論文なので、
主張の正当化のために、単純かつ魅力的な表現を選んではいるのだと思うのですが、
傾聴に値します (← 偉そうな)。
余談ですが、もう 1ヶ所「scale out」が遣われている個所があって、
なるほどこういう遣い方をするのか、と勉強になりました:
Other key principles embraced in the design are:
(デザイン上の要件:)
Incremental scalability: Dynamo should be able to 『scale out』 one
storage host (henceforth, referred to as "node") at a time, with
minimal impact on both operators of the system and the system itself.
(マシンを 1台ずつ追加できること)
> エンタープライズ・システムのパフォーマンスのネックはデータベースです。
> 現在のデータベースは、10年後くらいには、メモリー上のKey-Value Mapを中心と
> したシステムに姿を変えると思っています。
そこまでおっしゃいますか。なるほど。。
僕自身は DBMS をハードに使うアプリの経験が少ないので、
その点に関してはあまり知見も意見もないです。
RDBMS で巨大システムを組んできた方の御意見をうかがってみたいものです。
mixi や GREE の裏側、といった発表資料に、
RDBMS の分散をこれこれこう工夫して... といったお話があったのを思い出します。
星さんの書かれたこの記事が、最近、ほうぼうで話題になってました:
楽天テクノロジーカンファレンス2007から
大規模分散処理向けの国産“ウェブOS”をRubyで開発中 (2007/11/26)
http://www.atmarkit.co.jp/news/200711/26/rakuten.html
Matz にっき
[Ruby] 大規模分散処理向けの国産“ウェブOS”をRubyで開発中 － ＠IT
http://www.rubyist.net/~matz/20071126.html#p01
楽天の方が考える Roma というソフトが key-value interface かどうかは
不明ですが、少なくとも、1,000 台規模の、メモリ上にデータを持つ DB を
考えていることまでは確かなようです。
> もちろん、ノードの分散は必須です。
> その意味では、データベースは、分散ハッシュに置き換わるだろうと思っているのです
> が、それが、現在のDHTと同じかどうかは、面白いところだと思っています。
どうなるんでしょーねー。
> >> クラスタ (→ churn なし) で、せいぜい 10^3 とか 10^4 というノード数では、
> >> DHT を持ち出すまでもない、というのは自然な結論かと。
>
> そうなんですよね。
DHT にも 1-hop DHT という技術があったり...
なんてことも、構造化オーバレイ (含 DHT) ファンとしては考えるのですが、
クラスタ上で DHT が最適解であるような状況はあまりないのかな、とも考えます。
クラスタ上でも、充分、かなり使える技術だとは思ってますが。。
首藤一幸
KOBARA Makoto
こんにちは。
> おかげで理解が深まりました。
> どうやら、amazon S3 から DHTと信じてしまっていた私の盲信のようですね。
(って、ハズレだったというわけではないのですが)
> 小原さんのおっしゃるよう、分散DBの概念として、
> eventually-consistent はアリかもしれません。
> DHTにも応用できそう。
私は、この論文のキモ(Amazonさんのアプローチの優れたところ)は、
一貫性の維持などのことは上位レイヤと協力して対処する、という
設計をとっていることだと考えています。
自分たちのアプリ(ミドル)の知識をもって、プラットフォームまで潜って
自製するという点は、Amazonさんに限らず、楽天さん(Romeでしたっけ)や
Googleさんにも、共通するお話ですね。
(このあたりの私の考えは、昨年12月ころにこの場にちょっと出してますね)
そのため、
(どこまでが「Dynamo」なのかという話はありますが)
「Dynamoは分散DBです」、と言ってしまうと、
世の中に出ているエンタープライズ分野で運用されているプロダクト群に
埋もれてしまうので、ちょっとばかり抵抗があります。
(なので、Amazon さんも Key-value Store と言っているのかと。
ちなみに、GoogleさんのGFSも、FSなのか、というような
やりとりが、USENIX/FAST'07の会場で、ちょっとありました。)
------------------------
KOBARA Makoto
KOBARA Makoto
小原です(丸山先生はじめまして)。
こんばんは。
> 余談ですが、もう 1ヶ所「scale out」が遣われている個所があって、
> なるほどこういう遣い方をするのか、と勉強になりました:
よく使われている表現です(ので、この分野の人(私も)にはしっくりくる表現でした)。
> > エンタープライズ・システムのパフォーマンスのネックはデータベースです。
> > 現在のデータベースは、10年後くらいには、メモリー上のKey-Value Mapを中心と
> > したシステムに姿を変えると思っています。
>
> そこまでおっしゃいますか。なるほど。。
>
> 僕自身は DBMS をハードに使うアプリの経験が少ないので、
> その点に関してはあまり知見も意見もないです。
> RDBMS で巨大システムを組んできた方の御意見をうかがってみたいものです。
- DBベンダやSIerが導入事例としてホワイトペーパーを出していたりはするので、
(肝心なところはぼかしていますけどね)
そこから調査してみると参考になるかもしれません。
- エンタプライズ系システムでの OnMemoryDBの動向に関しては、たとえば、
TimesTenとOracle(の関係)あたりを調べてみると、いかがでしょうか。
(技術だけではなく売り方なども)
------------------------------
KOBARA Makoto
Miko Yoshida
どうも、吉田です。
In message, KOBARA Makoto <kobara...@gmail.com>-san wrote on
Wed, 5 Dec 2007 09:06:22 -0800 (PST)...
> > 小原さんのおっしゃるよう、分散DBの概念として、
> > eventually-consistent はアリかもしれません。
> > DHTにも応用できそう。
>
> 以下私の個人的な考え(与太話)です。
>
> 私は、この論文のキモ(Amazonさんのアプローチの優れたところ)は、
> 一貫性の維持などのことは上位レイヤと協力して対処する、という
> 設計をとっていることだと考えています。
> 自分たちのアプリ(ミドル)の知識をもって、プラットフォームまで潜って
> 自製するという点は、Amazonさんに限らず、楽天さん(Romeでしたっけ)や
> Googleさんにも、共通するお話ですね。
> (このあたりの私の考えは、昨年12月ころにこの場にちょっと出してますね)
かすかに記憶しております。:-)
そのときはあまり深く考えていませんでした。
> そのため、
> (どこまでが「Dynamo」なのかという話はありますが)
> 「Dynamoは分散DBです」、と言ってしまうと、
> 世の中に出ているエンタープライズ分野で運用されているプロダクト群に
> 埋もれてしまうので、ちょっとばかり抵抗があります。
> (なので、Amazon さんも Key-value Store と言っているのかと。
> ちなみに、GoogleさんのGFSも、FSなのか、というような
> やりとりが、USENIX/FAST'07の会場で、ちょっとありました。)
私が分散DBと表現したのは、dynamoをレガシーな分散DBのカテゴリに括ってし
まおうという意図ではなくって、逆に、分散DB に eventually-consistent と
いう概念を持ち込むとどうなるかと思ったからです。
レガシーなDB（「分散」はつけません）の立場からは、とんでもないと言われ
そうですが、走っている分散DBの技術者・研究者には受け入れられそうな気が
します。ちょっと面白いですよね。
それに、エンタープライズ分野で運用されているプロダクト群は、分散DBの研
究領域の一部の成果だと思っています。例えば、DHTも分散DBだという人もい
ます。なので、まあいいかなと。
（ところで、GFSはFS？ は自分も直感的に感じました）
---
吉田 幹 y...@bbr.jp
Miko Yoshida
In message, KOBARA Makoto <kobara...@gmail.com>-san wrote on
Wed, 5 Dec 2007 09:31:04 -0800 (PST)...
DBじゃなく、Key-value Store(Map) という表現を取っている理由もそうかと
思うのですが、この辺の話、トランザクションの概念の有無が関係するように
思うのですが、いかがでしょう。
---
吉田 幹 y...@bbr.jp
Kazuyuki Shudo
> Message-ID: <8f008eeb-e518-4d49...@e23g2000prf.googlegroups.com>
> From: KOBARA Makoto <kobara...@gmail.com>
> Date: Wed, 5 Dec 2007 09:31:04 -0800 (PST)
> > > エンタープライズ・システムのパフォーマンスのネックはデータベースです。
> > > 現在のデータベースは、10年後くらいには、メモリー上のKey-Value Mapを中心と
> > > したシステムに姿を変えると思っています。
> > RDBMS で巨大システムを組んできた方の御意見をうかがってみたいものです。
>
> 一般論として、ですが、(お仕事絡むので具体的なことは言えません)
ありがとうございます。
手がかりを頂けるだけでもありがたいです。
メモリ DB の動向、調べてみます。
あとは key-value store でいいの? どのくらい使えるの? というあたりに、
(DHT ファンとしては) 興味があります。
RDBMS を scale out させることに大変苦労されている方々が、
では、もし、Dynamo のような key-value store を手に入れたとしたら、
どういう使い方があって、どのくらい嬉しいのかな? と。
応用によって様々で一概には言えないのでしょうけども。
key-value store である Berkeley DB がどう使われているかを観察する、とか、
想像の仕方はいろいろありそうです。
が、想像だけふくらませても、机上の空論になりそうな気もします。
首藤一幸
丸山不二夫
>> そこまでおっしゃいますか。なるほど。。
「10年後」は、いいすぎかしら。
「10ないし20年後」ぐらいにしときましょうか。
リレーショナル・データベースの理論的な歴史は、70年代から始まって
いますので40年近い歴史はあるのですが、CoddがTuring賞をもらったのが、
1981年で、四半世紀前。Oracle社は、確か、今年が創立30周年ですね。
実際にリレーショナル・データベースが、大々的に使われ始めたのは、
ここ20年の間だと思います。意外と短いです。
あ、そうだ。首藤さん、誕生日でしたね。おめでとうございます。
リレーショナル・データベースの年齢って、大体、首藤さんと同じくらいです。
>> 星さんの書かれたこの記事が、最近、ほうぼうで話題になってました:
情報、ありがとうございます。読んでませんでした。
ただ、10月に楽天の研究所の人と話をして、僕の最近の関心と彼らの関心が
近いので、ちょっと驚いたことがありました。先週、まつもとさんとも
会う機会があったのですが、そこでも、そうした話をしていました。
あまり空想に走ってもいけないのですが、現実のエンタープライズのシステムの
中でも、面白い動きがあります。
OracleのCoherence、IBMのObjectGridは、よく似たクラスタ・ネットワーク上の
分散Cacheのシステムです。基本は、Key/Valueマップをネット上に拡大したものです。
これらのクラスタのCache技術は、実装としては、ネットワーク上のHash-Map
で、クラスタのボトルネックであるDBの遅さを解消しようとしてメモリ上に
キャッシュ・データを置こうというものです。
AmazonのDynamoは、ネットワーク上のHash-MapをCacheではなく、データベース
そのものにしてしまえというものですので、孤立した技術ではありません。
Teracotta社のTeracottaも、バイト・コードにフックをかけて、あるオブジェクト
へのアクセスを、ネットワーク上のpersistentな共有オブジェクトへのアクセスに
置き換えます。これも、近い技術です。
>> DHT にも 1-hop DHT という技術があったり...
>> なんてことも、構造化オーバレイ (含 DHT) ファンとしては考えるのですが、
もっとしたたかなのは、GoogleのBigtableだと思います。彼らの実装をよく見ると、
テーブルを小さなtabletに分割して各ノードに分散するんですが、tabletへの
書き込みは、メモリー上のテーブルへの書き込みなんです。メモリー・キャッシュが
効いています。ただ、Bigtableでは、ネットワーク上に分散したtabletへのアクセスは、
DHTでもハッシュでもなく、i-node風な多段のアドレス・アクセスですね。
いずれにしても、データがpersistentじゃないと、データベースの意味がないので、
メモリー上のデータは、いつか、ファイルに落ちないといけないですね。その
あたりでは、BigtableはSSTableというのを使うんですが、分散データベースとしては、
いいバランス感覚なのかもしれません。
SunのGlassfishというAppサーバのクラスタリングは、JXTAのGroup機能を使っています。
これなんかも、意外というか、面白い話ですね。ただ、これも、クラスタのスケールが、
せいぜい 10^2 とか 10^3 の程度だからだと思っています。
ただ、こうしたJXTAの使い方よりも、分散DBを分散ハッシュで実現しようというのは、
王道ですね。DHTにとっては、新しい応用の展望が開けて、また理論も進むんだと
思っています。
Kazuyuki Shudo さんは書きました:
KOBARA Makoto
小原です。
> 私が分散DBと表現したのは、dynamoをレガシーな分散DBのカテゴリに括ってし
> まおうという意図ではなくって、逆に、分散DB に eventually-consistent と
> いう概念を持ち込むとどうなるかと思ったからです。
> それに、エンタープライズ分野で運用されているプロダクト群は、分散DBの研
> 究領域の一部の成果だと思っています。例えば、DHTも分散DBだという人もい
> ます。なので、まあいいかなと。
例えば、の後半からは、人それぞれのバックグラウンドによってどう捕らえるか
色々と意見がありそうで(それを否定するつもりはないです)、
でもそういうことから新しい発想がでてくるので、面白いところですね :-)
---------
KOBARA Makoto
KOBARA Makoto
> DBじゃなく、Key-value Store(Map) という表現を取っている理由もそうかと
> 思うのですが、この辺の話、トランザクションの概念の有無が関係するように
> 思うのですが、いかがでしょう。
(Key-Value Storeはトランザクションの概念がないものだ、と私が主張している
わけではないです :-) )
-----
KOBARA Makoto
KOBARA Makoto
> > 一般論として、ですが、(お仕事絡むので具体的なことは言えません)
>
> ありがとうございます。
> 手がかりを頂けるだけでもありがたいです。
> メモリ DB の動向、調べてみます。
このあたり調べるときに、提灯記事に振り回されると、落とし穴にはまっちゃうので、
ちょっと突き放して調べるのがよいかと思います :-)
> あとは key-value store でいいの? どのくらい使えるの? というあたりに、
> (DHT ファンとしては) 興味があります。
私にとっては、key-value store の概念はそれらと重なるところがあります。
なので、エンタープライズ分野でどうなのよ、と考えるときに、
それらをキーワードに、技術や、動向(それが今どうなっているのか、どうやって
売っているのか)を調査されるのもよいかと思いました。
(多分、国内にはあまり情報ないと思いますし、ベンダも公開してないかも。)
--------------
KOBARA Makoto
Miko Yoshida
吉田です。
過去に実務経験を持っていたということだけでコメントをしてみます。
専門の方がいらしたら、別のコメントがあるかもしれません。
In message, Kazuyuki Shudo <20...@shudo.net>-san wrote on
Thu, 06 Dec 2007 03:03:13 +0900 (JST)...
> あとは key-value store でいいの? どのくらい使えるの? というあたりに、
> (DHT ファンとしては) 興味があります。
>
> RDBMS を scale out させることに大変苦労されている方々が、
> では、もし、Dynamo のような key-value store を手に入れたとしたら、
> どういう使い方があって、どのくらい嬉しいのかな? と。
> 応用によって様々で一概には言えないのでしょうけども。
何をアプリケーションと考えるかで、嬉しさがかなり違うと思います。
ただ、RDBMSが相手にしてきた領域はつらいと思います。
通常の業務でRDBMSを使う場合、ERDを使ってテーブルデザインを行います。
この表設計と、key-value storeの間にかなりのセマンティックギャップがあ
るのでこれを何らかの形で埋める必要があります。
さらに面倒なのは、トランザクションです。
DBMSの世界では、DBサイドでトランザクション管理をしてくれるのが当たり前
なので、アプリ側では、平気でロールバックを発生させます。
これをやられると、key-value store はかなりつらいのじゃないかと思います。
（トランザクションの概念が無い、は言い過ぎたかもしれませんが、RDBMSと
比べると、トランザクション管理は弱いです）
性能設計も同様です。いつも問題になるのは、
・テーブル間の依存性（ERDを使って抽出）
・トランザクションの及ぶ範囲
の2つです。
前者が論理設計（最適化含む）、後者が物理設計ということになるのですが、
scale outを考えると、分散トランザクションの及ぶ範囲をできるだけ小さく
する（もっと言えば分散トランザクションは発生しないようにする）ことが肝
要となります。
そのため、論理設計で、テーブル間の依存性を分析し、テーブルの物理配置の
工夫（partitioning のような）をしたりします。
私自身は、アプリががんばらなくても、高度の分散化ができるDHTのような仕
組みがいいと思っています。
でも、業務の世界では、トランザクション管理がしっかりしたRDBが大前提で
すし、分散化する際も、複数サーバをフェールセーフなネットワークを前提に
クラスタ化して、やむえないときだけ2フェーズコミットを行うという念の入
れようです。
そういう意味では、トランザクション管理をわざと弱くしたオブジェクト指向
DBの方が相性がよいのではないかと思います。
オブジェクト指向DB上でアプリを作る人は、DBとはいえ、単なる persistent
objectだと思っている場合が多く（私もそうでした）、トランザクション管理
についても、自分で解決して、DB側に頼らないことが多いです。（かなり主観
が混じってますが）
これは、分散オブジェクトの方にも関係する話ですが。
これ以上広げるとつらいので、この辺で。
---
吉田 幹 y...@bbr.jp
丸山不二夫
丸山です。
実務的なのDB運用の実際から見ると、吉田さんのおっしゃるとおりですね。
>> 通常の業務でRDBMSを使う場合、ERDを使ってテーブルデザインを行います。
>> この表設計と、key-value storeの間にかなりのセマンティックギャップがあ
>> るのでこれを何らかの形で埋める必要があります。
key-value Hashに限らず、オブジェクト志向的なアプローチとEntity-Relationalな
アプローチとの間には、ギャップがあります。ここ数年の、エンタープライズ
システムのひとつの流れは、OR-Mapping（Object-Relational Mapping）で、両者の
違いを隠蔽しようというものです。
JavaEEのEJB3,それをJavaEEから切り出したJPA（Java Persistent API）が、代表例
です。（昔からのHibenate,TopLinkも健在です。）
あと日本では、データ総研の椿さんを中心とするDOA（Data Oriented Approach
データ中心主義）という開発手法が、大規模システムでは、強い影響力を持っています。
ま、OR-Mappingも、ER分析も、RelationalなDBの存在を前提にしたものではないのかと、
僕は、最近、感じ始めています。DOAの人たちは、それは、実在するデータの自然な
構造だと考えるわけで、その限りでは説得力もあるのですが、データベースの構造自体
が変わったら、ものの見え方が変わることがあるかも知れません。
トランザクション処理については、データを扱う以上、それがメモリー上にあろうが、
DB上にあろうが、本質的に必要な処理だと思います。この点では、分散HashDBには、
Transaction Memory的なアプローチが、有効かもしれません。
僕自身、まだ、Relationalな考え方の影響の下にあるのですが、気になるのは、
Key Value Pairから、Row Objectを引き出すとすると、テーブル間のJoinにあたる
操作を、どう分散環境で実現するのかという問題があるように思いました。
これにも、面白いアプローチがあります。Yahooの連中が開発した、分散処理言語
Pig Latin（ふざけた名前です）は、視点を変えて見ますと、一般化したJoin操作を
MapReduceのアルゴリズムで実行する処理系に見えます。ここにも、データベースの
分散処理の、ひとつのヒントがあると感じています。
もっとも、Hashの値に、複数のColumn ObjectからなるRow Objectを格納する必要が
あるのかも、再検討してもいいのかもしれません。単一Key（これは当然ですね）
単一Valueを持つ複数のHashの集合としてDBを構成すれば、Joinは、同一Keyで
複数のHashにアクセスする、自明な処理に還元できます。
BigtableのLocality-Groupや、そうした抽出を可能にしている、Column中心の
データ格納のスタイルも、データベースなら、Rowを持つだろうという先入観からは、
自由になり始めていることの表れなのかも知れません。
Miko Yoshida さんは書きました:
Kazuyuki Shudo
> Message-Id: <20071206.012249...@utagoe.com>
> From: Kazuyuki Shudo <20...@shudo.net>
> Date: Thu, 06 Dec 2007 01:22:49 +0900 (JST)
> 星さんの書かれたこの記事が、最近、ほうぼうで話題になってました:
>
> 楽天テクノロジーカンファレンス2007から
> 大規模分散処理向けの国産“ウェブOS”をRubyで開発中 (2007/11/26)
> http://www.atmarkit.co.jp/news/200711/26/rakuten.html
>
> Matz にっき
> [Ruby] 大規模分散処理向けの国産“ウェブOS”をRubyで開発中 － ＠IT
> http://www.rubyist.net/~matz/20071126.html#p01
>
> 楽天の方が考える Roma というソフトが key-value interface かどうかは
> 不明ですが、少なくとも、1,000 台規模の、メモリ上にデータを持つ DB を
> 考えていることまでは確かなようです。
ROMA は DHT (分散ハッシュ表) なんだそうです。
6月の松本さんの講演の中で、楽天技術研究所の方がそんなことをお話してました。
まつもとさんの基調講演 その3（RubyKaigi2008） - ニコニコ動画（夏）
http://www.nicovideo.jp/watch/sm3726943
楽天技術研究所の方:
「ROMA はこういう環状になっているというイメージ」
…とすると、DHT のアルゴリズムは Chord か Pastry なのではないかと思います。
こういう状況のようです。
松本さん:
「ROMA の方はプロトタイプが動いていて、
6台のマシンに 10ノードぐらい分散して、
リクエストを投げて、データがあって、
ノード 1個無理矢理強制終了させてもデータが残ってるとか、
そういうようなことをやってみています。」
首藤一幸