2005年03月30日

前回のネタ続きですが、iYappoのクロウラー収集データを含めた情報をRastを用いて検索可能にしてみました。
検索例
いつの間にかLabsは携帯ユーザー含め一般解放してたりするです。
Labsもいくつかの新要素が導入されてますが、説明はそのうち・・・

データ構造は適当に設定したので見栄えが変ですが、既存のlike '%%'な検索より随分と高速になりました。
like検索といっても多段キャッシュ機構をiYappoで持っていたので意外と速かったりしますが。
クロウラーやら運用ポリシーやらを整理しなおしてから正式採用するかどうか決めようかなと思います。

なぜRastなのかというと

  • N-gram
  • サンプルスクリプトが付いてくる
  • チュートリアルが親切
  • APIリファレンスが作れらている
  • 文書属性を自由に設定でき、それらをソート対象に出来る
  • APR
    って所がポイントでした。

    特にN-gramとソートが重要でした。
    なんせ携帯サイトの文章は、わかち書きしにくい、辞書の超整備が必要なのでN-gram必須だったりするのです。
    あとソートなんかは、日付順やTF・IDFなんかよりも独自ランキングのスコアを利用しないと気持ちの良い検索結果にならないので。

    iYappoのメインエンジンをNamazuの超カスタマイズ版にしようかmysql上で実装しようか、QDBM使ってゴリゴリやろうかと、あれこれ悩んでいたのですが、ニーズにマッチした物が公開されて嬉しい限りです。


    Sennaを導入しなかった理由は、
    SennaはMysqlの全文検索機能に置き換える事が出来て、文書属性の要件を満たしそうなのですが、いかんせんMysqlって所に引っ掛かりがあって手を出してないです。
    じゃぁ、単独でAPIたたけよって話しになるのですが、そうなると文書属性がクリアされなそうなのですよ。
    むしろSennaはMysqlと組み合わせることにより真価を発揮すると見ていますが(技術分野以外を含む)
    mysqlにパッチ当てたりしないとmysql上で利用できなかったり、そもそも全文検索専用のデーモン立ち上げなきゃいけないしでややこしいから採用しなかっただけです。
    実績は十分に有るそうなので、ドキュメントが纏まってやる気が出たら手をつけるかも。

    クロウラーもPOEで構築しようと思ったXangoなんつうのもあってビックリですが、Xangoは採用しない方向です。
    もうちょっとシンプルなフレームワーク作って、それに色んな手法を乗っけようかなと。
    それらとは別に、携帯サイトに利用されるURLを良い感じに解析するモジュールとかとか。


    今回はyappodの採用は考えない方向でした。
    あまり下のレイヤに頭使いたくなかったのです。
    yappodなんかも、要件満たしてたりするんですけどねぇ。
    根本的な再設計が必要かと。

    Posted by Yappo at 2005年03月30日 22:37 | TrackBack | Yappoな事
  • Comments
    Post a comment









    Remember personal info?






    コメントを投稿する前に↓の場所にnospamと入力してください。