morihideによる
2008年02月21日 16時29分の掲載
pgfsはどうなった？部門より。
pgfsはどうなった？部門より。
MySQLデータベースをファイルシステムとして利用するためのFUSEドライバ「MySQLfs」が、Open Tech Pressで紹介されています。データベース＋ファイルシステムと聞いて、BFSや幻に終わったWinFSのような、属性を使ってファイルの検索/整理ができるものを想像しましたが、今のところ階層型ファイルシステムをデータベース上に再現するものとなっているようです。また性能面は、Bonnie++によるベンチマークでは、ext3の10分の1程度とのこと。現時点では導入効果が薄い感じのMySQLfsですが、検索などに力を入れてもらえると面白くなりそうです。
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
Database とファイルシステムの統合で期待するべきこと (スコア:4, すばらしい洞察)
期待する人が多いような気がするけど、それは間違っている気がする。
属性の整備とかが適正に行われ、RDB に乗っけたほうがいい形になっている情報なら
検索が速くなるだろうが、
そうなっておらず、RDB に乗っける意味がない情報ならやっぱり速くならず、
形式にとらわれない形でのインデックス付けを行うシステムの方が有用だという状態は
簡単にはひっくり返らないと思う。
じゃあ、なぜ Database とファイルシステムをくっつけようとするのか。
それはもっと低レベルな領域の話で、
という「データベース側の都合の話」だと思う。
ただ、WinFS は「どうせくっつけるなら。。。」と暴走した感がありますけどね。
日本ユニセフ協会への寄付断固拒否
マクロの基本は検索置換
Re:Database とファイルシステムの統合で期待するべきこと (スコア:2, 参考になる)
形式にとらわれない形、といっても個々のフォーマットに応じた解析はするわけですから、これは疑問ですね。おそらく、RDBに乗っけることの出来ないような情報は、現在のインデックス付けでは効率化できないでしょう。
そうではなくて、検索以外のオペレーションが高速化できないのが問題なのです。現在のファイルシステムは、ファイルシステムが要求するオペレーション(ブロックレベルのread/writeとか、ファイルレベルでのアクセスとか)に特化した設計になっています。これは、既存のRDBMSには処理しづらいものです。また、ファイルサイズに非常に幅があって、大抵は100KB以上の大きなものです。これもまた通例数百バイト程度の小規模レコードがたくさんあることに特化した設計を採用するRDBにはつらいものです。
MySQLfsに関して言えば、そこに付けられるものがあるから、じゃ無いですかね。同様のものにpsqlfsがありますが、これもはっきり言って「できるから統合してみた」以上の何かではありません。それ以上に興味深いものは無いため、そこで止まってしまいます。
その種の話は、むしろ専用サーバやraw I/Oのような、DBサーバ用ファイルシステム不要論に向かいます。はっきり言うと、ext3程度のジャーナルファイルシステムの提供する信頼性は、DBにとっては全然足りませんので、結局全部実装するしかありません。一方、ファイルシステムにとってはRDBMSが要求するような信頼性やトランザクションを必要としないですし、それによって性能が犠牲になりますから、両者を統合しようという方向にはなりません。
WinFSは「検索したい/アドレス長などのデータして統合して使いたい」->「じゃあRDBMS使おう」という設計的な流れを普通に踏んだのだと思います。で、read-write性能が出ない->NTFSベースにするしかない->現場混乱して収拾つかない->中止、という形を踏んだのでしょうね。しかしRDBを使うかどうかはともかくとして、最初の理念は間違ってないと思うのです。今のところ「検索」は実現できましたが「統合」は出来てません。そこは今後どのように実現されるか楽しみな部分ではありますね。
親コメント
memcachefs (スコア:3, 興味深い)
http://memcachefs.sourceforge.net/ [sourceforge.net]
fuseを使うとなんでもファイルシステムに出来てしまうんですね。
(実用的かどうかはわかりませんが・・・)
温故知新 (スコア:1, 興味深い)
なんだ、Netware の再発明か。
Re:温故知新 (スコア:3, おもしろおかしい)
…絶対無いわ。
親コメント
Re:性能差 (スコア:1)
冗長化とか、トランザクショナルなファイル操作とかの可能性があるかも、とか思いました。（可能性、ね。）
親コメント
Re:性能差 (スコア:1)
原理的にinodeがないのも良いね。
ファイルの中身をどのようなデータ型で保存しているのかねえ。
とりあえずならBLOBなんだろうが、その場合速度は期待できないかも。。。
と思って、記事のリンク先を見たところ、なんとinodeがある。ただしDBの主キーとしての扱い。BIGINT(20)なので枯渇はしないと思う。ファイルの中身はBLOB。
いまのところ技術展示でしかない感じ。
親コメント
Re:性能差 (スコア:1, 興味深い)
1行あたり固定長データ＊行番号(?)
でアクセスすることで、
速くなる可能性も無いでもないでしょうね。
でもシーケンシャル読み出しは絶望的に遅いんじゃないかな？
だってハイコストな「order by」を処理しないとならないんだもん。
「もとから順番どおり並んでる」ことが全く期待できないのがRDB。
こういう使い方は辛いと思う。
あとファイル内容検索も期待できないだろうな。
もし固定長データを各行に持たす実装なら、
検索語が固定長の境界をまたぐかどうかで
検索のしかたを色々変えないとならないのだから、
そのぶん無駄だらけになる。
＃16bit時代、BLOBに絵のファイル突っ込んだら怒られたのでAC
あと気になるのが「SQLを」使ってるかどうか。
RDBだけならまだしも、それに加えて、
アクセスのたびにSQLを生成し、
バイナリデータのエンコードデコードだの、
SQLの解釈だのを
毎度毎度やってたんでは、
明らかに日が暮れる。
SQLを華麗にスルーしてNativeAPI(あるの？)で叩いてるのかな？
＃普通の業務アプリもSQL経由したくないのでAC。だって言語として使いづらいじゃんSQL。
親コメント