アカウント名:
パスワード:
Visual Basic 製と言う事は NTFS 上で利用する事になると思うのですが……。
肥大化した MFT によりディスク領域が圧迫され、しかも別途デフラグソフトを購入しないとデフラグが出来ない (OS 標準のデフラグは MFT の整理をしない) 物が出来上がったと言う事ですか。
RDB でもフルテキストインデックスとか、今時サポートしていない方がレアだと思うんですけどねぇ。
NTFS なら小さなファイルなら MFT に突っ込んじゃうのだし、それこそ Windows Desktop Search や Google Desktop Search と連動させてデータを小さなファイルとして保持させ、検索自体は WDS や GDS
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Visual Basic 製ということは…… (スコア:4, すばらしい洞察)
Visual Basic 製と言う事は NTFS 上で利用する事になると思うのですが……。
肥大化した MFT によりディスク領域が圧迫され、しかも別途デフラグソフトを購入しないとデフラグが出来ない (OS 標準のデフラグは MFT の整理をしない) 物が出来上がったと言う事ですか。
RDB でもフルテキストインデックスとか、今時サポートしていない方がレアだと思うんですけどねぇ。
NTFS なら小さなファイルなら MFT に突っ込んじゃうのだし、それこそ Windows Desktop Search や Google Desktop Search と連動させてデータを小さなファイルとして保持させ、検索自体は WDS や GDS
Re:Visual Basic 製ということは…… (スコア:5, 参考になる)
%temp%の中に大量に一時ファイルを作って後片付けしない行儀の悪いツールをデバッグしたことがありますが、場所が場所だけに何をやらせても遅くなってて大変でした。
署名スパムがウザい?アカウント作って非表示に設定すればスッキリさ。
NTFSでのファイル名のサーチって速いんだ (スコア:2)
幾ら工夫したとはいえ、RDBがファイルシステムに負けるのは信じられないですが。
[1] http://www.squid-cache.org/ [squid-cache.org]
[2] Ian Dowse, David Malone:
Recent Filesystem Optimisations in FreeBSD,
USENIX 2002 Annual Technical Conference, Freenix Track,
Pp. 245–258, June 10-15, 2002
Re:NTFSでのファイル名のサーチって速いんだ (スコア:1, 参考になる)
まじめに実装してあるかどうかはともかくとして、
ファイル数が変化しても全てのファイルに同じ
比較回数でたどり着けるというのがアルゴリズム的な
特徴です。
ファイルを追加したりすると、追加部分の比較回数だけが
増えないように、その都度、ツリー全体を組みかえて
段数調整をやっているハズです。
(サブディレクトリのパスの扱いはどうなっているんだろう?)
他に有名なのは、漢字TALK7のころにしょっちゅう
壊れてくれたMacのBツリーですかね。
# MAC OS8になってから壊れた記憶はないけど。
Re: (スコア:0)
すでにあるアルゴリズムの実装を利用して残りを作るってのは技術の基本なので、バカにしてるっぽい人が多いのはちょっとどうなのよと思う。でも、ことさら取り上げるほどのすごいものでもないような。
Re: (スコア:0)
今回のソリューションで気になるのは、ファイルシステムにべったりなところ。例えば、もっと大量のデータをもっと速く検索したい(ストップウォッチでは計測不可能なくらいに)という要望に答えるのは難しいんじゃないかな。
Re: (スコア:0)
むしろ, NTFSが出てきた頃, 単一ディレクトリに沢山ファイルを置いても大丈夫とか言ってたような記憶が.
Re: (スコア:0)