まだ自分でインストールして確かめていないが、kumofsに興味津々である。何が興味深いかというと、まあスケーラブルで且つ耐障害性に優れるところだ。もちろんそれだけなら分散KVSということである程度予想された機能である。個人的な興味としては「この種のKVSを使ってRDBMSもどきが作れないか」というところにある。

この構想は

超 並列RDBMSは成立するか – L.star的デザイン（１）

でずいぶん前から暖めているものであるが、ここでいうリソースノードをkumofsで代用できないかというものだ。引用して、機能的な実装の必要でないものを除くと

リソースノード

• storage engineである


• DDL的には、テーブルスペースに近い位置づけとして定義可能であると考えている。


• sequential scan, index scan, seq scan+sortを行い、その結果を返すDBである。MVCCを持つが、基本XIDを自前で持たない。


• （たぶん64bitの)論理rowidを全てのtupleに持たせ、これが常に主キーとなる。clustered indexでいいかもしれない。


• rowidベースのパーティショニングを備える。


• ノード数を増やし、sortのコストを分散することでクエリの高速化を実現する

論理rowidによるindex scanを実行可能なのは明らかで、パーティショニングも自動でやってくれるので、他の部分が焦点になる。

一番やっかいなのはSequential Scanだろう。例えばtableid,rowidというキーを作ってループで流すことは可能である（最大テーブルサイズは管理用キーに置くべき？）が、あまりやりたくないようにも思える。どのみちmemcachedプロトコルでちんたら１件づつ取得をやっていると泣けるので、拡張するなりMessagePackかなにかで直接たたけるように抜け道用意したりして、複数件を同時に取得できるようにすべきだろう。しかし、元がhashなため効率が若干悪いだろう。それを補うだけの性能をノード増でたたき出せるか？

次はindex scanだが、これはあっさりとなにがしかのTree系アルゴリズムを実装できるだろう。何となればtableid,indexid,nodeidという３組のキーを突っ込んで、値はkey-child nodeペア等々の組にしておけばいい。どのアルゴリズムが有効なのかは悩む。

Sortは・・・index scanならともかく、当然自前実装しかない。各kumo-server内で取得したデータを可能な限りオンメモリソートできるなら分散になるだろうが、現実の性能面ではどうなんだろうか。

あと最大の問題はkumofsドキュメントによると

Set(key, value) keyとvalueのペアを保存します。１つのkey-valueペアは合計３台のサーバーにコピーされます。 Set操作が失敗すると（ネットワーク障害などの理由で）、そのkeyに対応するvalueは不定になります。そのkeyは再度Setするか、 Deleteするか、Getしないようにしてください。

value = Get(key) keyに対応するvalueを取得します。 Set中にGetした場合に古いvalueが取得されるか新しいvalueが取得されるかは不定ですが、新旧が混ざったvalueにはなることはありませ ん。

（強調筆者）などという、データの完全性必須な人から見ると寝言としか思えない仕様が書かれている。トランザクションのACIDのうち、A-原子性とD-持続性はこの時点で期待できない。Iは自前実装である。しかし当面はそもそも2pc対応していないためにどのみちトランザクション対応のRDBMSストレージエンジンにはできないのでそもそも問題にはならない（まて

となると、インターフェース的に足りない機能、あった方が便利な機能としては以下か。

• values=Get(key,...) に相当する機能。シーケンシャルスキャン実現に有利


• values=SortedGet(sortfunc,key,...)に相当するデータをソートしてから取り出す機能。ソートスキャン用に有利


• Setのatomic化。まじめなデータを管理するには必須。


• GetとSet競合時のGetの動作の安定化。MVCCを実現するためにはないと泣ける。


• 2PC。

まあ今日は軽くブレストぐらいの感じでblogを書いたけれども、もうちょっと詰めてみると案外おもしろいのかもしれない。

（今後続くかも）