Home

12

日記
SBMをシードにした検索エンジンEdit

いつのまにかHyper Estraierにクローラーまで追加されて、Hyper EstraierだけでWeb検索システム一式そろうようになっていた。1470.netをリニューアルする際に、今度は検索周りをどういう風に作ろうかいろいろ考えていたんだけど、実はSBMで登録されたURLをシードにして、Hyper Estraierのクローラーに巡回させるだけで、十分面白いコンテンツになりそうな気がする。ブックマークすると、Hyper Estraierが関連情報を勝手に集めてきてくれる感じ。バックエンドはHyper Estraierに任せて、あとはUIに凝ればいい。個人(ローカル)でそういうシステムを動かしても便利だろうね。

Published At2006-05-29 00:00Updated At2006-05-29 00:00

日記
Zend_Db_Tableを使った場合の、DB負荷分散への対応Edit

Zend_Db_Tableを使って検索系クエリーを複数DBバックエンド(レプリケーション)に(コードレベルで)分散したい場合ってどうすればいいんだ? 一応setDefaultAdapterで適当にDB接続を切り替えてから、Zend_Db_Tableオブジェクトを生成すれば、そのオブジェクトでは生成された瞬間のZend_Db_Adapterを維持してくれるみたいだけど、複数のZend_Db_Tableオブジェクトで同じZend_Db_Adapterを使っていることを保証したりはできないよなー。更新系アプリと検索系アプリを分割し、検索系アプリでは全体で接続先を分散するようにする? あるいは基本的に接続先を分散しつつ、更新系処理を行う部分だけは明示的にマスタに接続させる? あるいはコードレベルで対応するのはあきらめて、DBレイヤーに近いところで負荷分散させる?(SQL Relayとかpgpoolとか) RoRとかではどうやっているんだろう? まだざっとしか読んでないけど、「RailsによるアジャイルWebアプリケーション開発」にはその辺ことは書いてなかったよなー。

ちなみに

DB_DataObjectでは、$do->_database_dsnをいじって、オブジェクト単位でDB接続先を変えれば、そのオブジェクトを通した処理は、すべてそのDB接続先に対する処理になるから、それで一応管理できた。Zend_Db_Tableの場合は、基本的に1テーブル単位の処理しかできないから、複数テーブルにまたがったjoin相当の処理をしたければ、複数のZend_Db_Tableオブジェクトを作る必要があり、それらが別のDBに接続されてしまうと、話がややこしくなる。っつーのをどうしようかなー、という話ね。

Published At2006-05-29 00:00Updated At2006-05-29 00:00

日記
Zend_Search_HyperEstraier設計中Edit

PEARスタイルのラッパーがあるのは知っているんだけど、Zend Frameworkスタイルで作り直し中。単なるノードAPIのラッパーはだいたいできたんで、さらにそれにかぶせるラッパーを作成中。

現状の設計だと使い勝手は、

$client = new Zend_Search_HyperEstraier_Node_Client($nodeUrl, $userName, $password);
// シンプルな検索
$searchResult = $client->search('phrase');
// 複雑な検索
$condition = $client->getCondition();
$condition->clear();
$condition->setPhrase('phrase');
$condition->addAttribute('name streq value');
$condition->setOrder('@mdate');
$searchResult = $client->search(); // or $client->search($condition);
foreach ($searchResult as $item) {
echo $item->getUri() . "\n";
foreach ($item->getAttributes() as $name => $value) {
echo "$name: $value\n";
}
echo 'Keyword: ';
foreach ($item->getKeywords() as $keyword) {
echo $keyword . ' ';
}
echo "\n";
echo $item->Snippet() . "\n";
}
// ドキュメントリストを取得
$list = $client->getDocumentList($limit);
foreach ($list as $item) {
echo $item['@uri'] . "\n";
echo $item['@cdate'] . "\n";
}
// 新規ドキュメントの登録
$document = $client->createDocument([uri]);
$document->addText('text');
$document->addAttribute('name', 'value');
$document->setKeywords(array('keyword1', 'keyword2'));
$document->save();
// 既存のドキュメントの更新
$document = $client->getDocument([document id or uri]);
$document->addText('new text line');
$document->addAttribute('name', 'value');
$document->setKeywords(array('keyword1', 'keyword2'));
$document->save();
// 既存のドキュメントの削除
$document = $client->getDocument([document id or uri]);
$document->delete();

なんて感じなんだけど、なんか末端部の扱いがこなれてなさ過ぎなんで、もうちょっと練ってみよう。あと、検索条件の設定を、Hyper Estraierのマニュアルなしでできるくらい、わかりやすくできないかなー? Estraierでもそうだったけど、高機能な分、検索条件を組み立てるのが難しい(直感的じゃない)んだよな。

あと今すぐは必要ないだろうけど、estwaverみたいにインデックスへの書き込みを複数のノードに分散させる機能を持つクライアント(Zend_Search_HyperEstraier_Node_Client_Distributedとか)も考えておこう。

Published At2006-05-31 00:00Updated At2006-05-31 00:00

12