solrで日本語検索

前回の記事で日本語の形態素解析ができるようになったけど、
今のままでは肝心の日本語検索ができない！！ファック！！
ということで、日本語でも検索できるように設定してやる必要があります。

server.xmlの編集

server.xmlを以下のように修正する。

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

↓↓↓

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" 
    redirectPort="8443" useBodyEncodingForURI="true" URIEncoding="UTF-8"/>

文字コードフィルタの設定

リクエストの文字コードはUTF-8にしてやる必要があるようです。
web.xmlのフィルタで設定してやればリクエストを一括でエンコードしてくれるのでそれでやっちゃいましょう。

※以下の例はSeasarを利用してる場合です。

    <filter>
        <filter-name>encodingfilter</filter-name>
        <filter-class>org.seasar.extension.filter.EncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
        </init-param>
    </filter>

・・・

    <filter-mapping>
        <filter-name>encodingfilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping> 

注意として、 上記のフィルタはSolrRequestFilterより上に書くこと。 SeasarとかStrutsを使ってない人は、自分でフィルタのクラスを作って設定してあげてください。

solrに形態素解析senの導入

Solrには日本語の形態素解析器が含まれてないので、
仕方がないからその導入手順を書いちゃうハメになってます。
そもそも形態素解析が何？って人は調べてください。

Senのダウンロード

https://sen.dev.java.net/servlets/ProjectDocumentList?folderID=755&expandFolder=755&folderID=0
からsen-1.2.2.1をダウンロードして任意の場所(以後$SENとする)に解凍する。

Antのインストール

Senを解凍してもそのままじゃ使えない？くて辞書をビルドする必要があるようです。
ビルドするにはAntがいるので、下記からダウンロードして任意の場所(以後$ANTとする)に解凍する。
http://ant.apache.org/

次にAntを実行するために$ANT/binにパスを通す。
ここら辺はJAVAとかで色々やったと思うので省略。

ちゃんとパスが通ったかどうかはコマンドプロンプトから、
ant -versionと打てば確認できる。

Senの辞書をビルド

以上の設定が終わったら辞書ディレクトリに移動してビルドを行う。

cd $SEN/dic
ant

"BUILD SUCCESSFUL"と表示されたら正常にビルドができたことになる。
けど、"BUILD FAILED"になった場合はperlのパスを確認する。

$PERL/binがパスに設定されていない場合は、パスを通すか、
antの実行時にオプションとして、

ant -Dperl.bin=$PERL\bin/perl

としてやればいい。

Jarの追加

ビルドした$SENディレクトリをプロジェクト直下に移動。
また、$SEN内にあるlucene-ja.jarとsen.jarをプロジェクトのWEB-INF/libないに移動し、 Eclipseのビルドパスの構成からクラスパスに追加してやる。
※エクスプローラ上でjarを移動した際はF5でプロジェクトの更新が必要。

schema.xmlの定義

これまでで形態素解析が利用できる環境が整ったので、
schema.xmlに以下のように定義してやる。

<?xml version="1.0" encoding="UTF-8" ?>
<schema name="example" version="1.2">
<types>
    <fieldType name="text_sen" class="solr.TextField">
        <analyzer class="org.apache.lucene.analysis.ja.JapaneseAnalyzer" />
    </fieldType>
</types>
<fields>
    ・・・
</fields>
</schema>

tomcatの起動オプション設定

あとはtomcatの起動オプションに$SENホームを追加する。
WTPを利用しているなら、サーバビューからサーバの設定ファイルを開く。
「起動構成を開く」の先の引数タブ内のVM引数欄に以下の記述を書く。


-Dsen.home=$SEN

あとはtomcatを起動するだけ！
疲れた！

Senの動作確認

最後に！！ ここまでくれば後は動作確認するだけ。
tomcatを起動し、http://localhost:8080/プロジェクト名/admin/analysis.jspにアクセスし、
↓画像のようになればOK！！

スレッドセーフ？

スレッドセーフとは

http://e-words.jp/w/E382B9E383ACE38383E38389E382BBE383BCE38395.html

スレッドセーフができていないというのは

同じインスタンスにある同じ変数を
複数のスレッドが参照・更新できる場合や、
共有ファイルを複数人で参照・更新できる場合
のこと。

例えば

下記コードがあった場合、

 private int num;

 public int getNum(){
 　　return num;
 }

 public void setNum(int なむ){
 　　num = なむ;
 }

 public void update(){
 　　System.out.println(num); //-----(1)
 　　int i;                   
 　　for(i=0; i < num; i++);  //-----(2)
 　　System.out.println(i);
 }

• 正常
  

1. スレッドA　が　Hoge.setNum(10000);実行
2. スレッドA　が　Hoge.update();実行

　　　　　コンソールに表示される結果は下記となる。
　　　　　　10000
　　　　　　10000

• 異常

1. スレッドA　が　Hoge.setNum(10000);実行
2. スレッドA　が　Hoge.update();実行
3. 「２．」実行中にスレッドBがHoge.setNum(500);実行

　　　　　コンソールに表示される結果はだれにも予想できないが、
　　　　　おそらく下記のような結果となる。

　　　　　(1)の直前で「３．」が実行された場合の結果は
　　　　　　500
　　　　　　500

　　　　　(2)の直前で「３．」が実行された場合の結果は
　　　　　　10000
　　　　　　500

　　　　　(2)を実行中に「３．」が実行された場合の結果は
　　　　　　10000
　　　　　　"500～10000のいずれか"

対処方法

各メソッドにsynchonized装飾子をつけてあげればとりあえずは防げる。

詳しくは下記

http://d.hatena.ne.jp/amachang/20100324/1269425706
http://www.ibm.com/developerworks/jp/java/library/j-threadsafe/

solrとtomcatの連携(WTP)

solrのダウンロード

solrを下記URLからダウンロードして任意のディレクトリに解凍する。
http://www.apache.org/dyn/closer.cgi/lucene/solr/
ダウンロードしたディレクトリ内にある/example/webapps/solr.warを
tomcatのwebappディレクトリに移動。
tomcatを起動してsolr.warファイルをデプロイ→solrディレクトリがwebapp内にできる。
※ここは単に解凍してやるだけでよさそうかも。

tomcatとの連携

1. プロジェクト作成　
   Doltengプラグインを使い、C:/project/aaa/bbbにsolr用の新規プロジェクト"ccc"を作成。
   ※いやこれDoltengでやる必要は全然ない(笑)
2. solr/homeディレクトリの移動　
   1.でダウンロードしたディレクトリ内にある/example/webapps/solrディレクトリ(bin,conf,dataを含む)を、 C:/project/aaa/bbbに移動。※ここではsolrディレクトリをsearchと名前変更している 
3. solrの組み込み　
   またtomcatのwebappに展開されたsolrディレクトリ内の下記ファイルをbbbに
   
   • admin、META-INFディレクトリ　→　webappディレクトリ直下
   • lib内のjarファイル　→　 webapp/WEB-INF/lib
   • WEB-INF内のweb.xml　→　 webapp/WEB-INF/
   にそれぞれ移動。(自動で参照ライブラリに追加される？)
   ※ここらで一旦cccプロジェクトを更新。
4. web.xmlの編集
   　上書きしたweb.xmlを開き、下記ソースのコメントアウトを外し、env-entry-value部分を1の手順で移動したパスに変更する。
   

     <env-entry>
         <env-entry-name>solr/home</env-entry-name>
       <env-entry-value>C:/project/aaa/bbb/ccc</env-entry-value>
       <env-entry-type>java.lang.String</env-entry-type>
     </env-entry>
   

 

WTPでサーバの登録

 サーバービューから新規サーバを追加し、新規リソースの追加でcccプロジェクトを指定する。
あとはサーバを起動させるだけで、solrの管理画面にアクセスできる。
http://localhost:8080/ccc/admin
また、サーバの起動時にsolrプロジェクト以外も起動させたい場合は、
サーバ追加時のリソース選択で任意のプロジェクトを指定してやるだけでよい。

対応内容は資料化してみる

webサイトの保守を行う以上、
何かしらの改修・追加開発依頼が発生します。

そんなとき、
依頼者と対応者の間で対応内容の認識にズレがあると
対応中または対応完了後に面倒事になる。

ので、ズレを起こさないように
予め色々資料化して確認しておこうよという話。

web開発？を例に下記に並べてみました。

１．対応箇所の確認

• 対応画面のURL
• 具体的に修正箇所がどこなのか画面をキャプチャして示す

２．対応内容の確認

• 何をしたら、どんな動きをするのか例を挙げて示す
• DBの場合、どのパラメタを、どう変更したら、何がおきるのか
• APIも同様

３．対応範囲の確認(マルチベンダの場合とか特に)

• 対応範囲の切り分けを明確にしておく

４．対応スケジュールの確認(マルチベンダの場合とか特に)

• スケジュール(全社分)を引く
• (厳しそうならご指摘くださいと伝えること)
• (Aが終わらないと、Bができない場合だとしても、Bが遅れたらBの対応者が責められるかも)
• (全社分確認を取れたら依頼者に報告)

５．対応結果の確認

• 具体的にこう操作したら、こうなります的な一覧を作る
• 対応内容の確認に近い
• 要はテスト項目書

つぎに資料化することのメリット・デメリットをそれぞれ挙げてみます。

メリット

• 依頼者との認識違いを減らすことができる
• 予め依頼者と具体的な対応内容を確認しておくことで仕様を握ることができる
• 対応内容を自分自身で整理できる
• 整理ついでにメンバーに対応内容が共有できる
• 時間が経っても(後から参加した人でも)対応内容を確認できる

デメリット

• ちょっと手間

当然対応内容の規模によっては、
すべてを行う必要はないと思います。
けーすばいけーす。

みなさんはどですか。