MySQL＋FUSEでファイルシステムを実現するMySQLfs

MySQLデータベースをファイルシステムとして利用するためのFUSEドライバ「MySQLfs」が、Open Tech Pressで紹介されています。データベース＋ファイルシステムと聞いて、BFSや幻に終わったWinFSのような、属性を使ってファイルの検索/整理ができるものを想像しましたが、今のところ階層型ファイルシステムをデータベース上に再現するものとなっているようです。また性能面は、Bonnie++によるベンチマークでは、ext3の10分の1程度とのこと。現時点では導入効果が薄い感じのMySQLfsですが、検索などに力を入れてもらえると面白くなりそうです。

Database とファイルシステムの統合で期待するべきこと

[NaruTo (1519)]

「ファイルシステムを (Relational) Database にのっけると情報の検索が早くなる」と
期待する人が多いような気がするけど、それは間違っている気がする。
属性の整備とかが適正に行われ、RDB に乗っけたほうがいい形になっている情報なら
検索が速くなるだろうが、
そうなっておらず、RDB に乗っける意味がない情報ならやっぱり速くならず、
形式にとらわれない形でのインデックス付けを行うシステムの方が有用だという状態は
簡単にはひっくり返らないと思う。

じゃあ、なぜ Database とファイルシステムをくっつけようとするのか。
それはもっと低レベルな領域の話で、

「Database のログのシステム」と「ジャーナルファイルシステム」は似ているから統合しちゃえ!
データベースのログとジャーナルの二重構造になっているのは無駄だ！

という「データベース側の都合の話」だと思う。

ただ、WinFS は「どうせくっつけるなら。。。」と暴走した感がありますけどね。

--
マクロの基本は検索置換(by y.mikome)

Re:Database とファイルシステムの統合で期待するべきこと

[L.star (163)]

属性の整備とかが適正に行われ、RDB に乗っけたほうがいい形になっている情報なら
検索が速くなるだろうが、
そうなっておらず、RDB に乗っける意味がない情報ならやっぱり速くならず、
形式にとらわれない形でのインデックス付けを行うシステムの方が有用だという状態は
簡単にはひっくり返らないと思う。

形式にとらわれない形、といっても個々のフォーマットに応じた解析はするわけですから、これは疑問ですね。おそらく、RDBに乗っけることの出来ないような情報は、現在のインデックス付けでは効率化できないでしょう。

そうではなくて、検索以外のオペレーションが高速化できないのが問題なのです。現在のファイルシステムは、ファイルシステムが要求するオペレーション(ブロックレベルのread/writeとか、ファイルレベルでのアクセスとか)に特化した設計になっています。これは、既存のRDBMSには処理しづらいものです。また、ファイルサイズに非常に幅があって、大抵は100KB以上の大きなものです。これもまた通例数百バイト程度の小規模レコードがたくさんあることに特化した設計を採用するRDBにはつらいものです。

なぜ Database とファイルシステムをくっつけようとするのか。

MySQLfsに関して言えば、そこに付けられるものがあるから、じゃ無いですかね。同様のものにpsqlfsがありますが、これもはっきり言って「できるから統合してみた」以上の何かではありません。それ以上に興味深いものは無いため、そこで止まってしまいます。

「Database のログのシステム」と「ジャーナルファイルシステム」は似ているから統合しちゃえ!

その種の話は、むしろ専用サーバやraw I/Oのような、DBサーバ用ファイルシステム不要論に向かいます。はっきり言うと、ext3程度のジャーナルファイルシステムの提供する信頼性は、DBにとっては全然足りませんので、結局全部実装するしかありません。一方、ファイルシステムにとってはRDBMSが要求するような信頼性やトランザクションを必要としないですし、それによって性能が犠牲になりますから、両者を統合しようという方向にはなりません。

WinFSは「検索したい/アドレス長などのデータして統合して使いたい」->「じゃあRDBMS使おう」という設計的な流れを普通に踏んだのだと思います。で、read-write性能が出ない->NTFSベースにするしかない->現場混乱して収拾つかない->中止、という形を踏んだのでしょうね。しかしRDBを使うかどうかはともかくとして、最初の理念は間違ってないと思うのです。今のところ「検索」は実現できましたが「統合」は出来てません。そこは今後どのように実現されるか楽しみな部分ではありますね。

Re:Database とファイルシステムの統合で期待するべきこと

[NaruTo (1519)]

WinFSは「検索したい/アドレス長などのデータして統合して使いたい」->「じゃあRDBMS使おう」という設計的な流れを普通に踏んだのだと思います。で、read-write性能が出ない->NTFSベースにするしかない->現場混乱して収拾つかない->中止、という形を踏んだのでしょうね。

一つの目的にたる発想の元は唯一だと限らないので、どの回答の唯一絶対の回答ではないですが、
WinFS は

「SQL Server を NTFS に統合する」

というアプローチが取られたはずです。

実際、WinFS が高速になる理由の説明として
「”対応するハードウェア”と組み合わせることで、ログの書き込みを10分に１回程度に減らすことができる」
となっていました。

PostgreSQL で「ログが物理的に書き込まれるまで待つか否か」ってオプションがあったことでも
「ログの書き込み」が Database での影響の大きい速度のボトルネックの一つだということがわかります。

で、WinFS は変な期待されたり、実装が遅れたりしていただろうところへ
横槍(デフラグソフトのメーカあたりが文句を言った)が入ったりで
Native なファイルシステムであることをあきらめたが、
上記の「ログの書き込みを減らす」という方向は NTFS の機能としてそのまま実装がすすめられ、
Flush と HDD を組み合わせた Hybrid型HDD とかを提案したりした経緯を経て
現時点では Windows ReadyBoost みたいな機能になっています。

形式にとらわれない形、といっても個々のフォーマットに応じた解析はするわけですから、これは疑問ですね。おそらく、RDBに乗っけることの出来ないような情報は、現在のインデックス付けでは効率化できないでしょう。

僕は「googleデスクトップ」とか「属性や構文レベルをぶっとばして全文検索で字句レベルでマッチさせるようなエンジンの方が現時点では一定の成果を上げている（= ある種の効率化を達成している）」と考えています。

ファイルシステムにとってはRDBMSが要求するような信頼性やトランザクションを必要としないですし、

う～ん、この点は必ずしも正しくないとおもいます。OS の文化の違いかもしれないですが。
単純にデータとしてみるなら、RDB に載っているデータだけが大事ということはないと思います。

そして、Windows では Volume Shadow Copy や Distributed File System、Cluster などの機能が
NTFS の信頼性やトランザクション性能に強く拠っているとみとれます。

--
マクロの基本は検索置換(by y.mikome)

Re:Database とファイルシステムの統合で期待するべきこと

[L.star (163)]

実際、WinFS が高速になる理由の説明として 「”対応するハードウェア”と組み合わせることで、ログの書き込みを10分に１回程度に減らすことができる」

別にこれは「ログを統合したから」という話では全然無くて、最初から

Flush と HDD を組み合わせた Hybrid型HDD とかを提案したりした経緯を経て

を意図した発言じゃないですか？

PostgreSQL で「ログが物理的に書き込まれるまで待つか否か」ってオプションがあったことでも 「ログの書き込み」が Database での影響の大きい速度のボトルネックの一つだということがわかります。

ログは同期書き込みである必要があるため、DBのボトルネックの一つなのはその通りです。でも、PostgreSQLには歴史的な経緯としてそんなオプションありませんでしたよ？

"fsync=off"はあらゆる同期書き込みを非同期に置き換える、であって、ログを意味していません。そもそも、ログのない時代の、あらゆる書き込みが同期だった頃の名残です。非常に紛らわしいオプションなのですが。

8.3で追加されたやつのことを言っているのなら、信頼性と性能のトレードオフがユーザーに選べるようになったという点で好ましいと思います。過去形で語られるような内容では無いと思いますが。

僕は「googleデスクトップ」とか「属性や構文レベルをぶっとばして全文検索で字句レベルでマッチさせるようなエンジンの方が現時点では一定の成果を上げている（= ある種の効率化を達成している）」と考えています。

本当に単なる機械的全文検索だったら、"Recieved"とか"Subject"で検索するとあらゆるメールヘッダが引っかかってどうしようもないと思いませんか？そんなソフトだったら到底使いものになると思いません。

あれはプラグインを使って個別に属性レベルの解析をしているわけであって、必ずしも構文とかそういうのを無視しているわけではないと思いますが。ただ、それをファイルシステムに集約するか、裏でアプリケーションとしてやるかの違いではないでしょうか。ただの機械的全文検索だったら、googleデスクトップのようなツールは見向きもされなかったと思います。

単純にデータとしてみるなら、RDB に載っているデータだけが大事ということはないと思います。

いえ、大事か大事でないか、ではなく、どの程度の信頼性を求めるかです。

トランザクショナルなRDBMSは、それが前述されたとおり「ログの書き込みがボトルネック」であることを知った上でも、要件として単なるクラッシュからのトランザクション保護を強固に行います。一方で、たいていのジャーナリングファイルシステムは高々fsckしなくて済む程度にしかしません。性能面を考えれば当然の妥協だと思います。

Re:

[Anonymous Coward]

全文検索エンジンと
RDB(きめうち検索エンジン？)とは
住む世界が違いますよね。

RDBにゃ「スキーマのメンテナンスをガチでキメないと、性能どころか論理(データ辻褄)的にも瓦解する」というナイーブな面があります。
正規化とかですね。
しかも変更があった場合も常に正規化とかをきっちりやり「つづけ」ないとならない。

それを受け入れてでも性能やカッチリさが欲しい！という場面では、RDBを使ったほうが得。
受け入れにくい状況なら全文検索のほうがきっと強い。

「あれーあのデータどこに有ったっけ？」
なんてほざくかたがた(ｗ)に対しては、
それが所謂業務であろうがなんだろうが、

memcachefs

[Anonymous Coward]

というものも在る様です。（mysqlfsと同じ開発者？）
http://memcachefs.sourceforge.net/ [sourceforge.net]
fuseを使うとなんでもファイルシステムに出来てしまうんですね。
(実用的かどうかはわかりませんが・・・)

温故知新

[Anonymous Coward]

「データベースをファイルシステムとして利用する」
なんだ、Netware の再発明か。

Re:温故知新

[shion_91 (34448)]

IPXの復活か！
…絶対無いわ。

Re:

[Anonymous Coward]

もしかして、意味が通じていないのかなぁ？

Re:

[Anonymous Coward]

> もしかして

というより、時代がNetWareとかぶる点は通じてると思うんですけどね。
ちょうどその時期でしたが、社長の決断IBM AS/400ってので採用されてた
ファイルシステムが単一レベル記憶 [wikipedia.org]と呼ばれてまさに
データベースがファイルシステムそのものでしたね。　SLS シングルレベルストレージ

Re:

[Anonymous Coward]

AS/400のSLSは「メモリとストレージの区別が無い」って話で、今回のストーリーでいってるような、世間一般で言うところのデータベース(≒RDB)とは違うと思うんだが。アレがデータベースなら、FATだってデータベースだぞ。

Re:

[Anonymous Coward]

> FATだってデータベース

近いと思うんですが。　サービスやプロセスではなく、カーネルと同じレベルでデータベースが動作してると。

FUSU 安定してる?

[Anonymous Coward]

俺sshfs 位しか使わないんだけど不安定なイメージが

Re:

[Anonymous Coward]

sshfsとntfs-3gで多少キツく触ったけど、滅茶苦茶に不安定とは思えないっす。

性能差

[Anonymous Coward]

検索は速くなるとしても、書き込み、読み込みの基本性能は一般的なファイルシステムより早くなることはないんじゃないかと(根拠なく直感的に)思ってるんですが、どうなんですかね。

# 検索以外のメリットが想像できないのでAC

Re:性能差

[oldwave (20436)]

冗長化とか、トランザクショナルなファイル操作とかの可能性があるかも、とか思いました。（可能性、ね。）

Re:性能差

[Another_View (29838)]

一つのディレクトリにファイルが大量にある場合なんかは有効かも。
原理的にinodeがないのも良いね。
ファイルの中身をどのようなデータ型で保存しているのかねえ。
とりあえずならBLOBなんだろうが、その場合速度は期待できないかも。。。

と思って、記事のリンク先を見たところ、なんとinodeがある。ただしDBの主キーとしての扱い。BIGINT(20)なので枯渇はしないと思う。ファイルの中身はBLOB。

いまのところ技術展示でしかない感じ。

Re:性能差

[Anonymous Coward]

ランダム読み出しは、
1行あたり固定長データ＊行番号(?)
でアクセスすることで、
速くなる可能性も無いでもないでしょうね。

でもシーケンシャル読み出しは絶望的に遅いんじゃないかな？
だってハイコストな「order by」を処理しないとならないんだもん。
「もとから順番どおり並んでる」ことが全く期待できないのがRDB。
こういう使い方は辛いと思う。

あとファイル内容検索も期待できないだろうな。
もし固定長データを各行に持たす実装なら、
検索語が固定長の境界をまたぐかどうかで
検索のしかたを色々変えないとならないのだから、
そのぶん無駄だらけになる。

＃16bit時代、BLOBに絵のファイル突っ込んだら怒られたのでAC

あと気になるのが「SQLを」使ってるかどうか。
RDBだけならまだしも、それに加えて、
アクセスのたびにSQLを生成し、
バイナリデータのエンコードデコードだの、
SQLの解釈だのを
毎度毎度やってたんでは、
明らかに日が暮れる。
SQLを華麗にスルーしてNativeAPI(あるの？)で叩いてるのかな？

＃普通の業務アプリもSQL経由したくないのでAC。だって言語として使いづらいじゃんSQL。

Re:性能差

[L.star (163)]

もともとファイルがBLOBに格納される実装なので違う、と言い切ってしまえばそれまでなのですが

だってハイコストな「order by」を処理しないとならないんだもん。 「もとから順番どおり並んでる」ことが全く期待できないのがRDB。 こういう使い方は辛いと思う。

ORDER BY、つまり並び替えに相当する作業をしないといけないのは通常のファイルシステムだって同じことですね。ファイルシステムにしても、物理的格納順と論理的格納順は分離されていますので。それに、インデックスを使うでしょうから、B-Treeを利用するNTFSやReiserFSと比べても、条件はそれほど代わらないんじゃないかと。

アクセスのたびにSQLを生成し、 バイナリデータのエンコードデコードだの、 SQLの解釈だのを 毎度毎度やってたんでは、 明らかに日が暮れる。

RDBMSにはその種のNavive APIはそもそも存在しませんが、昨今の高速なハードウェアにとって、SQLの生成/解析などというのはそれほど苦になるレベルではありません。もし実装が最適なら、SQLの生成する/しないの差なんてせいぜい数%でしょう。

だって言語として使いづらいじゃんSQL。

SQLは、ただのストレージとしてではなく、集計とか一定以上の高度な演算を行うのにはまあまあいいと思うんですけどね。ただのストレージにはdbmのほうがお勧めだと思います。

おそらくは昔にRDBMSをかなりつかってらっしゃったのでしょうが、この種の性能的用件は時代によって変わりますし実際変わってます。今一度最新のRDBMSに触ってみたら、言語が使いにくい以外の点は新しい発見がたくさんあると思いますよ。

Re:

[Anonymous Coward]

本来のFSなら、最初から特定の(つまりシーケンシャルアクセスの)並び方に最適化した実装をしておけますよね。RDB(汎用の)だと、どこをOrderByしないとならないかはテーブル定義次第、つまり選択の余地をわざわざ残して動的にしてます。そのぶん効率では負けるでしょう。

>高速なハードウェアにとって、SQLの生成/解析などというのはそれほど苦になるレベルではありません。

それが本当だったら、たとえばJavaのPreparedStatementクラス(コンパイル済みSQLをキャッシュしとく仕組み)なんて誰も有りがたがらないと思うんですけどね(^^;

問題はFSだとその生成/解釈の「頻度」

Re:性能差

[L.star (163)]

本来のFSなら、最初から特定の(つまりシーケンシャルアクセスの)並び方に最適化した実装をしておけますよね。RDB(汎用の)だと、どこをOrderByしないとならないかはテーブル定義次第、つまり選択の余地をわざわざ残して動的にしてます。そのぶん効率では負けるでしょう。

RDBMSだと、ORDER BYは当然sorted index scanで処理できると思うんですが、FアルゴリズムレベルでB-Treeを採用したfsと同格or古いのと比べてそれ以上じゃないですかね？

それが本当だったら、たとえばJavaのPreparedStatementクラス(コンパイル済みSQLをキャッシュしとく仕組み)なんて誰も有りがたがらないと思うんですけどね(^^;

ああ、そういえばその部分がありました。しかし、その部分が重宝されるのは字句解析とかコンパイルとかそんな話ではなく、コンパイルしたSQLを元に実行プランを設定するPlannerプロセスの実行結果、実行プランの使い回しが主です。

脱線すると、それらが一切期待できないとしても、PreparedStatementはSQL injection対策がしやすいのでありがたがられてますね。

問題はFSだとその生成/解釈の「頻度」が凄まじくなるという点です。

すいません、その説明を読んでも、どこが凄まじいのかさっぱり分かりません。せいぜい1OS命令に対して極端に多くても(私にとってはたった）2-3SQLで済むように思われますし、結果をある程度キャッシュしておけばどうとでもなりそうなレベルじゃないでしょうか。「すごいことになる」とは全然思われないのですが。 そういえばConnectionの数はどうなるんだろう？ プーリングすれば良いんじゃないんですかね。

脱線続き。それはアプリ側言語がCみたいな素朴な言語ばかりだった頃の話ですね。 GCだの高階関数だの型推論だのが珍しくなくなってきた昨今では

すいません、どこの世界の話ですか？

私の周りのIT業界では、たいていCに似た素朴な言語の世界で、せいぜいオブジェクト指向（それすらコーディング規約で禁止されたりすると聞きますが）が使われている程度、HaskellとかLispとかを使う方向に向いたところを見たこと無いんですが。

私もSQLは理想的と思ってないし、より演算させやすい言語が存在するのは想像に難くないです。

ただしそれらの言語処理系を「DBMSの外に」配置したのでは何時までたっても速度では負けます。なので、DBMSの中にそういった(さらにいえば任意の)言語処理系を置く仕組みは欲しいところです。

純粋な疑問ですが、個人的には、「ストアドプロシージャはDBと同じメモリ空間を利用できるから早いぜ！」というのはもう過去になりつつある気がなんとなくしていたのですが、違うんですかね？RDBMSのボトルネックはCPUになりつつある、と言われてますし。

それはともかく、任意の言語処理系をDBMS内に、と言うのであればPostgreSQLがその種の機能を持っています。

Re:

[Anonymous Coward]

>たいていCに似た素朴な言語の世界で、せいぜいオブジェクト指向（それすらコーディング規約で禁止されたりすると聞きますが）が使われている程度

おいおい。どこの田舎だよ。Rubyか、せめてJavaくらい使おうぜ。
そうすりゃ高階関数(モドキ)くらいなら使えるぜ？

Javaでいえば、Apache Jakarta Commons にゃ高階関数もどきクラスが色々用意されてるな。まだまだ足りないし少々無理もあるけど。

>ストアドプロシージャはDBと同じメモリ空間を

メモリかなあ？ディスクじゃなく？

それ以前の問題として、
何も考えずに「DBサーバ」と「Webサーバ」を別マシンにしてしまう馬鹿運用してるところ多くないか？
メモリやディスクどころかネットワークすら負担かけて、そのくせ両サーバ間のデータ量を減らすような工夫をロクにしてなくてさ。

しまった、こっちも田舎か。。。

目指すはgoogleデスクトップ？

[Anonymous Coward]

ファイルシステムをデータベース化して、利用する用途って、
googleデスクトップのようなものを想定してるのかな？
「あのファイル何処だっけ？」とか言う用途ではgoogleデスクトップ
はかなり便利ですね。

システムベンダーとしては、ファイルシステムがそのまま
データベースになるなら、構築が楽かもしれないと思うが、
リレーションなどの設定はどうやるのかな？
逆に面倒なのではないかな。

存在の耐えられない重さ

[Anonymous Coward]

「MySQLfsの処理速度はext3の10分の1程度」と仰ってますけど、それはファイル読み書きに関しての話ですよね？
なんだか、Sequential Create / Random Createの項目は100分の1以下のような……。

SQLはよく知りませんが、例えば /guten/alice13a.txt をオープンしたいときには、

SELECT inode FROM tree WHERE name='alice13a.txt' AND parent=(
  SELECT inode FROM tree WHERE name='guten' AND parent=(
    SELECT inode FROM tree WHERE parent IS NULL));

みたいなことを実行してるのでしょうか。
ファイル数が多くなると、フラットであることそのものがデメリットになりそう。

Re:

[Anonymous Coward]

今後階層という概念が無くなって行くのではないでしょうか？
gmailのラベルのような分類方法に変わって行くのかもしれません。

見やすさの為に階層っぽく表示することはあるのでしょうが。

Re:

[Anonymous Coward]

>見やすさの為に階層っぽく

というか階層は
「沢山ある見かた(Visitorの振る舞い)のうちの1つ」
に過ぎないということになるでしょうね。
複数あるKEYの1つ。複数ある属性の1つ。

FUSEみたいなものも悪くないんですが、
UNIX風の見かたを強制してしまうという意味では
痛し痒しの仕組みです。

夢も希望も・・・

[Anonymous Coward]

せっかくMSが天文学的資金をつぎ込んでその方向性が「無い」ことを
証明してくれたのに・・・

# そもそもファイルシステムがDBじゃ・・・

一方、

[Anonymous Coward]

"Postgresql fileststem" でぐぐると色々出てきますねぇ。
昔それらしい話を聞いたことも、すでにうろ覚え。

Re:

[Anonymous Coward]

systemじゃなくてststemなの？

# ただのtypoですか

qwerty

[Sithgunner (6190)]

qwerty