  |
はてなキーワード: 全文検索エンジンとは
アニメやゲームのキャラクター情報をまとめてるサイトがないから作りたいなぁって
思ってたんだけどhtmlは初歩しか分からないしプログラミングもできないので構想するだけで作れなかった。
ゼロから4ヶ月でWEBサービスをリリースした人の記事を見つけて｢自分にもできるかな！｣なんて思い挑戦してみたけど理解できず挫折･･･orz
それでもWEBサイトを作りたかったので制作会社に発注してみようと思い立った。
ただのキャラクターのデータベースだけではつまらないのでコミュニティ要素なども付けて
ネットで見つけた制作会社に見積もってもらうと下記のようになった。
合計1,483,125円
以前、SNS｢ウェブカレ｣のサイト制作費が1千万円で安く仕上がった(潰れたけど･･･)という話があったから
なんとなく3～400万くらいかかるんじゃないかなと不安だったんだけど予想より安い見積もりだったので、
このくらいの金額ならなんとか出せる！ということで制作してもらうことにしました。
本当は何社かに見積もってもらって比較しようと思ったんだけど面倒だったのでそのまま制作をお願いすることにした。
（最初はもう少し高かったけど機能の簡略化とオープンソースのライブラリを使用してもらう事で費用を抑えてもらった。）
去年の10月の頭くらいから打ち合わせを始めて第1フェーズでワイヤーフレーム作成と仕様策定をして第2フェーズのhtml､システム開発に
移ったのは中旬だったかな？その段階で前金で4割の580,650円を支払いました。
制作会社には3回くらい打ち合せに行って、あとはメールでやり取りしていました。
当初は12月中にリリースを予定してたんだけど、なんだかんだで伸びてあらかた出来上がったのが2月の中旬くらい。
ちなみに僕はヒッキー(どれくらいヒッキーかというと外出は3日に1回くらい)なので制作してもらっている間は
↓作ったサイト
サーバはさくらのVPS 8Gを使用。CentOS5の64bit
設定した項目は以下のとおり
HDDが3つあって、普通に/var/wwwにコンテンツを入れていくとHDDが溢れそうだったので、容量の大きいものを使うように工夫したりなど。
メモリもそこそこ積んであるサーバなので、mysql、php、apcに多めにメモリを割り当てる設定をした。
本当は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日くらいかかった。
アクセスは、サイト全体(トータル)、サイト全体(当日分)、各コンテンツ日別、各コンテンツ週間、各コンテンツトータルのアクセスをとるようにしています。
検討した候補はmemcaced、apc、mysql、redis、fileあたりなんですが、
fileは候補にあがったものの、メンドウ、、どうせなら楽な既製品がいい。と思って候補から外しました。
残るはmysqlかredisだけど、redisが高速って聞いていたのでredisにしてみました。
最初全部redisに入れて、集計した結果をmysqlに入れるつもりでしたが、週間ランキングなどはINSERT INTO .. DUPLICATE ONを使って、
アクセスした週の月曜日00:00:00のタイムスタンプとコンテンツIDをキーにしたレコードを作ればそのまま週間ランキングになるなー。と思ってmysqlを使っています。
コンテンツのトータルアクセス数もコンテンツのレコードにpvという項目をつくってUPDATE table SET pv=pv+1 WHERE id = ? のようにしました。
最初難しく考えていたけど、こうすることによって大分楽になったなーといった感じ。
全文検索エンジンや対話検索、ここにこのリンクがあればなぁ。。という所に何とかしてリンクを作るのが本当に大変だった。
使い勝手を良くするために、ここにこの機能をなど、さくっと思いつくのは簡単でもそれを実現するために、あーでもない、こーでもないと
DB・プログラムとにらめっこしながら「あ！こうすればできる！でもそうすると今度はこっちが･･･」みたいなのがあったりでとても大変だった。
はてなの不備もあるけれど、誤解もあるようです。
まず、インクリメンタルサーチは全文検索に対応していません。
あくまで、自分がブックマークしたエントリのタイトルとURL、それに自分のブックマークコメントからだけです。
あと、遅い件はブックマーク数が関係しているかもしれません。2000も無い私の場合は至って快適です。
インクリメンタルサーチはとりあえず的で、本格的な検索は全文検索で、ということかもしれません。
そして、ユーザー毎の全文検索ですが、これ、有料オプションです。
はてなブックマークプラスで無い人は使えませんが、リンクだけは出てくるようですね。
これははてなの不備でしょう。はてなアイデアに投げれば修正されるかもしれません。
というわけで、はてなにカネ/個人情報なんか渡さない、という人はマメにコメントを残しなさい、ということかも知れません。
もしくは個人用に全文検索エンジンを立ち上げるか。最近はクラウドとかWebAPIとかWebHookとかあるんで、それらを駆使すれば意外とハードルは低いかもしれません。
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の辞書データの一部を研究に使った記憶はある。
しかし、あそこまで精緻な辞書データを使う程高度な処理は今の所必要ない。
うちで自作した不要英単語辞書と、特別扱いする英単語辞書で間に合わせていたと思います。（その辺記憶があいまい。）
djangoは非常に明快で、快適。
画面の機能を追加するのに、例えばS2Strutsのアクションの定義の煩雑さに比較すると、天と地との差ほどにdjangoは簡単。
あと、pythonを使える開発者は日本には少ないとの事ですが、うちでもそれは同様です。
しかし、自分の隣の席の同僚はperlに非常に熟達していて、彼はすぐにpythonの達人に変わりました。
優秀な方にとっては言語なんて何をつかってもあまり変わらないみたい。
