Ariel Area Blogs

2007・02・28

全文検索エンジンFreyaSXについて(2回目)

12月1日の書き込みに対する続きですですが、最初から全部載せます。

全文検索エンジンFreyaSXについて

1. FreyaSXについて
==================

FreyaSX は Freya をベースに開発された全文検索エンジンで、産業技術総合研究所において、DeleGateの作者の佐藤豊さんという方が開発しています。Freya は、原田昌紀さんという方が開発された全文検索エンジンです。FreyaSXのサイトのURIは、下記になります。

http://www.delegate.org/freyasx/index-ja.html

"Freya"のサイトは下記になります。

http://www.ingrid.org/ja/project/freya/

2. redhat9での使用手順
======================

下記のファイルをダウンロードします。
ftp://ftp.delegate.org/pub/freyasx/freyasx.tar.gz

解凍、展開します。

# gunzip freyasx.tar.gz
# tar xvf freyasx.tar

下記のディレクトリ及びファイルが展開されます。

freyasx/INSTALL.sh
freyasx/test/
freyasx/test/fhttpd.conf
freyasx/test/index.shtml
freyasx/test/any2fdif.conf
freyasx/delegate8.9.7-pre1.tar.gz
freyasx/freyasx-0.99.10.tar.gz

INSTALL.shを実行します。

# cd freyasx
# ./INSTALL.sh

INSTALL.shを実行すると下記のメッセージが表示されます。

////////////////////////////////////////////////////////////////////
FreyaSX installer
FreyaSX ver. 0.99.10
DeleGate ver. 8.9.7-pre1
September 20, 2004, Yutaka Sato
////////////////////////////////////////////////////////////////////

Detailed log is put into "INSTALL.log"

extracting FreyaSX-0.99.10 ...

making FreyaSX-0.99.10 ...

extracting DeleGate/8.9.7-pre1 ...

making DeleGate/8.9.7-pre1 ...

Installing to here: /root/freyasx
/root/freyasx/bin
/root/freyasx/etc
/root/freyasx/cgi-bin
/root/freyasx/bank

0) You can remove following unnecessary files:

rm -r /root/freyasx/delegate8.9.7-pre1
rm -r /root/freyasx/freyasx-0.99.10
rm -r /root/freyasx/INSTALL.log

1) Complete the installation and setup your environmnet as follows:

export FSXHOME=/root/freyasx
export PATH="$FSXHOME/bin:$PATH"

2) Then, you can test it as follows:

findex sx
fsearch sx "freya*"
any2fdif -r http://www.delegate.org/freyasx | findex sx
any2fdif -r $HOME/Mail | findex mail

3) Also you can start HTTP server for this FreyaSX and test it:

fhttpd -P8880
... then open URL "http://localhost.localdomain:8880/test" in your WWW browser
See http://www.delegate.org/freyasx/ for more details
////////////////////////////////////////////////////////////////////

FreyaSX ver. 0.99.10とDeleGate ver. 8.9.7-pre1がインストールされます。DeleGateは、プロキシサーバです。Delegateについては、下記のページが分かりやすかったです。

http://masui.net/FreeBSD/step2/chap10.html

上記メッセージに従って環境変数の設定を行います。
上記メッセージにはありませんが、DGROOTの値も設定しておきます。DGROOTは、Delegateのホームディレクトリになります。
.bash_profileに追加します。

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi

# User specific environment and startup programs
DGROOT=/home/fukushima/freyasx/
FSXHOME=/fukushima/freyasx
PATH=$PATH:$HOME/bin:$FSXHOME/bin
BASH_ENV=$HOME/.bashrc
USERNAME="root"

export USERNAME BASH_ENV PATH FSXHOME DGROOT

.bash_profileを再読み込みします。

# source .bash_profile

次に索引の作成を行います。
findexが、索引を作成するコマンドです。
any2fdifは、findexが受け付けるfdif形式にファイルを変換するコマンドです。
sxという索引については、INSTALL.shによって既に作成されているので、findexコマンドを実行しなくても、fsearch sx "freya*"で検索できます。

試しに、aironeのデータ保存フォルダに対して、索引を作成します。最新版のaironeのデータ保存フォルダは暗号化されているので、とりあえず、v1.0のデータ保存フォルダを使用します。

# any2fdif -r 1 | findex airone

freyasxは、検索を実行するCGIが用意されているので、このCGIを利用して、検索を実行しています。
fhttpdを起動します。

[fukushima@localhost fukushima]$ fhttpd -P8880
[2465] -P8880 READY
DGROOT=/home/fukushima/freyasx
ADMIN=you@your.domain
AIST-Product-ID: 2000-ETL-198715-01, H14PRO-049, H15PRO-165
Copyright (c) 1994-2000 Yutaka Sato and ETL,AIST,MITI
Copyright (c) 2001-2004 National Institute of Advanced Industrial Science and Te
chnology (AIST)

ブラウザを起動し、下記のURIを指定します。
IPアドレスは環境に合わせてください）

http://192.168.0.152:8880/cgi-bin/fsearch.cgi?pfx=ja&index=airone&sort=date&key=fukushima*

（次回に続く）

2007 02 28 21:34 - fukushima - トラックバック(DISALLOWED (TrackBack))

2005・12・27

移動しました

http://dev.ariel-networks.com/Members
or
http://dev.ariel-networks.com/Members/inoue
です。

過去のblogは削除しないので、リンクは自由にしてください。

2005 12 27 23:29 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・20

EoE

EoE (Ethernet over Ethernet)
http://itpro.nikkeibp.co.jp/article/COLUMN/20051216/226378/

誰かから口頭で聞いていたら、冗談だと思って聞き流したと思います。
Ethernetによる本格的なルーティングが行われても、不思議ではない世の中です。

TCP/IPをC言語に例えると、一部アセンブラで書いてチューニングしました、の印象です(この観点では、MPLSにも似た匂いを感じます)。

2005 12 20 00:32 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・19

メンテナンスなどなど

メンテナンス+サーバシステムの移行を12/26にします。なので、その日はサーバがよく止まります。
ついでに、ブログなどのURLも変わります。過去のブログのデータは参照だけになります。

2005 12 19 11:46 - ohtani - トラックバック(DISALLOWED (TrackBack))

2005・12・18

ジングルベル from Google (libjingle)

Libjingle - Google Talk Voice and P2P Interoperability Library
http://code.google.com/apis/talk/index.html

P2Pと言っても、いわゆる多ノード協調環境としてのP2Pではなく、NATを越えてPeer間の1対1のセッションを確立する機能を提供するライブラリです。このライブラリで、WinnyやWinMXがすぐに作れるわけではありません。
ダウンロードして少しソースを見てみました。

ライセンスはBSD系ライセンス
言語はC++です。サイズは、.hと.ccを合わせて3万行強(exampleコードとthird_partyのlibaudioコードは除く)
STLを使っています。テンプレートばりばりのコードではありません。
クラス名とメソッド名はらくだ式、変数はへび式とらくだ式が混在(モジュールごとに作者が違うせい?)。
XMLパーサはexpatをクラスでラップしています(*1)
sigslotを使っています(*2)。コードは、かなりsigslotに依存していそうです。
Boostのscoped_ptrを使っています(Boostには非依存です。scoped_ptrのヘッダだけ取り込んでいます)。
通信プロトコルは、XMPPの拡張(Jingle)です。

(*1)(expatはAirOneでも使っている、高速XMLパーサです)
(*2)sigslotはイベントドリブン的なコードを書くためのライブラリです。イベントループを持たないので、イベントと言うよりフックと言った方が適切かもしれません。作者は女性です。

2005 12 18 01:50 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・16

「なるほどナットク! P2Pがわかる本」を読みました

岩田さんの「なるほどナットク! P2Pがわかる本」を読みました。
http://sats.zekku.com/daylist_html?year=2005&month=10&day=20

だいぶ前から机の上に積んであった気がしますが、ようやく読みました。(おそらく)2年以上積んであった「イノベーションのジレンマ」に比べると、だいぶ速いので許してください。

良い点:
こういう概論的な本では、

言葉の定義(言葉と意味の対応)が明確であること
言葉の使い方が一貫していること
上の対応が作る概念体系に矛盾が無いこと

が重要で、ここらに問題があると読んでいて頭に来ますが、この本はきちんとしています。さすが岩田さん、エックスアリエルです。

悪い点:
1.
暗号化に対する「復号」が、「複合」になっています。一箇所だけのtypoではなく、全編に渡ってtypoしています。

2.
p168の「電子証明書と秘密鍵の管理」はいまいちです。アリエル社内でも誤解している人がいるので、アリエルエリアに記事を書きました。
「証明書と鍵に関する、ありがちなメタファーとありがちな間違い」
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=60
# 書いて思いましたが、誤ったメタファーに、メタファーで対抗するのは間違いかもしれません。

3.
前書きで井上に対する謝辞が無い(第二版に期待...)。

項目の量だけ見ると、悪い点の方が多いですが、良い本なので勘違いしないようにしてください。

2005 12 16 03:54 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・09

地獄のペアプログラミング

今日、拘束14時間、約12時間のペアプログラミングをしました。嫌い嫌い大好きXPって感じです。

端で見ているから他人のミスに気づくという側面もありますが、辛口ながら、ミスの多さは偶然では無いと思いました。以下、少し愚痴っぽい話ですが、プログラミングの基本的な部分を含んでいるので書きます。
# 以下の例で命名が甘いですが、そこは論点では無いので無視してください。

データ構造への視点が甘い

「データ構造」と言っても、高度な話ではありません。非常に基本的な話です。
簡単に言うと、Cで書くと
struct foo_t {
int x;
int y;
} foo[N];
のようなデータ構造であるべきものを、次のように書いていました。
int arr_x[N];
int arr_y[N];

要は、構造体の配列であるべきところが、複数の配列になっています。

配列arr_xと配列arr_yが(暗黙に)関係しています。結果として、これらを参照するコードは次のようになります。
for (i = 0; i < N; i++) {
int x = arr_x[i];
int y = arr_y[i];
// xとyはペアで使われる
}

以前、プロのプログラマ歴20年以上の人がこんなコードを書いたので、速攻で直させました。例え、動いたとしても、こんなコードは、存在そのものが許せません。

今日は諸般の事情により放置されました... (言語がPerlだったというのも理由のひとつです。Cだったら10分で書き直すのですが、Perlのリファレンスとハッシュのコードを10分で書き直す自信がありませんでした。会社に戻ったら、隣の凄い人にバカにされそうです)

フラグの直交性への視点が甘い

フラグ変数が多すぎる、という問題もありますが、実はぼく自身もフラグ変数を結構使うのであまり人のことは言えません。
しかし、フラグの直交性には気を使います。ここでのフラグの直交性を簡単に説明すると、次のような話です。フラグ変数a,b,cと3つあった時、フラグcに「aかつb」の意味しか無い時、フラグ変数cの存在を許してはいけません。途中でフラグの意味が変わって、気づいたらフラグ変数cの意味がそうなっていた時も、即刻フラグ変数cを削除すべきです。
cの部分の記述性を明示したいなら、ぼくなら、次のようなマクロでCの部分の記述性を明確化します(Perlなら、まあ関数にでもするのでしょう)。
#define IS_C(conf) ((conf)->is_a && (conf)->is_b)

呼ぶ-呼ばれる関係への視点が甘い

「呼ぶ-呼ばれる関係」はぼくの用語ですが、雰囲気で察してください。
コードに問題がある時、呼ぶ側の問題なのか呼ばれる側の問題なのかの区別をすることは重要です。この区別を素早く行うためには、呼ぶ側と呼ばれる側を切り離す「感覚」が必要です。
今日のペアプログラミングで、呼び出す外部コマンドが未実装、という状況でした。切り離す感覚があれば、とりあえず何もしない(キックされたことだけが分かる)ダミーの外部コマンドを用意して、あると仮定してテストはできます。外部コマンドでも関数呼び出しでも同じようなものです。今風のモックオブジェクトという用語もありますが、頭での理解より、切り離すと言うか突き放すと言うか、そういう感覚が先です。
このような切り離す感覚があれば、呼ばれる側だけの単体テスト、呼ぶ側だけの単体テスト、と小さな部品ごとの動作確認の意識にもつながります。今風にユニットテストと言う用語もありますが、これも頭での理解の前に、区切って隔離するとでも言うべき、感覚の方が先です。

その他

printfデバッグもバカにしたものではありません

1分でprintfが書けるなら、コードを見てなぜ動かないのか考えているより、たぶん解決は速いです。

気になることはコードに書いておきます

コードを見ていると、気になる部分が見つかります。一瞬で直せれば直しますが、後で良さそうなものは、コードにコメントでメモっておきます。BSD系の伝統に従い、ぼくはXXXコメントと呼んでいます。気になる部分の多いコードだと、あちこちにXXXマークがつきます。本を読んでいて、気になるページにしおりをはさんだり、メモを書いたりする感覚に近いです。

2005 12 09 03:19 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・08

BPなんとか

http://www.jsys-products.com/iwaken/index.html
から
http://www.jsys-products.com/iwaken/bpmn/pub/Modeling_Forum_2005.pdf
の44ページ。

BPMI (Business Process Management Initiative)の標準BPMスタックには、
BPMN、BPSM、BPXL、BPEL、BPQL
があります。これらはWS-なんとか、の上に位置するようです。
全然分からないので、今度、ワークスの人に教えてもらいます。

誰か、BPMNでソフトウェア開発プロセスを記述してください。

参考: @ITの連載記事
http://www.atmarkit.co.jp/farc/rensai/bpmn01/bpmn01.html

2005 12 08 03:24 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・02

ワークス、アリエル共同勉強会の資料を公開しました

http://dev.ariel-networks.com/modules/xfsection/index.php?category=14

第1回目は、須崎さんがAJAXの講師をしてくれました。
須崎さんと言えば、知る人ぞ知る、2004/12/9にAJAX的方法論に言及していた人です。ちなみに、AJAXという言葉が生まれたのは、2005/2/18です。

外人が言うとそれに合わせて一緒に語り出す、その辺の日本人とは格が違います。日本シリーズの先発とアジアシリーズの先発ぐらい格が違います。

2005 12 02 16:03 - inoue - トラックバック(DISALLOWED (TrackBack))

2005・12・01

排他制御のパフォーマンス

aprのprimitiveな排他制御のパフォーマンスを調べてみました。
やっていることは単純で、lock、unlockを次のようにひたすらループで回すだけです。

#define NUM_LOOP 10000000
now = apr_time_now();
for (i = 0; i < NUM_LOOP; i++) {
apr_thread_mutex_lock(mutex);
apr_thread_mutex_unlock(mutex);
}
printf("mutex: %" APR_INT64_T_FMT "\n", apr_time_now() - now - nop);

nopは、あらかじめ何もしないループを回した時の計測時間です。
APR_INT64_T_FMTの部分は、GNU/Linuxではlld、WindowsではI64dに置き換わるマクロです(64bit整数のprintf用書式指定にプラットフォーム依存があるためのマクロです)。

普通のmutexとread-write lockをGNU/Linuxで計測したことはあったのですが、今回、次のふたつを初めてやりました。

Windowsでの計測
atomic APIの計測

atomic APIは、apacheのパフォーマンスチューニングで紹介されているAPIです。
Windowsでは、InterlockedIncrement()などのAPIのラッパーになっています。
GNU/Linux(x86)では、次のようなアセンブラに展開されるマクロになっています。

#define apr_atomic_cas(mem,with,cmp) \
({ apr_atomic_t prev; \
asm volatile ("lock; cmpxchgl %1, %2" \
: "=a" (prev) \
: "r" (with), "m" (*(mem)), "0"(cmp) \
: "memory"); \
prev;})

何回か実行しておかしな変動要因が無いことを確認した結果、次のような数値になりました。細かい数値はあまり意味がありません。桁だけの世界です。
CPUの性能が低すぎて書き間違いではないかと思われるかもしれませんが、事実です。
aprの排他制御系のAPIは、OSのAPIのthinラッパーなので、GNU/Linuxの場合はpthread系API、Windowsの場合はWin32 APIそのものと思っても大きな誤差はありません。

計測項目:

mutex(unnested): nestを許さないmutex lock
mutex(nested): nestを許す、つまり同一スレッドが連続してlockを呼んでもブロックしないmutex lock
rwlock(write lock): read-write lockのwrite lock
rwlock(read lock): read-write lockのread lock
atomic(add): atomic APIのaddオペレーション

GNU/Linux (Debian sarge、Linux 2.4.30、libc 2.3.2、Athlon 650MHz):

mutex(unnested) ... 約2600000マイクロ秒/1千万回 ...1回あたり約0.25マイクロ秒
mutex(nested) ...約5600000マイクロ秒/1千万回 ...1回あたり約0.56マイクロ秒
rwlock(write lock) ... 約4300000マイクロ秒/1千万回 ...1回あたり約0.43マイクロ秒
rwlock(read lock) ... 約5800000マイクロ秒/1千万回 ...1回あたり約0.58マイクロ秒
atomic(add) ...約460000マイクロ秒/1千万回 ...1回あたり約0.046マイクロ秒

Windows (Windows2000 SP4、Athlon 1.1GHz):

mutex(unnested) ... 約12000000マイクロ秒/1千万回 ...1回あたり約1.20マイクロ秒
mutex(nested) ...約700000マイクロ秒/1千万回 ...1回あたり約0.07マイクロ秒
rwlock(write lock) ...約12200000マイクロ秒/1千万回 ...1回あたり約1.22マイクロ秒
rwlock(read lock) ...約41100000マイクロ秒/1千万回 ...1回あたり約4.11マイクロ秒
atomic(add) ...約90000マイクロ秒/1千万回 ...1回あたり約0.009マイクロ秒

新しい発見。
GNU/Linuxでnested mutexの方が遅いので、Windowsでも同じだと思っていました。事実は、Windowsではnestedを許すmutexの方が速いです。

atomicオペレーションは圧倒的に速いのでatomicで置き換えられる箇所はmutex lockから置き換えたいです。実際は変数ひとつを守るだけのmutex lockはあまり無いですが。

2005 12 01 03:03 - inoue - トラックバック(DISALLOWED (TrackBack))