アカウント名:
パスワード:
属性の整備とかが適正に行われ、RDB に乗っけたほうがいい形になっている情報なら検索が速くなるだろうが、そうなっておらず、RDB に乗っける意味がない情報ならやっぱり速くならず、形式にとらわれない形でのインデックス付けを行うシステムの方が有用だという状態は簡単にはひっくり返らないと思う。
形式にとらわれない形、といっても個々のフォーマットに応じた解析はするわけですから、これは疑問ですね。おそらく、RDBに乗っけることの出来ないような情報は、現在のインデックス付けでは効率化できないでしょう。
そうではなくて、検索以外のオペレーションが高速化できな
WinFSは「検索したい/アドレス長などのデータして統合して使いたい」->「じゃあRDBMS使おう」という設計的な流れを普通に踏んだのだと思います。で、read-write性能が出ない->NTFSベースにするしかない->現場混乱して収拾つかない->中止、という形を踏んだのでしょうね。
「SQL Server を NTFS に統合する」
ファイルシステムにとってはRDBMSが要求するような信頼性やトランザクションを必要としないですし、
実際、WinFS が高速になる理由の説明として 「”対応するハードウェア”と組み合わせることで、ログの書き込みを10分に1回程度に減らすことができる」
Flush と HDD を組み合わせた Hybrid型HDD とかを提案したりした経緯を経て
PostgreSQL で「ログが物理的に書き込まれるまで待つか否か」ってオプションがあったことでも 「ログの書き込み」が Database での影響の大きい速度のボトルネックの一つだということがわかります。
"fsync=off"はあらゆる同期書き込みを非同期に置き換える、であって、ログを意味していません。そもそも、ログのない時代の、あらゆる書き込みが同期だった頃の名残です。非常に紛らわしいオプションなのですが。
8.3で追加されたやつのことを言っているのなら、信頼性と性能のトレードオフがユーザーに選べるようになったという点で好ましいと思います。過去形で語られるような内容では無いと思いますが。
僕は「googleデスクトップ」とか「属性や構文レベルをぶっとばして全文検索で字句レベルでマッチさせるようなエンジンの方が現時点では一定の成果を上げている(= ある種の効率化を達成している)」と考えています。
あれはプラグインを使って個別に属性レベルの解析をしているわけであって、必ずしも構文とかそういうのを無視しているわけではないと思いますが。ただ、それをファイルシステムに集約するか、裏でアプリケーションとしてやるかの違いではないでしょうか。ただの機械的全文検索だったら、googleデスクトップのようなツールは見向きもされなかったと思います。
単純にデータとしてみるなら、RDB に載っているデータだけが大事ということはないと思います。
トランザクショナルなRDBMSは、それが前述されたとおり「ログの書き込みがボトルネック」であることを知った上でも、要件として単なるクラッシュからのトランザクション保護を強固に行います。一方で、たいていのジャーナリングファイルシステムは高々fsckしなくて済む程度にしかしません。性能面を考えれば当然の妥協だと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
Database とファイルシステムの統合で期待するべきこと (スコア:4, すばらしい洞察)
期待する人が多いような気がするけど、それは間違っている気がする。
属性の整備とかが適正に行われ、RDB に乗っけたほうがいい形になっている情報なら
検索が速くなるだろうが、
そうなっておらず、RDB に乗っける意味がない情報ならやっぱり速くならず、
形式にとらわれない形でのインデックス付けを行うシステムの方が有用だという状態は
簡単にはひっくり返らないと思う。
じゃあ、なぜ Database とファイルシステムをくっつけようとするのか。
マクロの基本は検索置換(by y.mikome)
Re: (スコア:2, 参考になる)
形式にとらわれない形、といっても個々のフォーマットに応じた解析はするわけですから、これは疑問ですね。おそらく、RDBに乗っけることの出来ないような情報は、現在のインデックス付けでは効率化できないでしょう。
そうではなくて、検索以外のオペレーションが高速化できな
Re:Database とファイルシステムの統合で期待するべきこと (スコア:1)
一つの目的にたる発想の元は唯一だと限らないので、どの回答の唯一絶対の回答ではないですが、
WinFS は
というアプローチが取られたはずです。
実際、WinFS が高速になる理由の説明として
「”対応するハードウェア”と組み合わせることで、ログの書き込みを10分に1回程度に減らすことができる」
となっていました。
PostgreSQL で「ログが物理的に書き込まれるまで待つか否か」ってオプションがあったことでも
「ログの書き込み」が Database での影響の大きい速度のボトルネックの一つだということがわかります。
で、WinFS は変な期待されたり、実装が遅れたりしていただろうところへ
横槍(デフラグソフトのメーカあたりが文句を言った)が入ったりで
Native なファイルシステムであることをあきらめたが、
上記の「ログの書き込みを減らす」という方向は NTFS の機能としてそのまま実装がすすめられ、
Flush と HDD を組み合わせた Hybrid型HDD とかを提案したりした経緯を経て
現時点では Windows ReadyBoost みたいな機能になっています。
僕は「googleデスクトップ」とか「属性や構文レベルをぶっとばして全文検索で字句レベルでマッチさせるようなエンジンの方が現時点では一定の成果を上げている(= ある種の効率化を達成している)」と考えています。
う~ん、この点は必ずしも正しくないとおもいます。OS の文化の違いかもしれないですが。
単純にデータとしてみるなら、RDB に載っているデータだけが大事ということはないと思います。
そして、Windows では Volume Shadow Copy や Distributed File System、Cluster などの機能が
NTFS の信頼性やトランザクション性能に強く拠っているとみとれます。
マクロの基本は検索置換(by y.mikome)
Re:Database とファイルシステムの統合で期待するべきこと (スコア:1)
"fsync=off"はあらゆる同期書き込みを非同期に置き換える、であって、ログを意味していません。そもそも、ログのない時代の、あらゆる書き込みが同期だった頃の名残です。非常に紛らわしいオプションなのですが。
8.3で追加されたやつのことを言っているのなら、信頼性と性能のトレードオフがユーザーに選べるようになったという点で好ましいと思います。過去形で語られるような内容では無いと思いますが。
本当に単なる機械的全文検索だったら、"Recieved"とか"Subject"で検索するとあらゆるメールヘッダが引っかかってどうしようもないと思いませんか?そんなソフトだったら到底使いものになると思いません。あれはプラグインを使って個別に属性レベルの解析をしているわけであって、必ずしも構文とかそういうのを無視しているわけではないと思いますが。ただ、それをファイルシステムに集約するか、裏でアプリケーションとしてやるかの違いではないでしょうか。ただの機械的全文検索だったら、googleデスクトップのようなツールは見向きもされなかったと思います。
いえ、大事か大事でないか、ではなく、どの程度の信頼性を求めるかです。トランザクショナルなRDBMSは、それが前述されたとおり「ログの書き込みがボトルネック」であることを知った上でも、要件として単なるクラッシュからのトランザクション保護を強固に行います。一方で、たいていのジャーナリングファイルシステムは高々fsckしなくて済む程度にしかしません。性能面を考えれば当然の妥協だと思います。
Re: (スコア:0)
RDB(きめうち検索エンジン?)とは
住む世界が違いますよね。
RDBにゃ「スキーマのメンテナンスをガチでキメないと、性能どころか論理(データ辻褄)的にも瓦解する」というナイーブな面があります。
正規化とかですね。
しかも変更があった場合も常に正規化とかをきっちりやり「つづけ」ないとならない。
それを受け入れてでも性能やカッチリさが欲しい!という場面では、RDBを使ったほうが得。
受け入れにくい状況なら全文検索のほうがきっと強い。
「あれーあのデータどこに有ったっけ?」
なんてほざくかたがた(w)に対しては、
それが所謂業務であろうがなんだろうが、