« 2007年12月 | メイン | 2008年3月 »

2008年1月22日

データを全てファイル名に!?

カテゴリー: [ソフトウェア] [プログラミング]

スラドで見つけたんで、知っている人も多いでしょうけど。

スラッシュドット ジャパン | データをすべてファイル名扱いにして高速検索を実現?
HOWS「ISSEI(イッセイ)」:ITpro

既存のRDBの限界を超える、高速検索が出来るようにデータの全てをファイル名に入れる事にした検索技術を作ったというものです。OSの機能で高速検索できると主張しているわけですが。

最初は、何か利点になるポイントがあるんだと思って読んでいったんですが...
つっこみどころが満載で、どこからつっこんでいいやら困ってしまいます。ジョーク記事かと思いました。

すくなくとも、解説を読む限りはつっこみどころ満載です。
世の中、解説だけがでたらめということはあるので。(これがそれだけの話とは正直思えないですが)

とりあえず、他の人たちもつっこんでいるように、「ストップウオッチ片手に高速化を追求」というところは、つっこんでおかないといけないでしょうね。なぜストップウオッチ…

OSの基本機能であるファイル名の検索機能を用いることで、ハードディスク内のファイル本体にアクセスせず高速に検索できるのが特徴だ

HOWS「ISSEI(イッセイ)」:ITpro

ファイル名の情報も、ハードディスク上にあると思うのは私の勘違いなのでしょうか?
なにか、ファイル名を取ってくるのは、どんなときでも高速であるという思いこみがあるような気がします。

そもそもファイル検索機能というのが何をさすのか、よくわからないのですが、Windowsのファイル検索のことなんでしょうか。
あれだって高速化するには、インデックスつけたりするわけでDBと同じ事なんですが。
つまり、結局、Windowsのファイル検索は速いよ、ということですか。

検索対象は、このファイル名の集合体。この方法によって、ハードディスクに保存されているファイル本体にアクセスすることなく、メモリーにキャッシュされたファイル名群を検索することで高速化を図っている。

なるほど。メモリに持っておくから速いんですね。
でも、ファイル名としてデータを保存するから速いんではなかったんでしたっけ?
結局、ファイル検索ってなに…?キャッシュとは普通のディスクキャッシュのことなんでしょうか?
それこそ、単にOSの機能では?

従来のDBは、

「ファイルの入出力にかかる時間がボトルネックで、検索速度が上がらないとの問題を抱えていた」
というんですが、そこから、なぜ、ファイルの中身を読まずにファイル名だけ読めばよいという発想に至るのかよくわかりません。ファイル作成や、ファイル名の取得はボトルネックにならないと思ったのでしょうか?
そもそも、そのボトルネックはどうやって調べたんでしょうか。(ストップウオッチ?)

次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。最終的にはISSEI専用チップをメーカーと開発するのが目標だ

OSの機能をそのまま借りるのが利点だという主張なのに、なぜ専用チップですか。
これは、他と比べて、非常にわかりやすいつっこみどころですね。

このままつっこみ続けると、全文引用してしまいそうなのでこの辺で。
「ゼロベースで発想」したそうですが、どういう意味でゼロだったのか…

ファイル名にプログラムから利用される何らかの情報を持たせるということは、普通にあります。有効な場面もあるでしょう。
でも、そういうのは、62進数で全部のデータをファイル名に入れるとか言う話とは違う話ですし、新技術とか言うものではありません。

とにかく、この技術がたとえ本当に速かったとしても、すごいのはMicrosoftなわけです。
ファイルシステム、ファイル検索といった、「既存のDB」を使っているだけなのですから。

書くべきか迷いましたが、あんまりな話なので書かずにいられなかったです。
なんというか、トホホな話です…

追記:
改めて、何に違和感があるのか考えてみると、引っかかっているのは単に技術的に変とかいうことではないんですよね。
自分はそこに着目しがちですが、記事だけでは詳細まではわかりませんし。
まあ、記事の書き方自体がなにか変なのは確かですが…
用途は限られるでしょうけど、ファイル検索機能に検索させるということ自体は、(もしかしたら)状況によっては意味があるかもしれない。
(Google Desktop Searchとかの方がいい気はしますが)
でも、新技術とか、既存のDB技術と一線を画すとか、革新的とかいう話じゃない。(一番大事なところが借り物)
そこのところに引っかかるんでしょう。

投稿者 shingo : 01:16 | コメント (2) | トラックバック

2008年1月20日

RAID(mdadm)のメモ

カテゴリー: [Linux]

先日、LinuxサーバのHDD交換をしたわけですが、その後、24時間しない内に原因不明のフリーズに陥りました。
仕方ないので強制的に再起動しましたが、結局原因がわからないのでちょっと不安。
ハードウェア的にもソフトウェア的にもいろいろ変更したわけで、思い当たるところがありすぎです。

さて、HDD交換のついでにRAID1を組んだわけですが、そのときの操作をメモを兼ねて書いておくことにします。

mdadmによるRAIDの構築方法は簡単に見つかりますが、はまったのがセットアップ中に一度停止させたRAIDアレイをmdadmで再編成する方法。

RAID構築後に、以下のように、一度RAIDを停止させた場合。

# mdadm -S /dev/md1

次に、再びRAIDとして編成するときにどうするか。
ちゃんと調べないで停止させてしまったので、あわてて調べる羽目に。

最初は、こうやりましたが、うまく行きません。

# mdadm -A /dev/md1

/dev/md1 は編成されたRAIDアレイが使うデバイス名ですが、そのアレイの構成要素となるデバイス(/dev/hda1など)を識別する情報がないということなんでしょう。

結局、以下のようにして、まず、RAIDアレイのUUIDを調べ、

# mdadm -E /dev/hda1

その後、そのUUIDを指定して、一つ一つ編成しました。

# mdadm -A /dev/md1 -u xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx

ここまでが、実際の作業で使った方法。

結局、後で調べたらもっとやりやすい方法があったわけです。
まず、/etc/mdadm.conf に以下のように、RAIDアレイを探す対象のデバイスを書きます

DEVICE /dev/hda* /dev/hdb* /dev/hdc* /dev/hdd*

そして、以下を実行すると、既存のRAIDアレイを編成するのに必要な情報が出てきます。

# mdadm -E --scan
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx

これは、そのままmdadm.confで使える形式なので、以下のように/etc/mdadm.conf に追記します。

# mdadm -E --scan >> /etc/mdadm.conf

この後、以下のようにすれば、既存のRAIDアレイが編成されます。

# mdadm -A --scan

ただ、このやり方は実際には試せてないんですが…


ここまではソフトウェア的な話ですが、ここからはハードウェア的な話。

ミラーリングなのでHDDを2台つなぐわけですがが、HDDを両方ともATA100のプライマリチャネルにつなぎました。
1つのチャネルにミラーリングしているHDDを2つつなげるのはなんとなく遅いような気がしましたが、
手持ちのケーブルの長さが足りないので仕方ありません。

DVD-ROMドライブがケースの上の方に、HDD2台が下の方についてるんで、DVD-ROMとHDDを1つのケーブルのマスターとスレーブにするには、一度ケースの上の方のDVD-ROMドライブにつなげた後、下の方にあるHDDまで降りてこないといけません。
まあ、HDDの取り付け位置をDVD-ROMの近くにすればいいんでしょうけど、冷却の都合もあるわけで。
(そもそも、SATAにすればいいと言う話もあるわけですが(^^;)

でも、マスターとスレーブの間の長さは、15cmのものがほとんどです。
全体もやたら長いものの、マスターとスレーブの間が30cmのケーブルを見つけることが出来たので、つなぎ変えてみました。

さて、これで速度に変化はあるのか。
接続を変更する前後で、bonnie++というソフトを使って、計測しました。
Gentoo では、

emerge bonnie++

でインストールできます。
以下のようにすれば計測できます。
キャッシュやバッファの影響を避けるために、実メモリの2倍のサイズのファイルを作るので、十分な空き容量が必要です。

/usr/sbin/bonnie++ -d (ディレクトリ名)

rootで実行すると警告が出るので、root以外のユーザで実行します。

で、計測してみたんですが、正直あんまり変わってない感じです(^^;
まあ、そんなものでしょう。あんまり、こだわるところではなかったのかもしれません。

今回、RAIDを構築した後で、RAIDを構成するHDDの接続場所を変えてしまいましたが、起動時にRAIDを構成するデバイスを探しに行きますので、問題は起きません。
ただ、mdの初期化時にデバイスが存在しないとまずいので、USBとかでつなぐとだめなようです。

投稿者 shingo : 23:16 | コメント (1) | トラックバック

2008年1月15日

HDD入れ替えとLVMの導入

カテゴリー: [Linux] [blog] [自宅サーバ]

自宅のサーバが、そろそろ稼働開始から3年くらいになり、HDDが心配なのとパーティションのサイズに問題が出てきて不自由になってきたので、思い切ってHDDを入れ替え、LVM(Logical Volumn Manager)での管理に変更することにしました。
ついでなので、ソフトウェアRAIDで、RAID1にすることに。

まず、今のケースでは小さすぎてHDDが2台のらないので、入れ替え。

Gentooのinstallcdをつかって起動し、古いHDDをUSB経由で接続して、作業開始。
経験上、Gentooのinstallcdは、USBのHDDでも簡単につながるので便利です。

LVMにしない(できない) /bootとrootパーティションは、同じサイズのRAID1のパーティションを作ってddでコピー、のつもりがミスで少し小さいサイズになってしまって失敗。

よく考えてみれば当たり前で、/dev/hda1と/dev/hdb1 を束ねて/dev/md1 を作るとき、/dev/hda1と/dev/hdb1 を古いパーティションと同じサイズにしても、先頭にスーパーブロックが書き込まれるから、その分減るわけです。なので、普通にファイルをコピー。

その他のパーティションは、LVMで作るので、LVM用のRAID1のパーティションを作り、それをVolume Groupに追加。そこから切り出して、以前のシステムのパーティションに相当するLogical Volumeを作っていきました。
各Logical Volumeは、前のサイズよりは、少し大きめになるように取っていきました。
そして、作ったLVに、元のHDDからddでデータをファイルシステムごとコピーし、

resize2fs /dev/(Volume Gruop名)/(Logical Volume名)

で、LVのサイズいっぱいに拡張して、コピー終了。
ただ、コピーにけっこう時間がかかりました。
普通にファイルシステム作ってから、そこにコピーした方がよかったか…

作業をしていると、祖母から電話がかかってきました。
IP電話が止まっているので、変だと思ったようです。
こいつが、ルータになっているのをすっかり忘れてました。

最後の仕上げに、/etc/fstab のデバイス名を新しいRAID1とLVMのデバイス名に変更、/etc/mdadm.conf を追加、grubのrootパーティションのデバイス名を新しいものに変更して新しいHDDにgrubをインストールしました。
その後、全てのボリュームをumount、LVMとRAIDを停止して、リブートし、やっと稼働し始めました。
(ちなみに、カーネルはあらかじめLVMとRAIDを追加して再構築してありました)

結局、12時間くらいかかりました。
コピーに時間がかかったのと、コピーの間、別の用をしていたのが大きかったような。
そもそも、最初にケースを入れ替える作業があったわけで。

とりあえず、順調に動いている模様です。

記録の意味でも、後でやったことをちゃんとまとめたいですね。(後でというとやらない予感…)

余談:

その後、ついでなので、放置していたblogのメンテナンスをしていたら、なんと知り合いからのコメントまで、スパムフィルタが拒否していたことが発覚。
ブラックリストの zen.spamhaus.org に基づいて、拒否してしまったようで。
apacheで拒否するようになる前だったので、コメント自体は残っていたため復活させました。
このブラックリストは、どうやらまずいみたいです。
前のエントリでやったapacheの段階でスパムを拒否する設定から、このブラックリストは外しました。
そもそも、Movable Type側のスパムフィルタからも外しました。危険です。

投稿者 shingo : 02:00 | コメント (0) | トラックバック