バックアップ方法再考

私はMac OS Xを使っているが、作業環境として、Bootcamp 及び VMwareとして使う Windowsのパーティションを保持している。「作業環境」と言ったのは、大事なデータは殆ど入っていないという意味で、例えば外付けドライブのファイルを閲覧したり、後でMacに渡す Microsoft Office 書類を作成したり、という一時的な用途に使っている。

Bootcamp パーティションのバックアップは、多くのユーザが懸念することと思われるが、作業環境として割り切るなら、dd コマンドを使ってパーティションを丸ごとバックアップするのは、案外良い選択だと思った。

dd は、例えば、このように使う。

# 対象デバイスの識別子を確認する
$ diskutil list

# 確認したBootcampパーティションをアンマウントする
$ diskutil unmount /dev/disk0s3

# パーティションのイメージを外部ディスクにバックアップする
$ dd if=/dev/disk0s3 of=/Volumes/External_Disk/（ファイル名）

最大のメリットは速さだ。大きなファイルをコピーするような感覚で終わる。USB2.0 で接続した 7200rmp の外付けディスクの場合は、約15Mbyte/sの速さが出た。USB2.0 で単純にファイルコピーをする時の実効速度は20Mbyte/s前後だったから、その快適さが分かると思う。約9.5GBのパーティションだったので、ほんの12分でバックアップできた。（パーティションがこの大きさなのは、まさに作業環境でしかないからだ。）　IEEE1394 や eSATA で繋いだディスクになら、もっと速く終わるのではないだろうか。

個別にファイルをバックアップしたり、差分を取ったりすると、これよりずっと遅くなる。「作業環境」のバックアップは、正常に動くシステム及びアプリケーションの保存だから、差分でバックアップを取る必要性は小さい。むしろ正常に動く環境を丸ごと残した方が便利だ。

案外問題になるのは、dd コマンドを使うことの心理的な敷居の高さだと思う。

StataとRの行列計算の速さ

Title: Speed of matrix calculation with Stata and R

アメリカでは、大学、リサーチ機関、政府の至る所で、統計・計量分析ソフトと言えばStataが最も広く使われている。デファクト・スタンダードといっていいかも知れない。日本ではあまり使われていないのが不思議なくらいだ。

In the United States, Stata is the application that is the most commonly used for statistical and econometric analyses, in academic institutions, research institutions and government agencies. It can safely be said that Stata is a de facto standard. For unknown reason, it is not widely used in Japan.

Stataの良いところの一つに、主要な機能ではないかも知れないが、行列計算が簡単にできるところがある。計量モデルを作る時には、地道に行列を計算したいこともあるかと思う。そこで、この道を専門にする人には分かりきったことかも知れないが、行列計算のスピードはどうなのかと気になり、フリーソフトのRと比べてみた。

One of the good things with Stata is that it is handy for matrix calculation, which might not be a major functionality of Stata. Yet you might want to calculate matrices by yourself when you would construct econometric models. In this light, the speed of matrix calculation arose as my concern, and I decided to compare it with that of R, a free statistical software. Experts in this area might know which is faster, though.

比較はまずMac OS X 10.4上で行った。使用したStataは、Intercooled Stata 9というバージョンである。これは通常版と比べて、扱えるデータの量に制限がつけられている。また、別途MPというバージョンがあるので分かるように、マルチプロセッサをパラレルに使った処理はできない。

The comparison was made on Mac OS X 10.4. The Stata I used is 'Intercooled Stata' version 9. This version has limited functionalities in terms of the size of data it can handle. Additionally, it can't compute using multiple processors in parallel, which is known from the fact that an MP version exists.

まず、確率密度関数を使い、正規標準分布N(0,1)に従う乱数を各要素に持つ、800x800の行列Xを作成する（800なのは、これがIntercooled Stataが扱える最大要素数であるため）。各要素は最大で小数点以下8桁の大きさを持つとする。次に、以下の計算に要する時間を計測した。

Firstly, using a probability density function, I prepared an 800 by 800 matrix whose elements were random numbers that conform to the standardized normal distribution N(0,1). (The matrix size is 800 because it is the maximum number of elements that Intercooled Stata is allow to handle.) Each element has at maximum eight digits for decimal fractions. Then, I timed the following calculations.

(1) Xの転置行列をYとしたとき、YX
     YX, where Y is a transpose of X

(2) YXの逆行列
     Inverse of YX

Stataでは、(1) に約30.7秒、(2) に 2.3秒を要した。（共に手動計測による）

Stata took approximately 30.7 seconds for (1) and 2.3 seconds for (2). Both are timed manually.

matrix X = matuniform(800, 800)    
matrix TX = X'
matrix A = TX*X
matrix B = inv(A)

R 2.6.1（Stataに合わせてGUIを使用）では、(1) は約0.5秒、(2) は約0.9秒だった。

R 2.6.1 (GUI version, as is Stata) took approximately 0.5 seconds for (1) and 0.9 seconds for (2).

x <- matrix(rnorm(640000), nrow=800, ncol=800)
system.time(z <- (t(x) %*% x))
system.time(solve(z))

R も Stata も、LAPACK および BLAS、あるいはそれを元にした計算ライブラリを使っているのだが、特に (1) において、何故これほど著しい差が出るのだろう。ライブラリを使っている箇所が違うのだろうか。(2) の逆行列の計算に関して言えば、差が2倍弱の開きであることから、マルチコアを使っているかどうかの違いだけであるかもしれない。

I wonder where these remarkable differences, especially in (1), come from, for both R and Stata use LAPACK and BLAS, or scientific libraries originating from them.  Would it be a difference as to whether they use such libraries or not for specific computation models? As for the calculation of an inverse matrix with (2), the difference might have stemmed solely from whether they use multiple cores of CPU or not, because R run nearly two times faster.

補足： Windows用の Stata 10 MP をDual Core CPUで使える機会があったので、同じ計算を行った。(1)の計算に要した時間は 5.3秒で、随分Rに近くなった。Mac OS用の Intercooled Stata 9とは、なんと5倍以上の差がある。これはバージョンの違いというより、Mac OS版の出来が良くないからではないかと思われる。

PS: I had a chance to run Stata 10 MP for Windows on a dual core platform. The time required to calculate (1) was about 5.3 seconds and close to the speed of R. The performance was more than 5 times better than that of Intercooled Stata 9 for Mac OS X. From my speculation, the difference is in that the build for Mac OS is not designed well rather than in the difference in versions

2008年1月18日、Mac OS Xで行った計算を再計測し、この記事を改訂した。前回の計測に当っては、Macbook Proからバッテリーを外して使用していたため、Macbookの設計上、約半分の計算能力で稼働していた。

ソフトウェアの最適化ビルド

CPUのアーキテクチャに最適化したソフトウェアは、どれほどのパフォーマンスの向上をもたらすのだろうか？最近はIntelのデュアルコアCPUが大幅な性能向上を果たしたが、仮にソフトウェアをビルドする過程でCPUの新しいアーキテクチャを活かしきれていないとしたら、それはもったいないことだ。

最適化という意味では二つの岐路がある。一つはコンパイラの選択、もう一つはコンパイルオプションの選択。前者に関しては、いくつかのウェブサイトで比較を見ることができる。GNUコンパイラに比べて、インテルの商用コンパイラは非常に良い結果を出すらしい。（一方、GNUコンパイラは、バージョン4.0および4.1ではIntel Core Duoを使った場合に僅かに3.3より改善、それ以外のCPUではバージョン3.3より良い性能は出ないらしい。4.2になってやっとましになったとのこと。）

残るコンパイルオプションの選択は、ソフトウェアの演算能力をどう変えるのか。Intel Core Duo 2.0 GHzを搭載した Macbook Proで実験してみた。今回取り上げるソフトウェアは、画像処理の ImageMagick である。

比較したのは次の二つである。

（ア）　Mac OS X 10.4 に付属のGNUコンパイラ 4.0.1を用い、最適化フラグは -O2 だけでビルドしたImageMagick 6.3.7

（イ）　GNUコンパイラ 4.2.2を用い、Core Duo向けの最適化フラグとして -pipe -O2 -march=prescott -msse3 -fomit-frame-pointer を用いてビルドしたImageMagick 6.3.7

純粋に最適化オプションだけの比較でなく、むしろMac OSのデフォルトの開発環境と、新しくて性能にも留意した開発環境との比較ということになる。

ImageMagick の convert コマンドを用い、5016 x 7602 ピクセルの大きさの 16 bit TIFF形式の画像ファイルを、unsharpマスクをかけて縮小し、その時間を計測した。それぞれの実施前にはコンピュータを再起動し、ほどなく実験を行っている。Unsharpマスクには、Catromを選択した。Catrom自体がどのような計算をしているのか私は詳しく知らないが、積分及び行列計算が多くを占めると想像している。これが、最適化の検証に ImageMagick を用いようと思った一つの動機である。

結果は、50%に縮小した場合（convertのunsharpパラメターは9x1.4+1.0+0.02を使用。演算量は多いはず）

（ア）　1分6秒56
（イ）　1分5秒11 （-1.45秒）

12.5%に縮小した場合（unsharpパラメターは2.3x0.43+1.0+0.02）

（ア）　33秒86
（イ）　34秒73 （-0.87秒）

となった。計測時間には、241MBもの大きさのファイルの読み込みから、書き出しまでが含まれるので、演算自体の所要時間は分からないが、いずれにせよ目立った改善にはならなかった。

ImageMagick は MacPorts を使って導入している。MacPortsに登録された多くのソフトウェアが、デフォルトでは（ア）の条件でビルドするように設定されており、（イ）の条件を適用するのは少々面倒なのだが、その設定をするだけの価値は気休め程度でしかないということだ。性能向上のためなら、Intelのコンパイラを用い、半年でもあとに発売されたコンピュータを用いるほうが効果的だ。

ウェブブラウザのカラーマネジメント（２）

前回の記事では、ブラウザを巡るカラーマネジメントについて書いたが、図らずも「（Vistaより前の）WindowsはsRGBで統一されている」という一般知識に反することになった。自分でも俄に信じられなかったので、今回はその点を検証する。

おさらいがてらに、その命題をもう少し正確に書くと、次のようになる。

• Vistaより前のWindowsでは、ビューアーを例外とした、システム付属の全てのアプリケーションにおいて、画像のカラースペースがsRGBであることを前提とする。すなわち、Windowsの内部では、全ての画像のカラースペースを強制的にsRGBとして解釈する。これはFirefox 2でも同様である。

• よって、画像がsRGBというICCプロファイルを持つか持たないかに関わらず、sRGBのカラースペースで作成された画像は正しい色で出力される。（ここのでの「出力」とは、アプリケーションのものであって、ディスプレイやプリンタとは無関係）

これが仕様としてだけでなく結果的にも正しいなら、先の記事でテストしたsRGBの写真は、Windowsのどのアプリケーションでも正しく同様に表示され、また、他のカラーマネジメントされたシステムとも、外部出力時の違いは割り引いても、ほぼ同じに見えなければならない。

ところが、実際に検証してみるとその通りではなかった。

下の表は、３種類の画像を、それぞれWindows XP上の３つのアプリケーションで表示させた時の色再現をまとめたものである。一枚目の画像は、sRGBの色空間を持ち、かつsRGBのICCプロファイルが埋め込んであるもの。二枚目の画像は、sRGBの色空間を持つが、ICCプロファイルは持たないもの。三枚目の画像は、Adobe RGBの色空間を持ち、かつAdobe RGBのICCプロファイルを持つものである。（これらの画像はMac OS XとPhotoshopで用意した。）評価に用いたアプリケーションは、Internet Explorer 6 (IE 6)、OS付属のビューアー、それからカラーマネジメント機能をオンにしたFirefox 3である。（正確な比較のために、Firefox 3のモニタプロファイルに合わせた色変換機能はオフにした。）

先に述べたWindowsの流儀から考えると、一枚目（「sRGB」）と二枚目の画像（「なし」）は、３つのアプリケーションのどれを使っても同じ見え方をしなければならない。しかし、「なし」の画像は、IE 6とビューアーで見ると、明らかに色褪せて見えた。即ち、プロファイルがない画像をWindowsが強制的にsRGBとして解釈する方法は、上手くいっていないということだ。（万一、他に原因があり、その解決によってsRGBの色再現を本来のものにする方法があれば、ご教示頂きたい。）

次に、それではsRGBのICCプロファイルが埋め込まれているなら正しい色が表示されるのか、という問題はどうだろう。sRGBのプロファイルを持つ画像（「sRGB」）の色再現には、「良」と「最良」の２種類を示しているが、実は、この二つには明らかな相違があったのだ。この「良」が意味する所は、カラーマネジメントの対象にはなっているようだが、あるべき色の再現ではなかった、というほどのものだ。見る限り正しい再現をしていたのはFirefox 3だけだったのだ。Firefox 3の表示は、同じ画像をMacで見た時のものと同じだった。（参考までに補足すると、評価に用いたWindows XPは、Macbook ProからBootcampを用いて起動している。また、Mac OSでもWindowsでも、モニタのキャリブレーションを行っている。つまり、表示デバイスが同じで、特性も揃えてあるから、私の見た目による色評価は、OSとアプリケーション自体の色再現能力の評価に他ならない。）前回の記事は正しかったことになる。

さらに興味深いのは、「良」と一括りに評価したものが、必ずしも同じ見え方ではないことだ。同じsRGBのカラースペースを持った一枚目と二枚目の画像に限っても、IE 6とビューアーでは、判別が困難なほどではあるが、違いがある。また、二枚目の画像をFirefoxで見た時は、一枚目の画像をWindowsアプリケーションで見た時の「良」ほどではないながら、「不可」の場合よりは良い結果であった。これは、Windowsにおいては、色の管理がアプリケーションレベルでの実装に委ねられてきたという点と符合する。

一枚目と三枚目では、そもそもカラースペースの広さが違うので、それに対応してAdobe RGBの「良」はsRGBの「良」を上回った。

結論を再確認すると、Windows XPにおいては、OS及びアプリケーションレベルでのsRGBへの色の統一すら不完全である。よって、画像が持つカラースペースがsRGBであっても、sRGBというICCプロファイルは埋め込むべきである。また、ブラウザはFirefox 3か、Safariを使うべきである。

ウェブブラウザのカラーマネジメント（１）

コンピュータでのカラーマネジメント（色管理）については、他に分かりやすく体系的に説明したウェブサイトがあるので、齧った程度の私が頑張ってBlogに書くこともない。ただ、カラーマネジメントができていない場合に、写真によっては、とてつもなく元と違う見え方をすることは是非書いておきたいと思った。

これは近頃、フィルムをスキャンしてラボでプリント、あるいはインターネットに掲載するようになって、非常に気にするようになったからだ。愛着のある写真が、他のコンピュータでは全く異なって見えると、少なからずショックを受ける。

他のコンピュータでの見え方と言う時、カラーマネジメントには二つの側面がある。一つは、あるICCカラープロファイル（sRGB、AdobeRGB、 PhotoRGBといった、カラースペースに関する情報）を持った写真をアプリケーションが正しく出力すること。もう一つは、そのアプリケーションの出力を、さらにモニタの特性に合わせて変えることだ。後者はモニターのキャリブレーションの問題で、それなりの質のモニタと、キャリブレーション用のハードウェアを買わないとできないことだ。しかしながら、前者はOSとアプリケーションの問題であり、これが正しく行われないというのは、一連のカラーマネジメントの根幹に関わる。Photoshopなどで色を調整したくても、モニタなりプリンタなり、それぞれ異なる特性を持つ機器を通った後の色を見ながら、勘に頼ってやらざるを得ないからだ。

それなのに、コンピュータというものが画像を表示するようになってから、一貫して色を正しく扱えるのは、Macintosh時代からのMacだけである。OSの宗派論争にするつもりではないが、今ほど一般人が盛んに写真や絵をコンピュータで扱い、またメディアが多くの情報を写真を用いて伝える時代に、コンピュータの大部分を占めるWindowsが色を正しく扱えないのは、奇異と言わざるを得ないだろう。

ではどれほどの違いが表れるのか、次の写真で見てもらおう。

// カラーマネジメント　不可 //

// カラーマネジメント　有効 //

一枚目の画像は、Mac OS Xの上で、カラーマネジメントができないウェブブラウザ（Firefox 2）が表示した画像のキャプチャ。二枚目の写真は、カラーマネジメントが有効なウェブブラウザ（Firefox 3 ベータバージョン、設定が必要）が表示したもののキャプチャである。2枚目はApple標準ブラウザのSafariと同じ色になる。緑の発色が一目瞭然に違うことがお分かりだろう。色のマッチングができていないシステムでこのページを見ると、2枚の写真のどちらも正しくない色で見える訳だが、それでも、色に大きな違いがあることを知るには十分な例だ。ちなみに、上のどちらのキャプチャ・ファイルもsRGBのICCプロファイルを持っている。

Windows環境におけるウェブブラウザに関して、カラーマネジメントがどうなっているか、簡単に説明する。まずVista以前でInternet Explorer (IE) 6を使った場合は、完全に無力である。IE 6は画像がsRGBであることを想定しているらしいので、わざわざsRGBに変換したファイルを読ませるが、それでも正しい色で表示されない。上の一枚目の写真と同じ色になる。（追記：この箇所は、「WindowsはsRGBで統一されている」という、自分が持っていた知識に反することを思い出し、間違ったことを書いたかも知れないと思って再度検証した。結果は本Blogの次の記事でご覧頂きたい。）これは、同じシステムの上で Firefox 3 を使って表示したものとは全く違う色になることから、どんなにモニタの出力が狂っていようと明らかだ。VistaとIE 7の組み合わせになると、sRGBならsRGBの色で表示はするようだ（要検証）。しかし、sRGBを想定していることには変わりがないので、それ以外のプロファイルを持った画像は正しく処理できない。唯一、Firefox 3を使った場合にのみ、画像固有のカラープロファイルを個別に解釈し、尚かつ、モニタのカラープロファイルにあわせた表示をすることができる。尚、Appleがベータ版として出しているWindows用のSafariでも、カラープロファイルに対応している。まだ英語以外の言語やフォントに対応していなかった、最初のバージョンからそうだった。Appleが何に価値を見いだしているかを垣間見るようで、面白かった。

一方、Macの場合は、SafariとFirefox 3がカラーマネジメントに完全に対応している。つまり、VistaとFirefox 3の組み合わせと同じことができる。

カラープロファイルへの対応をもう少し詳しく説明すると、あるウェブサイトにどんなカラースペースを持った画像が載っていても、ブラウザがそれぞれを同時に正しい色で出力すると言うことだ。そのメリットの一つは、画像の作成者の事情に左右されないことだろう。画像には、使ったデバイスの都合や、その最終的な利用形態によって、異なるカラースペースが設定されうるからだ。逆に、何のカラースペースを持つかの情報は付与しなければならない訳だが、ない場合にのみsRGBなどのカラースペースで解釈すれば良いだけの話で、IEのように、どんな画像もsRGBに強制する必要はなかった訳だ。もう一つのメリットは、とりわけsRGBというカラースペースに縛られないことがある。sRGBは今となっては古くなりつつある規格で、再現できる色の範囲が限られている。長期的な視野でカラーマネジメントの仕組みを考えると、一時の規格に限定するのは賢明な方法ではない。sRGBの後、より広い色空間を持つAdobeRGBが広まっていたが、最近ではさらに広いPhotoRGBが使われ始めている。

出力側のメリット、つまり、モニタの特性に合わせた色表示をすることのメリットは、説明するまでもないだろう。汎用液晶モニタでは、そもそも性能上の限界があるが、それでもキャリブレーションしてやると、目に見えて色が変わる。（私はX-RiteのEye-One [i1] Display 2というローエンドの製品を使った。アメリカでは200ドル程度なのでお買い得だ。）Firefox 3では、キャリブレーションして作る、モニタ用プロファイルを指定できるのだ。IE 7ではできない。

出力側に関して重要なことを補足すると、Mac OSでは、通常、実はこのようにアプリケーション毎にモニタプロファイルを設定する必要すらない。それはOSが一貫して管理しているからだ。一部で対応していないアプリケーションもあるが、Apple製を含むほとんどのアプリケーションで、個別のモニタに合わせた色を表示することができる。換言すれば、Appleが色管理の仕組みを提供しており、それを利用すれば、入力から出力まで、カラーマネジメントに対応したアプリケーションを比較的容易に作れるのだ。

ついでながら、Intel MacではVMware Fusionを使ってWindowsを同時に走らせることができるが、この場合は、VMware Fusionがカラーマネジメントを行わないので、その中のWindowsでFirefox 3を使っても正しい色にはならない。Mac OS XでFirefox 2を使って見た場合と同じ色で表示される。

最後に。まだまだ IE 6を使う人がかなりを占めると思われるから、Flickrなどにアップロードする写真は、sRGBにするに越したことがない。モノクロ写真の場合は、Dot Gain XX% などというプロファイルはダメで、強制的にsRGBに変換するか、Gray Gamma 2.2などにする必要がある。

Mac OS XからVMwareクライアントへのポートフォワード

Mac OS X でポートフォワードを実現するには、通常のUnix/Linuxの方法が使えないようだ。

ネット上を検索すると、一つには、OS X の「インターネット共有」として稼働している natd を一度終了させ、新たに作成した設定ファイル (nat.conf) を読み込ませて natd を再起動する方法が用いられている。他には、/usr/libexe/InternetSharing  というコンパイル済みのファイルの可読部分を変更している例もあったが、これは他の手段がある以上、避けるべきだろう。　

これらの方法は、あくまで OS X の NAT の設定を変えるためのものだ。よって、フォワード先が Parallels Desktop や VMware Fusion （以下、VMware）のバーチャルマシンである場合は、バーチャルマシンはそれぞれのアプリケーションに付属する DHCP/NAT の下にあるため、同じ方法を使うことが出来ない。

VMwareの場合はどうすれば良いか。VMwareのNATは、vmnet-natd というプログラムによって動いているのだが、私はこの設定ファイルを変更することで、port forward を実現することが出来た。

まず、動いているプログラムと引数を調べる。ターミナルで ps -ax | grep  natd を実行すると、

/Library/Application Support/VMware Fusion/vmnet-natd -c /Library/Application Support/VMware Fusion/vmnet8/nat.conf -m /Library/Application Support/VMware Fusion/vmnet8/nat.mac -d /var/run/vmnet-natd-vmnet8.pid vmnet8

の一行が表示され、設定に使われている nat.conf が特定できた（VMwareで別のネットワーク形式を選択している場合は、'vmnet8' に相当する部分が異なる）。このファイルを開くと、カスタマイズ例がコメントアウトした状態で書き込まれており、実はカスタマイズを想定していることが伺える。このファイルの [incomingtcp] のセクションに、例えば

8080 =  172.16.226.128:8080

と書けば、port foward の設定が完了である。この例では、インターネットからのポート8080へのパケットは、natdによって172...のIPアドレスを持つバーチャルマシンへと宛先を書き換えられ、転送される。逆向きのパケットも同様に処理される。

NATの設定が終了したら、ファイアーフォールの設定も忘れずに行っておく。システム環境設定から先程指定したポートを開放しておく。私は ipfw を使って、より細かく設定したファイアーウォールを敷いているので、ipfw のルールに次のような行を加えた。

ipfw add allow tcp from any to me dst-port 8080 in

これにより、インターネットからen0 を経由してOS Xに入って来るパケット（これは後にNATに拾われ、バーチャルマシンに転送される）と、バーチャルマシンからvmnet8 を経由して OS X に入ってくるパケット（後にインターネットに向けて転送される）の両方が、ポート8080に限って許可される。

括弧内に記述した、OS X から外に出て行くパケットについては、別の行で他の通信と一括して許可しているのでここでは触れない。

なお、一般的に、ipfw と nat を用いた port forward には、ipfw の divert という命令を使うことも出来るようだが、同時に実行する natd に転送先IPアドレスを指定しなければならない。VMwareの場合に出来たとしても、vmnet-natd に何らかの設定が必要になるので、手間は変わらない。私が試した通り、vmnet-natd に想定された使い方をするのが最善だろう。

追記：VMwareの新しいバージョンをインストールすると、今回変更した設定ファイル nat.conf が上書きされていた。同じディレクトリにバックアップファイルは置かれているので、アップグレードの都度、設定を復元する必要がある。

カテゴリ別一覧～ファイルシステム

私は、Blogがこんなに流行る前から、ドキュメント出版の方法として、似たような仕組みが欲しいと思っていた。私の頭にあったのは、もう少し日記色が薄いもので、
・一つの記事を複数のカテゴリに分類して自在にフィルタをかけられるもの
・その際はカテゴリ別の一覧があるもの
だった。
実現方法としては、XML文書の利用を考えていた。

Movable Typeはこの点、カテゴリの作成自体には問題ないのだが、カテゴリ別の見出し一覧というものがない。あくまで日記なのだ。時間ができたら、見出しの一覧を表示するようなカスタマイズをしてみたいと思う。

文書に複数の属性を持たせ、いろいろな属性で探す仕組み、これはデータベースの話になってしまう。
話がそれるが、私の関心は、ファイルシステムについてもいえる。フォルダによるツリー型の分類には何かと不便が多い。次期WindowsのLonghornではファイルシステムをデータベース化するらしいので、積年の希望を実現してくれるかもしれない。しかし、自分のPCで常時SQL Serverが稼働しているとすれば、気後れしてしまう。