elasticsearchはSolrのようなluceneベースの検索サーバですが、Solrよりもデータ解析系に向かっているものかと思います。
elasticsearchはいろいろな機能をプラグインとして提供していますが、Solrっぽい動きをしてくれるmocksolrpluginというのがあるので、それを使って、FessでSolrの代わりにelasticsearchを使ってみます。
まず、ここからelasticsearchをダウンロードします。
そして、それを展開します。
$ unzip elasticsearch-0.90.0.zip
$ cd elasticsearch-0.90.0/
次に、elasticsearch-mocksolrpluginをインストールします。
ですが、オリジナルのmocksolrpluginはelasticsearch 0.90.0で動かないので(そもそもあんまり動かない気が…)、修正したものをcodelibsから提供したのでそれを利用します。
オリジナルのmocksolrpluginが今後運用されるかどうかよくわからないので、フォークして独自路線を進むかどうかは今後考えるとして、とりあえずはそこにある最新のzipを利用してもらえればOKかと。
(ちなみに修正したソースコードはここのdevelopブランチにあります)
$ ./bin/plugin -install elasticsearch-mocksolrplugin -url http://maven.codelibs.org/org/codelibs/elasticsearch-mocksolrplugin/1.1.5-SNAPSHOT/elasticsearch-mocksolrplugin-1.1.5-20130507.051401-2.zip
上記でプラグインがインストールされます。
もし、プラグインのインストールに失敗したような場合は、一度、プラグインをアンインストールして再度インストールしてください。
プラグインのアンインストールは以下のコマンド。
$ ./bin/plugin -remove elasticsearch-mocksolrplugin
そして、elasticsearchを起動します。
$ ./bin/elasticsearch
次にelasticsearch上にインデックスを生成しておく。
$ curl -XPUT 'http://127.0.0.1:9200/solr/'
URL上のsolrの部分はインデックス名なので、別にsolrという名前でなくてもOKです。
次に事前にフィールドの型を登録しておきます。
elasticsearchは何もしないと自動で型判定をして、インデックスを生成するので、必要に応じて事前にマッピングという形で型登録をしておきます。
まぁ、elasticsearchはスキーマフリーという感じだけど、日付型とかあると事前に指定しておかないとうまくいかない場合もある気がするし、型とかが事前にわかっているなら、マッピングで指定しておいた方が良い気がします。
FessのSolrスキーマをベースに作ると以下の感じ。
$ curl -XPUT 'http://127.0.0.1:9200/solr/core1/_mapping' -d '
{
"core1" : {
"index_analyzer" : "standard",
"search_analyzer" : "standard",
"date_detection" : false,
"numeric_detection" : true,
"properties" : {
"id" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"parentId" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"segment" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"digest" : {"type" : "string", "store" : "yes"},
"boost" : {"type" : "float", "store" : "yes", "null_value" : 1.0},
"host" : {"type" : "string", "store" : "yes"},
"site" : {"type" : "string", "store" : "yes"},
"url" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"content" : {"type" : "string", "store" : "yes"},
"title" : {"type" : "string", "store" : "yes"},
"cache" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"tstamp" : {"type" : "solr_date", "store" : "yes"},
"anchor" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"contentLength" : {"type" : "long", "store" : "yes"},
"lastModified" : {"type" : "solr_date", "store" : "yes"},
"lang" : {"type" : "string", "store" : "yes"},
"mimetype" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"type" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"label" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"},
"role" : {"type" : "string", "store" : "yes", "index" : "not_analyzed"}
}
}
}
'
次に、ここからFessをダウンロードして、インストールします。
$ cd ..
$ unzip fess-servver-8.0.0.zip
$ cd fess-server-8.0.0
$ chmod +x bin/*.sh
今回、Solrはいらないので削除しておきます。
$ rm -rf webapps/solr/
Fessの設定をSolrからelasticsearchに変更する。
$ vi webapps/fess/WEB-INF/classes/solrlib.dicon
...以下にSolrのパスを変更...
"http://127.0.0.1:9200/solr/core1/_solr"
そして、Fessを起動する。
$ ./bin/startup.sh
起動したら、管理者でログインします。
この辺は普通のFessと同様です。
http://127.0.0.1:8080/fess/admin/system/index にアクセスすると、solrServer1の状態がunknownと表示されるが気にしない。
現状、Function Queryがうまく処理できないので、http://127.0.0.1:8080/fess/admin/crawl/index で差分クロールのチェックを外して設定を保存する。
あとは、通常通りにクロール設定を作成してクロールを実行する。
クロールが完了したら、いつもどおりに http://127.0.0.1:8080/fess/ で検索してみてください。
検索結果に表示されればOKです。
今回、mappingでTokenizerとか設定していないので、必要に応じてその辺も設定すると良いかも。
オリジナルのものをいろいろと修正して、インデックスの登録と検索はできるようになったけど、Function Queryとか、まだ課題はある気がします。
一応、現状のものをオリジナルのところにpullリクエストはしてみたものの、特に反応はない感じです。
ということもあり、独自に作りなおしたほうが良いかな、とも思っています…。
カテゴリー: CodeLibs
Empros
S4とかStormとか、リアルタイムの分散イベント処理系のプロダクトがいろいろとあると思うけど、現在のところ、将来の勝者がどれになるのか予測困難だし、それぞれに一長一短があったり、何と言っても手軽ではない感が強い(現状、選択するのが難しい…)。あと、Hadoopもそうだけど、サーバを潤沢に持つ大規模なところがターゲットな感じがあるし(TwitterとかYahooとかだし)、そうでないところの案件には適用するのが辛い気がしている。つまり、最小構成ならTomcatとかに配備すれば動くよくらいの軽いノリのが欲しい。というわけで、何かしらのイベントをJSONでサーバに送りつけていろいろするための仕組みをEmprosとして作ることにしました。EmprosにJSONでキーと値のオブジェクトを送ると、Empros内に登録されたProcessor群に次々伝播されて処理されます。なので、Processorを適当に作れば、自由にカスタマイズできると思います。
直近の目的は、Fessとの連携があります。Fessに限らず、検索システムを作ろうとしたとき、共有フォルダが対象でサイズがでかいと夜間とかでクロールするのが不可能な状況になります。そのときに回避策として考えられるのが、更新分だけを夜間とかでクロールすることで使い勝手を上げる方法があるかと思います。WindowsやLinuxの共有フォルダとかで動いているのであれば、ファイル更新イベントとか取得できるので、発生したイベントをEmprosに送って、更新リストを作成して、Fessがそのリストを元にクロールする感じを考えています。というわけで、ガンガンイベントを送りつけられてもEmprosが動くようにする必要があるし(つまり、スループットが重要)、Tomcatとかで手軽に運用できると良いかなという感じです。まぁ、EmprosはFess以外にもいろいろと考えてはいますが、地道にやっていく感じかと思います。
FessとかはSAStrutsベースに作ってますが、EmprosはSpringベースです。そんでもって、Servlet 3.0 (非同期を利用しているため)で Java 7が必要になります。EmprosはデータをDBに保存できますが、そこはいつものDBFluteを採用してます(始めてSpring上でDBFluteを使ってみた)。現在はログの吐き出し、DBに保存、CSVに保存などをパラレルにできる感じです。まだ、始まったばかりな感じですが、いろいろと機能を追加していきたいところです。
という感じで、興味がありましたらどうぞ。
Solr 4.1から4.2へ
Fessに同梱されているSolrを更新する都合上、schema.xmlとsolrconfig.xmlの差分はバージョンアップする際にいつも比較しなければならない。なので、メジャーアップデートのときとかは結構辛いのだけど、今回はマイナーアップデートだったので差分はあんまり大したことなかった。solrconfig.xmlについていうと、
<codecFactory class="solr.SchemaCodecFactory"/>
が加わっていたことかな。schema.xmlについては、docValues要素が入っていることかな。docValues=”true”にできるのは、StrField、UUIDField、Tri*Fieldでマルチフィールドでなくて、必須かデフォルト値を持つ必要があるって書いてあった。うーん、Fessだと必須なフィールドは少ないのだよね。というわけで、変更点的にはそんな感じだった。