「全文検索エンジン」を含む日記 RSS

はてなキーワード: 全文検索エンジンとは

2012-05-06

http://anond.hatelabo.jp/20120322025117

外資系蹴って未来検索ブラジル行けよ

全文検索エンジンgroongaの開発、またはgroongaを用いたアプリケーションの開発を行っていただきます

以下の条件を満たしている必要があります

以下の技術分野に関する知識・経験があるとなお良いです。

http://razil.jp/recruit.html

英語論文が読めて、アルゴリズムについて知識がある人材求めているぞ

2012-03-18

WEBサイト発注してみた。

アニメゲームキャラクター情報をまとめてるサイトがないから作りたいなぁって

思ってたんだけどhtmlは初歩しかからないしプログラミングもできないので構想するだけで作れなかった。

ゼロから4ヶ月でWEBサービスをリリースした人の記事を見つけて「自分にもできるかな!」なんて思い挑戦してみたけど理解できず挫折・・・orz

WEBサービスを個人で作ってる人達が羨ましいです。

それでもWEBサイトを作りたかったので制作会社発注してみようと思い立った。

ただのキャラクターデータベースだけではつまらないのでコミュニティ要素なども付けて

ネットで見つけた制作会社見積もってもらうと下記のようになった。


合計1,483,125円


以前、SNSウェブカレ」のサイト制作費が1千万円で安く仕上がった(潰れたけど・・・)という話があったか

なんとなく3~400万くらいかかるんじゃないかなと不安だったんだけど予想より安い見積もりだったので、

このくらいの金額ならなんとか出せる!ということで制作してもらうことにしました。

本当は何社かに見積もってもらって比較しようと思ったんだけど面倒だったのでそのまま制作をお願いすることにした。

最初はもう少し高かったけど機能の簡略化とオープンソースライブラリを使用してもらう事で費用を抑えてもらった。)

去年の10月の頭くらいから打ち合わせを始めて第1フェーズワイヤーフレーム作成仕様策定をして第2フェーズhtmlシステム開発

移ったのは中旬だったかな?その段階で前金で4割の580,650円を支払いました。

制作会社には3回くらい打ち合せに行って、あとはメールでやり取りしていました。

当初は12月中にリリースを予定してたんだけど、なんだかんだで伸びてあらかた出来上がったのが2月中旬くらい。

見積もりがちょっと甘かったんじゃないかなぁって思うw

ちなみに僕はヒッキー(どれくらいヒッキーかというと外出は3日に1回くらい)なので制作してもらっている間は

家でずっとサイトに必要なアニメデータを収集していました。

↓作ったサイト

http://neoapo.com/


以下、サイト設計担当してくれた人の製作記。

サーバ設定

サーバさくらVPS 8Gを使用。CentOS5の64bit

設定した項目は以下のとおり

HDDが3つあって、普通に/var/wwwコンテンツを入れていくとHDDが溢れそうだったので、容量の大きいものを使うように工夫したりなど。

メモリもそこそこ積んであるサーバなので、mysqlphpapcに多めにメモリを割り当てる設定をした。

データベース

本当はmyISMやInnoDBエンジンでLIKE "%word%"のようなクエリーを投げて十分なパフォーマンスが出ればいいんですけどね。

それはムリなので、全文検索エンジンとしてgroongaを使用。

groongaを使用するために先にインストールしたのはこんな感じ

この時点でいざ、groonga!と思ってgroongaをインストールしようとすると競合を起こして入らない。

epel、remiレポジトリからインストールしてあったmysqlと衝突してたのでyum remove "mysql*"で

一旦mysqlを消して、groongaレポジトリからmysqlとgroongaをインストール

するとgroongaは入ったものの、今度はphpから使おうとしてもphp-mysqlパッケージが入らない。

あちらを立てればこちらが立たぬ状態で本当にこまった。

どうしようもないので、やりたくないけどyum-downloadonlyを使ってパッケージに含まれる設定やら、soファイルなどを直接とってきて入れた。

mysql.so、mysqli.so、pdo_mysql.soを/usr/lib64/php/modules/にコピーしたり、設定をコピーしたり、少しずついじりながら、なんとか動いてくれた。

状態としてはmysqlとgroongaはgroongaレポジトリからphpと本来php-mysqlパッケージインストールされるmysql.soは手動で置いたことになる。

シェルから直接mysqlログインするときはgroongaレポジトリのやつを、phpからmysqlを呼ぶときは手動で置いたmysql.soを使うことになっている。

ちょっと心境的にしんどい。別の方法があったかもしれないけど、調べても分からず結局1日くらいかかった。

アクセスカウンタ

アクセスは、サイト全体(トータル)、サイト全体(当日分)、各コンテンツ日別、各コンテンツ週間、各コンテンツトータルのアクセスをとるようにしています

高速だとうわさのredisアクセス回数を残しています

検討した候補はmemcaced、apcmysqlredis、fileあたりなんですが、

memcacheはサーバリスタートするとデータが消える。

apcapacheリスタートするとデータが消える。

fileは候補にあがったものの、メンドウ、、どうせなら楽な既製品がいい。と思って候補からしました。

残るはmysqlredisだけど、redisが高速って聞いていたのでredisにしてみました。

最初全部redisに入れて、集計した結果をmysqlに入れるつもりでしたが、週間ランキングなどはINSERT INTO .. DUPLICATE ONを使って、

アクセスした週の月曜日00:00:00のタイムスタンプコンテンツIDキーにしたレコードを作ればそのまま週間ランキングになるなー。と思ってmysqlを使っています

コンテンツのトータルアクセス数コンテンツレコードpvという項目をつくってUPDATE table SET pv=pv+1 WHERE id = ? のようにしました。

最初難しく考えていたけど、こうすることによって大分楽になったなーといった感じ。

まとめ

全文検索エンジンや対話検索、ここにこのリンクがあればなぁ。。という所に何とかしてリンクを作るのが本当に大変だった。

使い勝手を良くするために、ここにこの機能をなど、さくっと思いつくのは簡単でもそれを実現するために、あーでもない、こーでもないと

DBプログラムとにらめっこしながら「あ!こうすればできる!でもそうすると今度はこっちが・・・」みたいなのがあったりでとても大変だった。

そんなに機能がないような感じがしても、このサイトだけでテーブルが20個あって、途中本当に死にそうだった。

2009-08-20

http://anond.hatelabo.jp/20090820185042

はてなの不備もあるけれど、誤解もあるようです。

まず、インクリメンタルサーチ全文検索に対応していません。

あくまで、自分ブックマークしたエントリタイトルURL、それに自分ブックマークコメントからだけです。

あと、遅い件はブックマーク数が関係しているかもしれません。2000も無い私の場合は至って快適です。

インクリメンタルサーチはとりあえず的で、本格的な検索全文検索で、ということかもしれません。

そして、ユーザー毎の全文検索ですが、これ、有料オプションです。

はてなブックマークプラスで無い人は使えませんが、リンクだけは出てくるようですね。

これははてなの不備でしょう。はてなアイデアに投げれば修正されるかもしれません。

というわけで、はてなにカネ/個人情報なんか渡さない、という人はマメにコメントを残しなさい、ということかも知れません。

もしくは個人用に全文検索エンジンを立ち上げるか。最近クラウドとかWebAPIとかWebHookとかあるんで、それらを駆使すれば意外とハードルは低いかもしれません。

2009-03-30

自然言語処理Python がいちばん」について

http://d.hatena.ne.jp/mamoruk/20090327/p1

「いちばん」かどうかはわかりませんが、うちの会社製品ではpythonを主力に使った自然言語処理を含む製品を販売しているので、実際の感想を。

うちでは、pythonを元データの整備のための運用バッチ処理から、客が最終的に手にする情報の生成、実際に客が使うWEBインターフェースまで、pythonを主力にしています。

別のチームが作った別の製品ではS2Struts(JAVAね。)でWEBを作っている部分もありますが。

自然言語処理ぶっちゃけどの言語でも可能だとは思います。

mecabが使えて、Unicodeが使えて、正規表現が使えれば、まあ、どの言語を使ってもそんなに大差はないのではないでしょうか。

あとはsennaのような日本語用の全文検索エンジンなども使いますが、そこらへんに近い部分は基本的にC++で書きます。

pythonとは言っても、速度を重視する部分はやはり迷わずC++です。

C++で書いたものはswigを使うか、又はC言語で手書きのbindingを使ってpython接続します。

もこないだswigでつないで製品リリースしたら、WEBからの並列アクセスswigがうまく対応できず、リリースした日に急いで手書きbindingを書いた経験があります。swigの使い方はきちんと理解していないので非常に難しい。

nltkとか、wordnetの話はたしかに使えそうかもと思ったことはありますが、nltkはうちでは使っていません。

うちの会社では自然言語処理研究段階から自社で行っているので、nltkにあるようなできあいのルーチンを実戦投入する事はなく、基本的に地味に自分達でpythonで書いています。

自然言語処理と言っても、核心の処理はやはり泥臭い個別事例への対処が多いです。不要語処理とか。

自然言語処理アルゴリズムは8割程度の精度を出すのは簡単で、すぐに思いつきで書けるものですが、残り2割の精度をいかに埋めて行くかが、頭のいい人とそうでない人の差が現れる部分だと思います。

どうしてもいいアルゴリズムを思いつかない場合は、泥臭い個別事例処理がうねうねと並んだプログラムになります。学術的なものではなく商売になればいいので、うちはとりあえずそれで十分。(これは自然言語処理に使う機械学習アルゴリズムたちも同様。というか自然言語処理機械学習て、区分けがあいまいな部分が多いですよね。)

そういう感じなので、pythonの可読性の高さは非常に有効。

また、変数名や関数名などをexplicitに書く文化も業務で使うのに適していると思います。(他の言語でもexplicitに書けばいいだけですが、それを言語開発者自身が推奨するほど強調はしていないですよね。)

英文の処理で、wordnet辞書データの一部を研究に使った記憶はある。

しかし、あそこまで精緻辞書データを使う程高度な処理は今の所必要ない。

うちで自作した不要英単語辞書と、特別扱いする英単語辞書で間に合わせていたと思います。(その辺記憶あいまい。)

WEBユーザーインターフェースdjangoで。

djangoは非常に明快で、快適。

画面の機能を追加するのに、例えばS2Strutsアクション定義の煩雑さに比較すると、天と地との差ほどにdjangoは簡単。

あと、pythonを使える開発者日本には少ないとの事ですが、うちでもそれは同様です。

しかし、自分の隣の席の同僚はperlに非常に熟達していて、彼はすぐにpythonの達人に変わりました。

優秀な方にとっては言語なんて何をつかってもあまり変わらないみたい。

でも、彼も自分自然言語処理JAVAC++のようなまわりくどい言語は使ってられないという点では同意しています。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん