アカウント名:
パスワード:
Visual Basic 製と言う事は NTFS 上で利用する事になると思うのですが……。
肥大化した MFT によりディスク領域が圧迫され、しかも別途デフラグソフトを購入しないとデフラグが出来ない (OS 標準のデフラグは MFT の整理をしない) 物が出来上がったと言う事ですか。
RDB でもフルテキストインデックスとか、今時サポートしていない方がレアだと思うんですけどねぇ。
NTFS なら小さなファイルなら MFT に突っ込んじゃうのだし、それこそ Windows Desktop Search や Google Desktop Search と連動させてデータを小さなファイルとして保持させ、検索自体は WDS や GDS とかに任せた方が効率的なんじゃないかと思う。
多少データが増えたところで、単なるミラーリング & インデックス再生成程度で環境移行も出来ちゃうし。
つーかこれ、書庫ファイルでバックアップ取ろうにも zip とかじゃファイル名は圧縮されないから tar + gzip/bzip2 とかじゃないと悲惨だよね。NTFS 上に Unicode ファイル名で記録すると約 32,000 文字とか使えちゃうから、下手な fs 上じゃ展開できないんじゃない?
# 説明されたのに金を出した客の方がすごいと思う。
つーかこれ、書庫ファイルでバックアップ取ろうにも zip とかじゃファイル名は圧縮されないから tar + gzip/bzip2 とかじゃないと悲惨だよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
Visual Basic 製ということは…… (スコア:4, すばらしい洞察)
Visual Basic 製と言う事は NTFS 上で利用する事になると思うのですが……。
肥大化した MFT によりディスク領域が圧迫され、しかも別途デフラグソフトを購入しないとデフラグが出来ない (OS 標準のデフラグは MFT の整理をしない) 物が出来上がったと言う事ですか。
RDB でもフルテキストインデックスとか、今時サポートしていない方がレアだと思うんですけどねぇ。
NTFS なら小さなファイルなら MFT に突っ込んじゃうのだし、それこそ Windows Desktop Search や Google Desktop Search と連動させてデータを小さなファイルとして保持させ、検索自体は WDS や GDS とかに任せた方が効率的なんじゃないかと思う。
多少データが増えたところで、単なるミラーリング & インデックス再生成程度で環境移行も出来ちゃうし。
つーかこれ、書庫ファイルでバックアップ取ろうにも zip とかじゃファイル名は圧縮されないから tar + gzip/bzip2 とかじゃないと悲惨だよね。NTFS 上に Unicode ファイル名で記録すると約 32,000 文字とか使えちゃうから、下手な fs 上じゃ展開できないんじゃない?
# 説明されたのに金を出した客の方がすごいと思う。
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)
客もネタで付き合ったのでは？ (スコア:1)
金出した客の方もネタで付き合ってみただけじゃないかなぁ．
さすがにIT関連の担当者ならトンデモだって気付きそうなものだが…
屍体メモ [windy.cx]
Re:客もネタで付き合ったのでは？ (スコア:1, 参考になる)
http://blog.goo.ne.jp/katakait/e/957a40199c4a276ac0e59434a52f9006
とか。
結局は良いところ（検索が速い）ばかりしか見ていないだけのようですがね。
市販のRDBで同等のシステムを構築するより安くて簡単というのはある意味同意ですが
ファイル数が多くなったらどうなるか分かってるの？とか
バックアップのこと考えてる？とか、そういうシステムとしての
トータルの性能をちゃんとユーザが分かっているかは不明ですね。
しかし、「庄司渉」って人は一応色々なことをやっていた人なのですね。
WILLなんとかの人みたいに、まるっきりトンデモな人ではなさそうです。
Re:Visual Basic 製ということは…… (スコア:1)
◆IZUMI162i6 [mailto]
むしろ Windows を (スコア:0)
#バックアップは dir /b > backup.txt で(w 圧縮は NTFS にお任せで(爆
Re: (スコア:0)