Solr on @johtaniの日記 3rd

第13回Solr勉強会を開催しました

Wed, 29 Jan 2014 18:46:00 +0900

改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。

出版記念なので、技術評論社様より、プレゼント用にSolr本を用意していただきました！ありがとうございます！！書籍をゲット出来た方は、ツイートしたりブログ書いたり書評書いたりして、宣伝してください！！！

今回は、私は手を抜いて他の人に喋ってもらいました！

今回は、著者陣（関口さんは特別ゲスト）でスピーカーを固めてみました。以下は、いつもの簡単なメモです。スライドが集まったらまた更新していきます。

1. 「はじめての検索エンジン＆Solr」株式会社NTTデータCCS　鈴木教嗣さん

スライド：はじめての検索エンジン＆Solr 第13回Solr勉強会

鈴木さんの発表初めて聞きましたｗ。趣味が多いなぁ。ちょこちょこと、宣伝を入れてるのが流石ですｗ

入門らしい概要
クエリの概要とかも。
スコア計算とか
導入するとうれしいところとか
Solr盛り上げましょう！

2. 「Solr SearchComponent 再訪」株式会社ロンウイット　関口宏司さん

スライド：公開待ち

ベン図で検索の評価指標の説明
理論的なお話
Solrのサーチコンポーネントを使って何ができるか。ベン図で。
サーチコンポーネント以外にも
- NGramTokenizerも
- SynonymFilterも
- パーソナライズ検索

いきなり話をふられたのでちょっとびっくりしましたｗ

3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」株式会社ロンウイット　大須賀稔さん

スライド：Solr AutoComplete and Did You Mean?
デモ：https://github.com/mosuka/solr-suggester-demo-ui

職歴が相変わらずおもしろい
編集距離のお話
素晴らしいCM！

候補のランキングを変更できる？ SpellcheckComponentのパラメータで指定できるものなら楽ですが。。。

4. 「Lucene Revolution 2013 Dublin振り返り」楽天株式会社　平賀一昭さん

スライド：公開待ち

ダブリンどこ？（間違ってベルリンって言っちゃいましたｗ）
スタジアムで開催。グランドにも入れるのかなぁ？
まずはTwitter
- Luceneの改良版
- ちょっと特殊。１４０文字とか
青いRさんのライバル。Careerbuilder
- 元FASTユーザ
- 企業向けに検索キーワードとかの解析画面を用意
- 検索精度の改良の話とか
- 転職で引っ越す意思があるかとか。
最後はLinkedIn
- Luceneのユーザ

まとめ

ということで、スピーカーの方々のスライドにもありましたが、改訂新版Apache Solr入門は良い本なので、購入していただけると嬉しいです。

感想、コメントなど、いつでもお待ちしています！

lucene-gosen 4.6.1のリリースに関する注意点

Tue, 28 Jan 2014 12:34:00 +0900

Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。

ライブラリのインタフェースなどは特に変更はないのですが、ライブラリのダウンロード先が変更になっているため、注意喚起です。

Google Project Hostingの仕様変更により、Downloadsに新規ファイルがアップロードできなくなっています。（2014年から）

このため、プロジェクトの選択肢としては以下の3点となっています。

Google Driveにファイルをアップロードしてダウンロードしてもらう
他のソースコード管理サイトなどを利用する。
他のダウンロードサイトを利用する

1.と3.は場所が違うだけで、方法は一緒です。今回は、暫定的に1.を利用してダウンロードするように対応しました。

ダウンロード先はプロジェクトのページにリンクが有りますが、わかりにくいのでキャプチャを撮ってみました。

ダウンロード先

これまでのFeatured - Downloadsとは異なり、Links - External linksの下に Downloads lucene-gosen 4.6.1というリンクを用意してあります。

フォルダとなっており、各種jarファイルがリストされていますので、こちらからダウンロードをお願いします。今後は、この下にダウンロードリンクを追加していく予定です。

ただし、2.で述べたように「別のソースコード管理サイト」も検討中です。

Solrへのプラグインの配置方法について

Thu, 19 Dec 2013 19:09:00 +0900

Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。

プラグインの配置方法についてこんな質問を受けてたので、それっぽいエントリを書いておきます。（想像と違ってたらツッコミ入れてください）

@johtani 追加でプラグインの配置方法とかあると便利かなと思いました
— Tsubosaka (@tsubosaka) 2013, 12月 2

改定前のSolr本では、日本語の形態素解析器をjarファイルとして追加する方法が書かれていました。ただ、改定後のSolr本では、KuromojiがLuceneで実装されているためサンプルとしてjarファイルを追加するような方法の記載が明確にはありません。

19ページのcollection1の説明ですこしだけ、libディレクトリについて触れています。

独自のTokenizer（lucene-gosenなど）はjar形式でSolrに追加し、schema.xmlなどに利用するFactoryを指定してから利用します。

このとき、追加のjarファイルを配置する先がlibディレクトリです。

libディレクトリは2つの種類のスコープのディレクトリが存在します。

Solr全体で利用可能なlibディレクトリ
コア単位で利用可能なlibディレクトリ

Solr全体で利用するlibディレクトリ

これは、起動しているSolrにある全てのコアで利用するようなjarファイルを配置するディレクトリになります。場所は$SOLR_HOME/libです。ここにjarファイルを配置することで、この$SOLR_HOMEを利用するすべてのコアで同じjarファイルを利用することができるようになります。

ですので、例えば、lucene-gosenはすべてのコアで利用するという場合にはここに配置すれば、1つのjarファイルを配置するだけで済むことになります。

コア単位で利用するlibディレクトリ

これは、コアごとにlibディレクトリを用意する場合です。 19ページにも記載されていますが、$SOLR_HOME/コアディレクトリ名/libとなります。

特定のコアのみで利用するライブラリについてはこちらに配置する形になります。他のコアで利用してほしくないjarファイルなどを配置するのに利用すればよいかと。

簡単ですが、補足記事でした。 UIMAやlangidの利用方法などもあるとうれしですかね？そのうち気が向けば書くかもしれません。（他の人に書いてもらうのもありかも。）

改訂版Solr入門のPDF版も発売

Mon, 09 Dec 2013 11:08:00 +0900

少し遅くなってしまいましたが、12/05に電子書籍も発売されました。

技術評論社の電子書籍サイトから購入可能です。

書籍のページへのリンク

PDF版となっております。購入の際は、技術評論社の電子書籍サイトに会員登録後購入可能となります。

個人的には電子書籍が便利なので、こちらを普段活用しようと思っています。

もちろん、紙の書籍も発売中です！購入の際は右の書影をクリックしていただければと！

改訂版Solr入門を執筆しました

Tue, 26 Nov 2013 12:27:00 +0900

勉強会で宣伝もしましたが、改めて。

Solr入門の改訂版を執筆しました。考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会などでも何度も新しいのは出ないのですか？と聞かれていましたが、やっと出ました。（お待たせしました。）

時が立つのは早いものです。前回のSolr入門はバージョン1.4にて執筆していましたが、今回は4.4をベースにし、4.5.1への対応を行っています。

月曜日には手元に見本が届き、今週金曜日に発売予定です！

SolrCloud、SoftCommit、Spatial、Joinなど、多彩な機能についても記載してあります。また、ManifoldCFというSolrにデータを登録するのに利用できるコネクタフレームワークについても書いてあります。

より多彩になったSolrの機能を活用するための一助となれればと思います。（電子版も出る予定です。詳細についてはもう少々お待ちください）

また、出版を記念して少し時期が先になりますが、Solr勉強会を開催しようと思います。

日時：2014年01月29日
第13回Solr勉強会 #SolrJP 新Solr本出版記念

今回はせっかくのSolr入門の書籍の出版記念ということで入門的な話をしてもらう予定です。 Solr初心者の方、Solrに興味のある方などに来ていただきたいと思っています。（プレゼントも用意できるかも！？）

ということで、「改訂版Apache Solr入門」をよろしくお願いします。（もちろん、購入は下のリンクからですよね！）

第12回Solr勉強会を主催しました。#SolrJP

Thu, 10 Oct 2013 11:35:00 +0900

不定期開催ですが第12回Solr勉強会を主催しました。

今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかと。ありがとうございます！

今回は聞きたかったYokozunaの話をしてもらいました。あと、リベンジManifoldCF。 一部、追記しました。Bashoさんからツッコミがあったので。あと、4.5.1の話とか。

ManifoldCFのとSolrの組み合わせ（仮）株式会社ロンウイット　大須賀　稔さん

前回お休みだったのでリベンジですw。

英語だ。。。やっぱ英語がいいですか、スライド。。。
ManifoldCFの概要から。最新版は1.3です。色々サポートしてるなぁ。

デモもありました。（やっぱりちゃんと動かないので、鬼門みたいですが）

デモ

ManifoldCFのGUIで操作しながら。いまいちちゃんと動かなかった。。。

QA

Q:Zipはうまく動かなかった
A:Solr側で処理してくれてる。
Q:Notes対応するの？
A:いまのところない。
Q:ExcelとかPDFはTika？
A:Tika次第です。
Q:認証周りどこから取ってくるの？
A:クローラ側にはなくて、SharePointとかの権限をみてる。
Q:Web系の認証は？
A:まだないのでは。。。（調査します）

あー、デモの続き忘れてましたね。。。

Solrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん

Riak色々使われてるよ！アングリーバードとか、Y!とか。 Riakで提供されている1機能としてのYokozuna。単独製品ではないですよと。

Riakの説明。スケールするよ、いつでもRead/Writeできるよ、運用にフォーカスしてるよと。マスターレスですよ。 Riak2.0のリリースは2013年末。Yokozunaもかな？

ダイナミックフィールド使ってるので、Yokozunaをonにするだけで簡単に使えるよ。

RiakがSolrのプロセスを管理。

インデックスの不整合の検知とかってどうやってるのかなぁ？インデックス比較用のハッシュツリーをノード間でコピーしつつ検査してる。（Active Anti-Entropy）

(デモには魔物がいるようだ。。。)

QA

Q:JSONの属性を元にしてフィールドにインデックス可能か？
A:可能です。IIJさんの発表で話が出ます。
Q:ProtocolBufferでSolrにアクセス可能？
A:~~そのうちできそうです。~~リリース時にはできるようになっています。
Q:コアのスワップは？スキーマの変更は？
A:事前に設定するのは可能。
Q:RiakのデータとSolrでデータがずれるってのはあるの？
A:可能性はありますが、~~極力ずれ~~AAEで修復。
Q:復旧中のインデックスにアクセスが行かないようにする仕組みなどはある？
A:今はないです。

Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中義久さん

いいとこ取りで楽だなぁと。いうことで、試してみてます。デモが動いてる。

extractorでXMLやJSONをパースできる。ベンチマーク結果。

Riak Meetup Tokyo #2の時のQAも入ってるので助かります。素晴らしい。

QA

Q:スナップショットは両方取れるの？
A:Riakは取れますが、インデックスは今は無理です。
フォロー:0.8はYokozunaにボトルネックがあったので、0.9以降だともっと性能が出るはずですとのこと。また次回とかに発表してもらうのもありですかねぇ。

Solr 4.5の新機能など @johtani

発表資料のPDFです。

ツイート見てて誤解を招いたなと思ったのですが、7u40は4.5限定ではなく、すべてのバージョンと考えてください。チケットを見ると分かりますが、影響バージョンの記載はありません。

※あ、4.5のChangesを紹介しましたが、4.5.1が出るかも。このへんが困ってるらしいです。

LT

@haruyama さん

資料：http://haruyama.github.io/solr_20131009/#(1)

記号が捨てられるTokenizer困るので、捨てないのを作ってみました。

Kuromojiの困ったこと。全角数字を分解しちゃう。→MappingCharFilterFactoryで全角から半角にしましょう。 lucene-gosenデフォで半角記号が未知語になってしまい、半角カナと混ざるので、記号を全角にしましょう。

MorphlinesのloadSolrをちょっとだけ調べてみた

Fri, 02 Aug 2013 18:02:00 +0900

宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、なんか調べることになってたので、関係しそうなMorphlinesのLoadSolrコマンドを調べてみました。こいつが、Solrへの書き込みを実行するコマンドみたいだったので。
（※Cloudera Searchのスキーマの設定方法とかは調べてないです。）
（※めんどくさかったので、パッケージ名すっ飛ばしてクラス名書いてます。githubへのリンクを代わりに貼ってます。）

Record＝Solrのドキュメント

convert()メソッドにて、MorphlinesのRecord（コマンドの処理するデータの１単位）に格納されているKey-ValueデータをSolrInputDocumentクラスのフィールドとして格納しています。 Recordにもフィールドという概念があり、Recordのフィールド＝Solrのフィールドという事みたいです。

ということで、Solrのフィールドは事前に定義しておき、Morphlinesの処理内部でSolrのフィールド名に値を詰めていく感じでしょうか。別途、sanitizeUnknownSolrFildsというコマンドが用意されていて、Solrのスキーマにないものはこのコマンドを使って、無視するフィールド名に変えたり、雑多なデータを入れるためのフィールド名にするといった処理ができるようです。このコマンド内部で、Solrのスキーマ設定を元に、Solrのフィールドに合致する物があるかをチェックして処理しています。

Solrへの登録処理は？

Solrへの登録処理自体はLoadSolrクラス内部でDocumentLoaderというクラスのload()メソッドを呼び出しているだけでした。ということで、DocumentBuilderクラスを少し調査。

DocumentLoader

IFでした。。。実クラスは次の条件

SolrMorphlineContextにDocumentLoaderがあればそちらを採用（他の種類はなにがあるんだろ？）
なければ、SolrServerDocumentLoaderをnewしたものを利用

2.の場合がおそらくMapReduceではないパターンのloadSolrだと思われます。SolrServerDocumentBuilderはSolrJのAPIを利用して、Solrへデータ登録していく普通のアプリです。（対象とするSolrは外部に起動しているもののはず＝FlumeのSolrSinkではこちらを採用かな？）
Solrへの接続情報とか設定ファイルとかSolrCloud用のZooKeeperとかはSolrLocatorクラスに設定される内容が利用されます。

1.のパターンは、どうやら、Cloudera SearchのMapReduceIndexerToolのクラスにあるMyDocumentLoaderかなぁと。こちらは、MapReduceを利用する場合に、利用されてるっぽいです（ちゃんと見てないけど）内部処理は、HadoopのContext.writeメソッドにでSolrInputDocument（＝MorphlinesのRecord）を書きだして、ReducerでSolrOutputFormatでインデックス作成の流れかなと。たぶん、MorphlineMapRunnerあたりを読みこめば解読できるかと。ちなみに、こちらは、2.とは異なり、SolrLocatorの設定は無視されそう。

感想＋妄想？

ということで、Morphlinesのデータ流れを考える上で、現時点ではSolrのスキーマを頭の片隅に置きつつ、 Recordの中にあるデータをゴニョゴニョしてデータを形成していくって感じになりそうです。うまく処理できなかったものとかのカウントとかもとれたりするのかなぁ？とか、また色々と気になるところが出てきますが、一旦ここまでで。。。（だれか、続きを調べて書いてみてくれてもいいんですよ！コマンドもいっぱいあるし！）

とまぁ、こんなかんじでMorphlinesをちょっとだけ読みました。よくよく考えたら、こんなの作ったことあるなぁと（こんなに汎用的じゃないけど）。みんな同じ事考えるんですねぇ。コマンドパターン？みたいな感じで、I/F決めてSolrとか別のシステムとかにデータ入れる処理を順番に記述できる的なバッチ処理良くかいてます（書いてましたのほうが正解かなぁ）。

Morphlines入門？

Wed, 31 Jul 2013 19:12:00 +0900

Morphlinesについてちょっとだけ、さらに調べました。

誤解

Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいです。スミマセン。

誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ

まぁ、書いてあるのでちゃんと読めって話ですが、Morphlineはあくまでライブラリだということでした。私はなんとなくManifoldCFのようなミドルウェアorプラットフォームが存在して、そこにFlumeのSinkとかMapReduceによるIndexerが動作するのかと思ってました。

まぁ、これが間違いでした。正解のイメージはこっちですね。

各プラットフォーム（FlumeとかHadoopとか）に組み込んむライブラリで、それぞれ組み込んだ先でMorphlineの設定を記述することで、パイプライン処理ができるっぽいです。

Flumeについては、MorphlineSolrSinkというクラスでMorphlineの設定ファイルを読み込み、いろいろ処理出来ます。

Map/ReduceだとCloudera Searchに含まれてるMapReduceIndexerToolがMorphlineの設定を読み込んでコマンド実行してくれるみたいです。 MapReduceIndexerToolはまだちゃんと読んでないのですが、MapperとしてMorphlineのコマンドが実行されるのかなぁ？という感じです。（結構入り組んでるので、ちゃんと読まないとわからない。。。）

ということで、Morphlineというプラットフォームがあって、一元的にFlumeやMap/Reduceに対するコマンドをパイプライン化するという話でありませんでした。

※ちなみに、上の画像ですが、愛用しているNUBoardを使って書いてます。考えをまとめるのにすごく役立つ一品です。持ち運び可能なノート型ホワイトボードです。

疑問点

ただ、読んでてまだ不明な点があります。まぁ、ぼちぼち調べるかなぁと。。。

Solrのschemaはどーなってんの？
MorphlineにSolrへロードするコマンド（loadSolr）があるけど、FlumeのMorphlineSolrSinkってのもSolrに書き込みそうだけど？
Map/ReduceでSolrに書き込むもMorphlineのコマンドとの違いは？（前にソースを見たときはSOLR-1301がベースになっていて、SolrOutputFormatってクラスがEmbeddedSolrServer起動してインデクシングしてた）
GoLiveってなんだろ？（MapReduceIndexerToolに入ってて、M/Rでインデックス作ったあとにSolrのクラスタに配布＋マージするやつっぽい）
どんなコマンドがあるの？（Cloudera Morphlines Ref Guide）

以下は、参考資料と参考資料にあるSlideshareの資料を一部訳したものになります。

参考資料

メモ

現在のコマンドライブラリ（スライド 18-19ページ）

Solrへのインテグレートとロード
フレキシブルなログファイル解析
1行、複数行、CSVファイル
正規表現ベースのパターンマッチと展開
Avro、JSON、XML、HTMLのインテグレーション
Hadoop シーケンスファイルのインテグレーション
SolrCellとApache Tikaパーサすべてのインテグレーション
Tikaを利用したバイナリデータからMIMEタイプの自動判別
動的Javaコードのスクリプティングサポート
フィールドの割り当て処理、比較処理
リストやセット書式のフィールド処理
if-then-else条件分岐
簡易ルールエンジン（tryRules）
文字列とタイムスタンプの変換
slf4jロギング
Yammerメトリックとカウンター
ネストされたファイルフォーマットコンテナの解凍
などなど

プラグインコマンド（スライド　20ページ）

簡単に新しいI/Oや変換コマンドが追加可能
サードパーティや既存機能のインテグレード
CommandインタフェースかAbstractCommandのサブクラスを実装
Javaクラスパスに新規作成したものを追加
登録処理などは必要ない

新しいプラグインコマンドとして考えられるもの（22ページ）

RDBやKVSやローカルファイルなどの外部データソースをレコードにjoin
DNS名前解決とか短縮URLの展開とか
ソーシャル・ネットワークからリンクされたメタデータのフェッチ（？？）
レコードの感情分析とアノテーション？

31ページの図がわかりやすいかも

以上。

第11回Solr勉強会を主催しました。#SolrJP

Mon, 29 Jul 2013 23:15:00 +0900

不定期開催ですが第11回Solr勉強会を主催しました。

今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（20時時点で最終的に補欠17人でした。）

~~とりあえず、第一報です。このあと懇親会なので。~~

ということで、帰りの電車でいくつか感想を（忘れちゃうから）。

小林さんの苦労話は細かいですが、結構はまりがちな点を共有していただいたので良かったかなぁと。 Solrのexampleの設定とか、ManifoldCFとかちょっとずつ罠があったりするので、あるあるネタはありがたいと思いますｗ

Cloudera Searchについては、安定の嶋内さんの喋りに圧巻でした。検索だけの視点とは異なる観点についての話は私には足りないしてんだったりするので参考になります。なんか、気づいたらMorphlineやスキーマ周りを調べてブログ書くことになっちゃったけど。。。一つ質問しそこねたのがあって、Cloudera社は基本的に公開したOSSについてのトレーニングも立ち上げているイメージです。Cloudera Searchについてもトレーニングが立ち上がるのかなぁと密かに期待をしてみたり（予算の関係上参加できるかは不明ですが。。。）

牧野さんの話は画像系について、私は詳しくないので、また関口さんのalikeと比較とかしてもらえると面白いかなぁと。とりあえず、青いロボットがちゃんと検索できるようになるといいですねｗｗ

秀野さんの空間検索は緯度経度以外のPOLYGONなどを利用した検索で、実は私も知らない機能でしたｗ
なとなくは知ってたんですが、そこまでちゃんと検索できるとは！地図以外にも活用できるような気がします（想像つかないんだけど。。。）

最後は私の発表で、簡単な資料ですみませんでした。しかも発表よりも宣伝が。。。（ブログの宣伝だったりとか。。。）最後に宣伝した「「ビッグデータ活用を支えるOSS」特集への論文投稿のご案内」もご検討ください！

懇親会も楽しかったです。また思いついたら開催しますー
最後に、今回の発表者の皆様、会場提供していただいたVOYAGE GROUPの皆様ありがとうございました！

以下はいつものメモです。

ManifoldCFのとSolrの組み合わせ（仮）株式会社ロンウイット　大須賀さん

残念ながら、発熱のため発表は次回に持ち越しに。

##社内ファイル及びWEBコンテンツの検索システム構築時に苦労したことソフトバンクBB㈱　小林さん

ManifoldCF＋Solrを使って社内ファイルの検索システム構築
約1000万ドキュメント
さまざまなDCにドキュメントがある

クロールジョブのハング。。。

ログをDEBUGにしたら。。。ログファイル150GB。。。
一定時間ごとにAgentをリスタートするバッチを。。。（力技）

MCFエラーによるジョブの停止

CONNECTORS-590
エラーが発生して止まったジョブを起動するバッチをcronで。。。

自作リアルタイムインデクシングの問題

MCF使わないでSlaveにインデックス
openSearcher=falseだとautoCommitが実行されてもSearcherを再起動しないので検索にでてこない

リプリケーションのNW負荷

別DCからのレプリケーションが複数が一度に実施される→ネットワーク負荷が。。。
cronで別々にレプリすることでNW負荷を分散できてるかな。。。

Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん

マサカリ画像がｗ
SolrのコミッターMark Millerさんもジョインしてる

ClouderaとHadoop入門とか。

いろいろあるよ、エコシステム
4つの分類。
- データの取り込み
- データの保存
- データの活用

Search

検索エンジンなら数十億人が使い方を知ってる（Clouderaのチャールズ・ゼドルースキ）

Cloudera Search

Hadoopのためのインタラクティブな検索
CDHとSolrの統合
OSS！
利点とか。
- データ解析にも使えるよね、検索
- 非構造化データの検索にもいいよね
- 単一プラットフォームによるコスパ

Cloudera Searchの事例

バイオテクノロジー企業で画像検索とか
医療系企業でいろんなログイベントの管理とか

Cloudera Searchのアーキテクチャ

Flumeでストリーミングで登録
HBaseデータの登録
M/Rでバッチ登録
HueのWebインタフェース

Morphlines、HBaseはLinyプロジェクトのもの

Solr使うならCDH！！

QA

Q：デモで使われたTwitterの検索のデータ料とかは？
A：デモ環境ですので小さい。
Q：スキーマってどうするの？
A：スキーマは。。。私が書こうかなぁ、ブログ。。。

コンピュータビジョン　株式会社 Curious Vehicle　牧野さん

色々やってます
コンピュータビジョンの説明（某ネコ型ロボットのいろんな画像がｗ）

画像検索の流れ

特徴情報の抽出
特徴情報のクラスタリングによるword化
Solrによる画像情報の検索

1. 特徴情報の抽出

SIFT特徴点解析
グレースケールしてからSIFT
注意！SIFTは商用ライセンスが必要です

2. 特徴情報のクラスタリングによるword化

K-meansでクラスタリング
クラスタ情報をヒストグラム化してSolrへ

3. Solrによる画像情報の検索

物体認識ベンチマークセット（ケンタッキー大）を使って。
やっぱり良し悪しある。データセットに特化したチューニングしてます。

つぎのステップ

文字認識とか顔認識
つぎはドラえもんじゃねぇ、検索とかも。。。

ガウシアンによる画像ぼかしの例

QA

マイク回しててメモ取れず。。。

国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん

スライドはこちら

評価の関係で。。。
Spatial検索の話

デモの想定機能

地図上の小学校を起点に物件検索
地図上をクリックしたところを中心に検索

デモ環境

Solr4.3.0、PostGIS 2.0.3、東京都のデータ

事前知識

ジオメトリーデータ（点、線、面がある）
WKB/WKT、Intersects（しらなかった。こんなのもあるのか）

環境

EC2上にPostGIS＋Solrで構築
WKT形式でDIHでインポートできるらしい。
Solr＋S3をJSでGoogleMapへ

Solr 4.4新機能をちょっと紹介　@johtani

紹介というよりも宣伝。。。

Yokozunaの気になる点というかなんというか

Thu, 11 Jul 2013 01:43:00 +0900

Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。別に調べるわけじゃないので、完全に自己満足なメモですけど。
ちなみに、分散システムとかRiakの仕組みは詳しくないので、ズレてる点がいっぱいあるかも。
というか、分散システムでテストというか、検討する点とかってまとまってる資料とかあるのかなぁ？

スキーマ変更時の挙動
- フィールド型変更とか、フィールド追加とか
既存RiakクラスタにYokozunaの機能を追加する方法と制限
- タイムラグとかも
Riak＋Yokozunaクラスタに対してノード追加時に発生するオーバーヘッド（ネットワークとかディスクIOとか）
性能検証のためのシナリオ（どっちが先に悲鳴をあげるかとか）
- Riakメインで、Yokozunaはおまけ程度に検索するというシナリオ
- Yokozunaメインで使うシナリオ
- 更新が多い場合のシナリオ
Riakのみ、Riak＋Yokozunaの各種統計情報（CPU、メモリ、ディスクサイズ、ネットワークIO）
運用系（監視とか）の手法とか機能？とか
バージョンアップなどの対応方法
Solrがコケた時とかの対処

とりあえず、こんな感じかなぁ。

Riak Meetup Tokyo #2に参加しました。#riakjp

Wed, 10 Jul 2013 18:57:00 +0900

先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。
Yokozunaの話も聞けるということで。懇親会も参加しました。Vさん＆リピさんと話し込んじゃってあんまり他の人と話せなかったけど。。。

以下はいつものメモです。

FreakOut 久森さん「Riak環境をプロダクションで構築＆運用してみた（仮）」

FreakOutとRTB

ディスプレイ広告の新しい配信の枠の話
この人には何出すの？いくらで？みたいな感じ
純広告：表示保証、期間保証など
RTB：1回の広告表示ごとに買い付け
DSP（デマンド・サイト・プラットフォーム）
広告表示は大体0.1秒で表示しないといけない。この間に色々やってる。
- 50ms or die.で戦ってます。
RTBはCPUバウンド
- 多コアを安く並べたい
- Tokyoなんとかとか使ってた。
  - スケーラビリティがキツイ（クライアント側でアルゴリズム分散してる）
  - データ解析もしたいけど、検索ができない
- RTBに適したRiakがうまくハマるのではと。

構成とかとか

アプリはPerlなので、PerlでRiakクライアントが必要。Memcached互換とかあると嬉しい。
ProtobufサポートもPurePerlしかなかった。
ないなら、作ろうと。githubに上がってます。このへんかな？
監視はcloudforecastとかでやってる。

課題

Redirectがつらい（haproxy？がつらい？）
Setが詰まるとつらい（ケースがまだわからない）
対策１
- memcached＋Riak
対応２（案）
- hashからpartitionに直接取りに行くとか

まとめ

素のままRiakはちょっとつらい

QA

聞き取れたやつだけ

Q：1台いくら位ですか？
- A：10万から11万くらい
Q：どのくらいの性能ですか？
- A：同時1000くらいをさばいてる？
Q：50ms以下を出すのに、ネットワーク周りで近さとかを考えることありますか？
- A：国内だと10msあればなんとかなる。それよりもアプリ側のチューニングのほうがまだ重要
Q：Cassandraとか候補に挙がらなかったんですか？
- A：苦しんでる人が知人にいるので。。。あと、用途的に違うので。
Q：バックエンドとしてはなにを？
- A：bitcaskにしてる
Q：サーバ構成、ネットワーク構成がどうなってる？
- A：。。。
Q：Redirectとは？RiakがやってるRedirect？
- A：はい。
Q：他に候補にあがったのは？
- A：商用のaerospike（これかな？）がスケールできそうだったけど、クライアントがいまいち。。。

感想

広告業界のことをよくわかってないので、微妙にピンときてなかったりもするのですが、以下に素早く返すかって観点でどこに注力して、問題点を潰していくのかってのは面白そうだなぁと。リクエスト処理の性能がクリアできたらつぎはスケールの観点（ノード追加時の挙動とか）で検証していくんだろうなと。次回の話も聞いてみたい感じです。

IIJ 曽我部さん、田中さん「Yokozuna 日本語検索性能を評価しました」

Yokozunaって？

Riak＋Solrでいいとこ取り
データの登録とかはRiakのAPIで。
SolrのAPIが使える。
YokozunaがSolrの分散検索の部分を隠してくれる。

Yokozunaのインストールとか。

SolrのAPIっぽい形で検索できるし、戻りもSolrのXMLっぽいのが出てくるよ。

Wikipediaデータってstoreの性能とか。

Riakのノード32台。（Xeon、メモリ24GB、HDD。。。）
yz_extractor：Riakのコンテンツタイプを見てSolrにデータを入れる処理が書いてある。
自分でschema.xmlを書いてYokozunaに指定することもできる。
- スキーマの変更とか登録とか。
  - すでに指定済みスキーマを変更した場合の挙動ってどうなるの？
デモではSolrからid取って、Riakからその他のデータを取り出していた。

Rubyでの性能評価

ベンチマークプログラム側の問題が先に影響が出てしまった。

QA

Q：Riak単体とYokozunaつかった時でディスク容量がどのくらい増えた？
- A：ちゃんと調べてないが、10%くらい増えた気がする。
Q：Solr側の設定でstored=trueだけど、falseにしてもいいんじゃないの？
- A：デモはfalseにしてます。
Q：スキーマってあとから変更できるんですかね？
- A：まだ良くわかってないです。
Q：ノードの追加、削除時の挙動とかも気になります。

感想

今回はStore性能に関してでしたが、今後は検索性能やシナリオによる性能（KVSの処理メインで、時々全文検索とか、全文検索の処理も結構あるパターンとか）の測定とか、耐障害性とかの観点で調査を進めてもらってSolr勉強会で話をしてもらえると面白そうだなぁと勝手に思ってみたり。 Solr勉強会へのコンタクトお待ちしてます！ｗ

スキーマレスモード？（SOLR-4897）を調べて見ました。

Thu, 04 Jul 2013 01:12:00 +0900

Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。

元となるチケットはこちら。SOLR-4897。

スキーマレス？

Solrはschema.xmlにデータの定義（フィールドタイプやフィールドなど）を記述して、データを登録する全文検索システムです。これまでのSolrではこの設定ファイルを元にデータを登録するフィールド名を決定しており、変更を行う場合はSolrのコアを再起動するなどの手順が必要でした。（※ダイナミックフィールドはすこし特殊）

それだと、Solrを管理するのがめんどくさいですね？という感じで現れたのがSchemaREST APIです。（たぶん。）

Schema REST API

Solr 4.2から導入されたSolrのスキーマに関する情報を提供するためのREST APIです。 4.2で導入されたのはあくまでもschema.xmlの情報を取得するためのAPIでした。たとえば、Fieldの一覧を取得するとか。

4.4から、フィールドの追加（変更、削除はできない）ができるようになりました。あくまでも、フィールドの追加で、フィールドタイプなどの追加はまだできません。（できるようになるのかもわからないですが。）フィールドの追加方法などはWikiに記載がありました。

ということで、簡単に試してみることに。

起動方法

exampleディレクトリの下にexample-schemalessというディレクトリが新設されています。ここに、スキーマレスモード用の設定がされているファイルが入っているので、こちらを利用します。

cd $SOLR/example
java -Dsolr.solr.home=example-schemaless/solr -jar start.jar

ログにいくつかWARNが出ますが、影響の内パス設定ミスなので無視してOKです。

最初に定義されているフィールドは「id」と「_version_」のみになります。（Schema Browserなどで確認できます。あ、REST APIでもいいですね。http://localhost:8983/solr/schema/fields）

スキーマの更新

さて、フィールドを追加してみます。 PUTを利用すると1フィールドの追加が可能です。「fugatext」というフィールド名でフィールドを追加しています。今のところJSONのみ対応みたいです。

$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H 'Content-Type: application/json' -d '{"type":"text_ja","stored":false,"multiValued":true}'
{
  "responseHeader":{
    "status":0,
    "QTime":18}}

追加できたかどうかもREST APIで取得してみます。

$ curl http://localhost:8983/solr/schema/fields
{
  "responseHeader":{
    "status":0,
    "QTime":0},
  "fields":[{
      "name":"_version_",
      "type":"long",
      "indexed":true,
      "stored":true},
    {
      "name":"fugatext",
      "type":"text_ja",
      "multiValued":true,
      "stored":false},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true,
      "uniqueKey":true}]}

追加できました。ちなみに、同じフィールド名を追加しようとするとエラーが帰ってきます。

$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H 'Content-Type: application/json' -d '{"type":"text_ja","stored":false,"multiValued":true}'
{
  "responseHeader":{
    "status":400,
    "QTime":1},
  "error":{
    "msg":"Field 'fugatext' already exists.",
    "code":400}}

設定の違い

example-schemalessのsolrconfig.xmlは以下の設定が通常のexampleとは異なるようです。

schemaFactoryの設定

schemaをAPIから変更可能にする設定です。これまでの変更しない設定の場合はClassicIndexSchemaFactoryを指定します。

...
  <schemaFactory class="ManagedIndexSchemaFactory">
    <bool name="mutable">true</bool>
    <str name="managedSchemaResourceName">managed-schema</str>
  </schemaFactory>
...

update.chainの設定

更新処理（update関連のリクエストハンドラ「/update」とか）には次のような設定が追加されていました。（1006行目あたり）

  <requestHandler name="/update" class="solr.UpdateRequestHandler">
    <!-- See below for information on defining 
         updateRequestProcessorChains that can be used by name 
         on each Update Request
      -->
    <lst name="defaults">
      <str name="update.chain">add-unknown-fields-to-the-schema</str>
    </lst>
  </requestHandler>

「add-unknown-fields-to-the-schema」というupdate.chainが指定されています。このchainの定義自体は1669行目くらいに存在します。（長い。。。）

  <!-- Add unknown fields to the schema 
  
       An example field type guessing update processor that will
       attempt to parse string-typed field values as Booleans, Longs,
       Doubles, or Dates, and then add schema fields with the guessed
       field types.  
       
       This requires that the schema is both managed and mutable, by
       declaring schemaFactory as ManagedIndexSchemaFactory, with
       mutable specified as true. 
       
       See http://wiki.apache.org/solr/GuessingFieldTypes
    -->
  <updateRequestProcessorChain name="add-unknown-fields-to-the-schema">
    <processor class="solr.RemoveBlankFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseBooleanFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseLongFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseDoubleFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseDateFieldUpdateProcessorFactory">
      <arr name="format">
        <str>yyyy-MM-dd'T'HH:mm:ss.SSSZ</str>
        <str>yyyy-MM-dd'T'HH:mm:ss,SSSZ</str>
        <str>yyyy-MM-dd'T'HH:mm:ss.SSS</str>
        <str>yyyy-MM-dd'T'HH:mm:ss,SSS</str>
        <str>yyyy-MM-dd'T'HH:mm:ssZ</str>
        <str>yyyy-MM-dd'T'HH:mm:ss</str>
        <str>yyyy-MM-dd'T'HH:mmZ</str>
        <str>yyyy-MM-dd'T'HH:mm</str>
        <str>yyyy-MM-dd HH:mm:ss.SSSZ</str>
        <str>yyyy-MM-dd HH:mm:ss,SSSZ</str>
        <str>yyyy-MM-dd HH:mm:ss.SSS</str>
        <str>yyyy-MM-dd HH:mm:ss,SSS</str>
        <str>yyyy-MM-dd HH:mm:ssZ</str>
        <str>yyyy-MM-dd HH:mm:ss</str>
        <str>yyyy-MM-dd HH:mmZ</str>
        <str>yyyy-MM-dd HH:mm</str>
        <str>yyyy-MM-dd</str>
      </arr>
    </processor>
    <processor class="solr.AddSchemaFieldsUpdateProcessorFactory">
      <str name="defaultFieldType">text_general</str>
      <lst name="typeMapping">
        <str name="valueClass">java.lang.Boolean</str>
        <str name="fieldType">booleans</str>
      </lst>
      <lst name="typeMapping">
        <str name="valueClass">java.util.Date</str>
        <str name="fieldType">tdates</str>
      </lst>
      <lst name="typeMapping">
        <str name="valueClass">java.lang.Long</str>
        <str name="valueClass">java.lang.Integer</str>
        <str name="fieldType">tlongs</str>
      </lst>
      <lst name="typeMapping">
        <str name="valueClass">java.lang.Number</str>
        <str name="fieldType">tdoubles</str>
      </lst>
    </processor>
    <processor class="solr.LogUpdateProcessorFactory"/>
    <processor class="solr.RunUpdateProcessorFactory"/>
  </updateRequestProcessorChain>

使ってるUpdateProcessorはこんな感じみたいです。最後の2つはこれ用じゃないので省略。

プロセッサ名	説明
RemoveBlankFieldUpdateProcessorFactory	値がないフィールドは除去
ParseBooleanFieldUpdateProcessorFactory	スキーマに定義されていないフィールドで、値がBooleanとしてパースできたら、Boolean型とする。
ParseLongFieldUpdateProcessorFactory	スキーマに定義されていないフィールドで、値がLongとしてパースできたら、Long型とする。
ParseDoubleFieldUpdateProcessorFactory	スキーマに定義されていないフィールドで、値がDoubleとしてパースできたら、Double型とする。
ParseDateFieldUpdateProcessorFactory	スキーマに定義されていないフィールドで、値がDateとしてパースできたら、Date型とする。（パースの形式がformatで列挙されてる）
AddSchemaFieldsUpdateProcessorFactory	入力されたドキュメントの中でスキーマに定義されていないフィールド（静的、動的両方）を見つけた時に、フィールドの値の型を元にフィールド型をマッピングする。

とここまで見てきたところで、スキーマレスという名前の意図がちょっとわかったかも。

定義されてないフィールドを持ったデータを登録

起動時には定義されてないフィールドをもったデータを登録してみます。 boolean型で試してみることに。以下のデータを管理画面のデータ登録画面から登録します。（http://localhost:8983/solr/#/collection1/documents）（タイトルでbooleanってわかりにくいですが）

{"id":"change.me","title":true, "price":1.25, "fuga":"100,200"}

エラーは出ません。で、またフィールド一覧を取得すると。

$ curl http://localhost:8983/solr/schema/fields
{
  "responseHeader":{
    "status":0,
    "QTime":1},
  "fields":[{
      "name":"_version_",
      "type":"long",
      "indexed":true,
      "stored":true},
    {
      "name":"fuga",
      "type":"tlongs"},
    {
      "name":"fugatext",
      "type":"text_ja",
      "multiValued":true,
      "stored":false},
    {
      "name":"id",
      "type":"string",
      "multiValued":false,
      "indexed":true,
      "required":true,
      "stored":true,
      "uniqueKey":true},
    {
      "name":"price",
      "type":"tdoubles"},
    {
      "name":"title",
      "type":"booleans"}]}

おー、最後にtitleが追加されてます。他にもfugaやpriceも。（日付は手を抜きました。。。）

感想

詳細までは追いかけてないですが、こんなかんじです。フィールド追加が可能になるのはいいんじゃないでしょうか。SolrCloudの機能との関連もあるのかもしれません。ZooKeeperへの出力も実装されてそうなので。

ただ、機械的に出力されたschema.xml（exampleだとmanaged-schemaというファイル）には_「DO NOT EDIT」_との記述があるので、修正するとなにかおきてしまうかもしれないですねぇ。現時点では、フィールドタイプの変更やフィールドの更新、削除に関してはSolrCoreの再起動などの手順が必要です。あと、変なデータ（タイプミスとか）が登録されたりしないかってのは気になりますね。

※ちなみに、別の人が気づいたんですが、ちょっとバグが有ったみたいで、代わりにチケットつくったらキリ番（SOLR-5000）ゲットしましたｗ

Solrの管理画面でデータ登録

Thu, 27 Jun 2013 16:28:00 +0900

SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。元になってるチケットはこちらです。昨日だか、今朝にtrunkとbranch_4xにコミットされたみたいです。試してみたい方は、branch_4xかtrunkをチェックアウトすると触ることができます。

データ登録用の画面（JSON）

branch_4xをチェックアウトしてexampleを起動し、Solrにアクセスします。
管理画面に「Dcuments」という項目が追加されてます。開くとこんなかんじです。

なんと、デフォルトはJSONになってます。これも時代の流れでしょうかｗ
Solrでは、これまで設定ファイルやデータ登録もXMLがメインになっていました。（Apache Solr入門もXMLを基本に書いてます。このころはまだデフォルトでは対応してなかったので）

登録するデータをテキストエリアに記述して、「Submit Document」をクリックすればデータは登録されます。基本的には単件登録の画面でしょうか。（登録されたデータを確認するには「Query」画面を利用すればいいです。）また、JSONのデータ形式はSolrのWikiを参照してください。

CSVやXMLも

この管理画面ではJSON以外の形式でもデータの登録が可能です。「Document Type」の項目をクリックすると以下のように選択肢があられます。

CSV、XMLについては、先ほどのJSONの画面の用に、テキストエリアが表示されます。テキストエリアにCSV（データの形式はこちら）やXML（データの形式はこちら）を入力してボタンを押せば登録できます。

Solr Command形式も（JOSNかXML）

Solr Command というのはXMLやJSONで登録、コミット、削除などを実行するための画面になります。 JSONのコマンドはこちら、XMLのコマンドはこちらをご覧ください。

あと、便利なのがファイルアップロードです。こんなかんじで、ファイルを選んでSubmitすればデータが登録出来ます。

ファイルのサイズが大きいとちょっと時間がかかりますが、コマンドを打つより簡単かもしれません。 post.jarツールと違って、デフォルトでコミットをしてくれるわけではないので、「Extracting Req. Handler Params」に「commit=true」をつけないと、データが登録されてない？と思ってしまうかもしれませんが。

組立もできるみたい（Document Builder）

最後に紹介するのが「Document Builder」というタイプです。

もっと簡易にデータを記述できるようにということで用意されているようです。フィールドの情報はSolrに接続して利用できるフィールド？（ダイナミックはないのかな？）が表示されます。

追記していくとこんなかんじになります。

日本語のデータもちゃんと登録できました。ただ、まだ、開発中なんでしょうがないかもしれませんが、以下の様な制約があるようです。

multiValuedなフィールドに値を追加できない（上書きされる）
改行が入ったデータをテキストエリアにいれると「Add Field」を押しても反応しない
ダイナミックフィールドは自分で書きましょう

ただ、これまでXMLでファイルを作ってコマンドで登録したり、curlコマンドでJSON書いたりして登録していたよりはお手軽にさわれるようになるかと思います。つぎの4x系のバージョンが出たときはこちらからデータを登録してみてください。

Basho Japanに遊びに行きました

Wed, 19 Jun 2013 10:03:00 +0900

ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。

昨日は、Basho Japanに遊びに行って来ました。（Riak触ったことないのに。。。Erlangも。。。ゴメンナサイ）

RiakにSolrを組み合わせたYokozunaというものの名前を最近耳にしていたので、どんなものなのかなぁと興味がありまして。Solrがどんな使い方をされているのかってのが気になったので、情報交換したいなぁと思っていたところ、Vの人が調整してくれたので色々と有意義な話ができたかなぁと。（Yokozunaについての最新のスライドはBerlin Buzzword 2013のものがここに） Twitter上で見かけたことのある方々と話ができたり面白かったです。（やっぱ英語で会話できたりスラスラと読めるの必要だよなぁと痛感したりもしました。。。）

ということで、遊びに行ったのに美味しいピザやこんなおみやげまでもらってしまいました。（ピザの写真撮るの忘れてたw）

Riak＆Bashoグッズ

ちなみに、Yokozunaですが、Riakに登録したデータを裏で起動しているSolにデータを流しこんでくれるものになります。 Solrの機能としては分散検索（Distributed Search）と呼ばれる仕組みを利用しているようです。 YokozunaのI/Fとしては、Solrのインデックスの分散構成は隠してくれていて、かつ、Solr（っぽい？）リクエストを投げれば裏の分散構成に問い合わせた結果をSolrのレスポンスの形で返してくれます。 KVSに全文検索の機能がついてくるお得感が満載な気がしますw。

Riak自身のデータの取り扱いがどんなものかをまだちゃんと理解していないので（ゴメンナサイ。Little Riak Bookは開いてるんですが読んでなくて。。。）またおじゃましてもう少し情報交換したいかなぁとｗ。

Cloudera Searchといい、Yokozunaといい、Solrを利用したものが少しずつ増えてきて嬉しい限りです。 Solrの作りがしっかりしている？活発？、だから取り込む形が多いんですかねぇ。 Solr本を書いてから数年たちますが、やっと検索のニーズが出てきたのかもしれないなぁと思ってみたり。（流れのつながりはあまりないですが）ElasticSearchも少しずつ人気が出てきてるし、日本語の本とかのニーズあったりするかなぁ？

新しいsolr.xmlとCore探索ロジック

Tue, 11 Jun 2013 19:11:00 +0900

Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたのでメモを残しておきます。

マルチコアの設定ファイルであるsolr.xmlの記述方法と、コアの探索ロジックが4.4（実装的には4.3から入っている）から変更されるようです。4.x系の最新版である、branch_4xのexampleディレクトリにあるsolr.xmlも新しい記述に変更されていました。

参考URL

ちなみに、最後のold styleと呼ばれる4.3までの記述方法はつぎの5.0ではDeprecatedになるようです。（5.0がいつ出るのかはわからないですが。）

Core探索ロジック

4.4から、$SOLR_HOMEディレクトリ以下の探索ロジックは次のようになるようです。以下では、「新スタイル」（4.4以降の書式）、「旧スタイル」（4.3以下の書式）として記述します。

solr.xmlファイルの存在チェック
1. solr.xmlが存在しない場合→旧スタイルとして処理→3へ（旧スタイル）
2. solr.xmlが存在し<cores>タグが存在しない場合→2へ（新スタイル）
3. solr.xmlが存在し<cores>タグが存在する場合→3へ（旧スタイル）
新スタイルのロジック
1. SOLR_HOMEディレクトリに存在するディレクトリについて以下の処理を繰り返す
2. SOLR_HOME/ディレクトリ/core.propertiesファイルが存在する→後続処理へ。存在しなければ終了
3. SOLR_HOME/ディレクトリ/conf/solrconfig.xmlを読み込み、コアを起動
旧スタイルのロジック
1. これまで同様、solr.xmlの<core>タグの記載内容を元にコアを起動（instanceDir以下のconf/solrconfig.xmlを使って）
2. solr.xmlが存在しない場合はSOLR_HOME/collection1/conf/solrconfig.xmlが存在するものとしてコアを起動

このようなロジックになります。

ちなみに、以下の場合はエラーとなりSolrは起動しますがログや管理画面にエラーである表示がされます。

2.3でsolrconfig.xmlが見つけられなかった場合
3.1で<core>タグが存在しなかった場合（この場合、ログにはエラーが出ません）

propertiesに記述できる内容やsolr.xmlの記述内容については、Wikiを見てもらうということで。。。 CoreAdminHandlerでコアを生成したりした場合に、新スタイルの設定がどのように出力されるのかといった点が気になりますが、また今度にでも。

Cloudera Searchメモ（妄想版）

Thu, 06 Jun 2013 12:26:00 +0900

ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。（ユーザガイドはまだ読んでないです。）

ざっくりメモ

ストリーム処理でインデックス作るときはFlume経由でSolrに
- SinkとEventの両方が用意されてる？（Flumeを良く知らないので、違いがわからない）
- FluemeからはリモートのSolrに対してインデックス登録するクラスがある。SolrServerDocumentLoaderがソレだと思う。
バッチ処理でインデックス作るときはMapReduceIndexerToolsってのを使ってSolrに
- SOLR-1301がベースになっている。色々と改良されてるようだけど、コアとなってる処理はSOLR-1301。
- GoLiveってクラスの処理の中で、現在動作してるSolrに配布したバッチで作成されたIndexをマージする処理が書いてある。
- HDFSへ出力されたインデックスはリモートのSolrからアクセスするとオーバヘッドとかどーなるのかなぁ？
検索処理自体はHueでもできるけど、基本的にSolrCloud任せ
インデキシングの処理のフローについてはCloudera Mrophlinesで定義

ということで、 2つの流れがありそう。

HDFS→Flume→Solr
HDFS→MapReduce→Solr

で、まだ、わかってないですが、構成要素として

Hadoop（HDFS）：データソース
Hadoop（MapReduce）：データ変換処理、バッチインデキシング
Zookeeper：SolrCloudのクラスタ管理
Solr：インデキシング、検索エンジン
Flume：データをストリーミングでSolrへ
Coudera Morphlines：HDFSからSolrまでのETLデータ処理を定義実行する環境

って感じでしょうか。 SolrCloudのクラスタとHadoopのクラスタが同一マシン上なのか、別なのかとか。組み合わせがどんなものができるのかがまだわかってないです。ユーザガイド読んでみたらなにか出てくるかなぁ。

ちなみに、Cloudera SearchのgithubリポジトリにあるソースはCloudera Morphlinesのコードがメインで、SolrのHDFS対応版のソースがあるわけでは無かったです。

SolrのHdfsDirectoryってのがClouderaのリポジトリにあるSolrには追加されていて、これが、HDFSのインデックスを読み込んだりする処理が出来る仕組みっぽい。
一応、SolrCloud以外（分散検索）も考慮された形になってるっぽい。

ってとこでしょうか。

感想

読んでて思ったんですが、Cloudera Searchの肝はじつは、検索じゃなくて、Morphlinesにあるんじゃないかなぁと。今はSolrが出力先ですが、その他のデータ変換処理とかが増えてくると、処理の流れがMorphlinesで定義できてデータ変換処理が簡便になりそうな気が。

その他に気になる観点

CDH経由でSolrCloudのクラスタの管理するのかな？
SolrCloud用のクラスタとCDHのクラスタって同一マシンに載るの？別マシンにもできるの？
- 併存したらIOがキツそうだけど
Hueで検索アプリとか組めるの？（そもそもHueがわかってないんだけど。。。）

ま、とりあえず、こんなとこで。つぎは余力があれば、ユーザガイドかなぁ。英語力。。。

Cloudera Searchのモジュールたち

Wed, 05 Jun 2013 15:12:00 +0900

Cloudera Searchは次のようなモジュールから構成されています。これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使ってるみたいですね。pom.xmlを見たら何を使ってるかがわかるかな。

cdk-morphlines
search-contrib
search-core
search-flume
search-mr
search-solrcell

てきとーに、README.mdみながらメモを残してみました。ソースとかはまだ読んでないです。ざっと眺めたけど、インデキシング処理の話がメインで、検索側がどうやって動くかってのがわからなかったなぁ。ユーザガイド（注：PDF）ってのがあるから、これを読んでみるか。。。

各モジュールについては、以下。

cdk-morphlines（Cloudera Morphlines）

Cloudera Morphlinesという名前みたい。検インデキシングアプリの構築、変更をラクにするためのフレームワーク。 ETLの処理チェインを簡単にCloudera Searchにデータを入れる設定（Extract/Transform/Load処理）がかけると。バッチ処理、Near Real Timeのために使えるみたい。検索結果をさらに入れるとかもできるんかなぁ。？

Unixパイプラインのの進化版みたいなもので、一般的なレコードに対するStream処理から、Flueme、MapReduce、Pig、Hie、SqoopのようなHadoopコンポーネントも使えるみたい。

Hadoop ETLアプリケーションのプロトタイピングにも使えて、リアルタイムで複雑なStreamやイベント処理やログファイル解析とかに使えるの？

設定ファイルのフォーマットはHOCONフォーマット。AkkaやPlayで使われてる。

cdk-morphlines-core

Cloudera Morphlinesのコンパイラ、実行環境、コマンドのライブラリを含んでる。ログファイル解析やsingle-lineレコード、multi-lineレコード、CSVファイル、正規表現パターンマッチ、フィールドごとの比較とか条件分岐とか、文字列変換とか色々なコマンドを含んでる。

cdk-morphlines-avro

Avroファイルやオブジェクトの抽出、変換、読み込み処理コマンド

cdk-morphlines-tika

バイナリデータからMIMEタイプを検出して、解凍するコマンド。Tikaに依存

雑感

Cloudera Searchへのデータの流し込みを設定ファイルに記述して実行するとデータの変換処理とかが記述できるって感じかな？ Morphlinesのコマンドとして独自処理や使えそうな処理を作ることで、いろんな処理ができるって感じかなぁ。

search-core

Solrに対するMorphlineコマンドの上位モジュール

search-solrcell

Tikaパーサを使ったSolrCellを使うためのMorphlineコマンド。 HTML、XML、PDF、Wordなど、Tikaがサポートしてるものがサポート対象。

search-flume

Flueme Morphline Solr Sink。 Apache Flumeのイベントから検索ドキュメントを抽出、変換し、SolrにNearRealTimeで読み込むためのコマンド

search-mr

HDFSに保存されたファイルに含まれる大量データをMapReduceで処理してHDFS上の検索インデックスに焼きこむモジュール。

MapReduceIndexerToolは入力ファイルの集合からSolrのインデックスシャードの集合を作るためのmorphlineのタスクで、MapReduceのバッチジョブドライバー。 HDFSにインデックスを書き込む。動作してるSolrサーバに対して出力されたデータをマージするのもサポートしてる。

とりあえず、Near Real Time検索するにはFlueme使って、バッチ処理でインデックス焼くのはMapReduceIndexerToolみたいだなぁ。

Cloudera Searchってのが出たらしい（とりあえず、雑感？）

Wed, 05 Jun 2013 15:05:00 +0900

AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。英語力はあやしいので、おかしいとこがあったらツッコミを。

Cloudera Searchとは？

CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？

基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。

どんな仕組み？

次のものを利用しているようです。（GithubのREADMEから。）

使ってるもの

Apache Solr(4.3.0＋α？)
- Apache Lucene（Solrつかってるからね）
- Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？）
Apache Flume
Apache Hadoop MapReduce & HDFS
Apache Tika
- SolrCellとしてSolrにも組み込まれてる、いろんな文書（WordとかHTMLなどなど）からメタデータと本文データとかを取り出せるライブラリラッパー。実際にはさらにpdfboxとかを使って各文書からのデータを取り出してる。

何ができるの？

HBaseやHDFSの用にZookeeperを使ってインデックスのシャーディングや高可用性ができる。（SolrCloudがZookeeperを使ってるからね。） MapReduceのジョブの出力から自動的にSolrのインデックスにデータをマージできるらしい。 Cloudera Managerを使って、デプロイ、設定モニタリングなどが可能。

Flumeのフィードをつかって、ストリーミングしてインデックスを作れる。FluemeがデータをSolrに流しこむのかな？将来的にはHiveやHBaseのテーブルをインデックスすることも可能になるらしい。Impalaクエリの結果もフィードできるのか？

Apache Blurってキーワードも出てきた。HDFSのデータからLuceneのインデックス作るのかな？ NGDataのチームがSolr/HBaseの統合とかしてるみたい。

参考URL

Solr4.3.0のChangesを訳してみた。(Jugemより移植)

Thu, 25 Apr 2013 11:14:00 +0900

まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、誤訳があるかもしれないですが。おかしいとこあったらツッコミを。

○Solr 4.3.0のChanges 　・Upgrading from Solr 4.2.0 　　1.schema REST APIのcopyFields、dynamicFieldsの出力パスをCamelCaseに。他も同様。（SOLR-4623）　　2.Slf4j/logging jarをSolrのwarに含めないことに。すべてのlogging jarはexample/lib/extに。（SOLR-3706、SOLR-4651）　　3.SolrCloudでハードコードされてたhostContextとhostPortをdeprecatedに。Solr5.0で削除する。（SOLR-4622）

　・New Features 　　1.SOLR-4648　PreAnalyzedUpdateProcessorFactoryでPreAnalyzedFieldの機能をほかのフィールドタイプでも使えるようにした。詳しくはJavadocとexampleを見て。　　2.SOLR-4623　REST APIで現在のschemaのエレメントをすべて読めるように。REST APIの返却の形式として、XMLとJSONとschema.xmlの形式を追加REST APIのパッケージを変更。　　　クラス名も変更しschemaにフォーカスした機能も除去。今後のschema以外のREST APIのために。　　　copyFieldsとdynamicFieldsの出力パスをすべてlowercaseのものからCamelCaseに変更。他のREST APIも同様。　　3.SOLR-4658　REST APIリクエストでschemaを変更できるようにするために、「managed schema」を導入。solrconfig.xmlに「<schemaFactory class=“ManagedSchemaFactory” mutable=“true”/>」を追加。REST APIリクエストでスキーマ変更が可能にするために。　　4.SOLR-4656　2つのハイライトパラメータ（hl.maxMultiValuedToMatch、hl.maxMultiValuedToExamine）を追加。　　　hl.maxMultiValuedToMatchは指定された数のsnippetが見つかったらそれ以降の探索を停止する設定。multiValuedフィールドがどんなに離れてても探索する。　　　hl.maxMultiValuedToExamineは指定された数のmultiValuedのエントリ数を調査したら探索を停止する設定。　　　両方を指定した場合、最初のlimitに達したら停止する。ドキュメント全体をハイライトするためにコピーされるのを削減する。これらの最適化はmultiValuedフィールドに大量のエントリが存在する時に効く。。。　　5.SOLR-4675　PostingsSolrHighlighterでper-field/クエリ次のパラメータ指定のサポート　　6.SOLR-3755　既存のshardを動的にsplitしてshardを追加するための新コレクションAPI（shard splitting）　　7.SOLR-4530　DIH：TikaのIdentityHtmlMapperを使う設定の提供　　8.SOLR-4662　solr.xmlにあるSolrCoreの定義よりもディレクトリ構造で見つける。また、solr.xmlのフォーマットを変えて、solrconfig.xmlに近くする。Solrのこのバージョンは旧スタイルの例で提供するが、新しいスタイルも試すことができる。Solr 4.4では、新しいスタイルで提供し、Solr 5.0では旧スタイルは廃止する予定。　　　SOLR-4347　Adminハンドラで新しく生成されたコアがsolr.xmlに永続化される　　　SOLR-1905　Adminリクエストハンドラで生成されたコアもsolr.xmlに永続化される。また、solr.solr.datadirのようなプロパティの用にsolr.xmlに永続化される問題のfix。　　9.SOLR-4717/SOLR-1351　SimpleFacetで同じフィールドに異なるファセットを適用出来るlocalParamsを追加　　10.SOLR-4671　CSVResponseWriterのpseudoフィールドのサポート　　11.SOLR-4358　HttpSolrServerでuseMultiPartPostでstream名を送信できる　・Bug Fixes 　　1.SOLR-4543：solr.xml/solr.propertiesでshardHandlerFactoryの設定が動作しない　　2.SOLR-4634：Java 8"Nashorn"JavaScript実装の動作に関するscripting engineのテストのfix 　　3.SOLR-4636：SolrIndexSearcherをオープンする時に何かの理由でreaderがオープンできない時に、ディレクトリがリリースされない　　4.SOLR-4405：Admin UIのadmin-extraファイルでcore-menuが表示されない　　5.SOLR-3956：group.facet=trueでfacet.limitがマイナスの時の動作　　6.SOLR-4650：copyFieldでダイナミックフィールドや暗黙的なフィールドがsourceでマッチしない。4.2で入ったバグ　　7.SOLR-4641：Schemaで、illegalなフィールドパラメータで例外が発生するようにする。　　8.SOLR-3758：SpellCheckComponentが分散groupingで動作しない。　　9.SOLR-4652：solr.xmlプラグインのresource loaderで共有ライブラリの挙動がおかしい　　10.SOLR-4664：ZkStateReaderがaliasを更新しても見えない　　11.SOLR-4682：CoreAdminRequest.mergeIndexが複数コアやindexDirが複数の場合にマージできない　　12.SOLR-4581：Solr4.2で数値フィールドのファセットでマイナスの値があるとソートがおかしい　　13.SOLR-4699：Admin Handlerでデータディレクトリの場所がファイルシステムだと思い込んでる。（RAMの場合もある）　　14.SOLR-4695：non-cloudセットアップでもコア管理のSPLITが使えるように　　15.SOLR-4680：exampleのspellcheck設定のqueryAnalyzerFieldTypeの修正　　16.SOLR-4702：exampleの/browseの「Did you mean?」のサジェストをFix 　　17.SOLR-4710：Zookeeperから全ノードをアップせずにコレクションを削除できないのを修正　　18.SOLR-4487：HttpSolrServerからのSolrExceptionがリモートのサーバから戻るHTTPステータスコードを含んでない　　19.SOLR-4661：Admin UIのレプリケーションで現在のレプリカ可能なマスタのバージョンを正確に表示　　20.SOLR-4716,SOLR-4584：SolrCloudリクエストプロキシがTomcatなどJetty出ないコンテナで動作していない　　21.SOLR-4746：Distributed groupingのトップレベルグループコマンドでSimpleOrderedMapの代わりにNamedListを使う。non-distributed groupingと出力形式が異なるため。　　

Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)

Wed, 24 Apr 2013 16:00:00 +0900

現在、RC3のVoteをやっている最中（2013/04/24　16:00時点）で、まだリリースされていない、4.3.0についてです。開発者MLでChangesの書き方を考えないとね、みたいなエントリーが流れてて気になっていたので、訳してみた。 lucene-gosenの実装を変更しないといけないっぽいなぁ。Lucene/Solr 4.2.1以前と4.3.0でI/Fとかが変わることになりそうです。（3.とか8.とか）（ここで力尽きて、それより下はまだ読んでないです。。。）

○Changes in backwards compatibility policy 　　1.LUCENE-4810：EdgeNGramTokenFilterが同じ入力tokenから複数のngramを生成した時にpositionを増加させていないのを修正　　2.LUCENE-4822：KeywordMarkerFilterがabstractクラスで、サブクラスがisKeyword()メソッドを実装する必要がある。新しく、SetKeywordTokenFilterというクラスにすでにある機能を分解した。　　3.LUCENE-4642：TokenizerとサブクラスのAttributeSourceのコンストラクタを削除。代わりにAttributeFactoryをもつコンストラクタを追加。　　4.LUCENE-4833：IndexWriterConfigがsetMergePolicy(null)の時にLogByteSizeMergePolicyを使っているのをデフォルトmerge policyをTieredMergePolicyに。また、nullが引数に渡されたらExceptionを返す。　　5.LUCENE-4849：ParallelTaxonomyArraysをDirectoryTaxonomyWriter/Readerのためのabstractとして作成。あと、o.a.l.facet.taxonomyに移動。　　6.LUCENE-4876：IndexDeletionPolicyをInterfaceではなく、abstractクラスに。IndexDeletionPolicy、MergeScheduler、InfoStreamでCloneableをimplement。　　7.LUCENE-4874：FilterAtomicReaderと関連するクラス（FilterTerms、FilterDocsEnumなど）でフィルタされたインスタンスをforwardしないように。メソッドが他のabstractメソッドを実装している場合に。（？）　　8.LUCENE-4642, LUCENE-4877：TokenizerFactory、TokenFilterFactory、CharFilterFactoryの実装者は、少なくともMap<String,String>（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。

Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)

Fri, 13 Jul 2012 20:02:00 +0900

今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。数日前に「Solr 4.0: Partial documents update」という記事を見つけました。

Solrには、ドキュメント（RDBで言うレコード）のデータを更新したい場合には、特定のフィールドだけを更新するという機能がありませんでした。ですので、特定の項目（例えば、priceなど）を更新したい場合、ドキュメントの全データをSolrに再度上書き登録するという処理をしなければなりませんでした。 RDBを触っていた方が、Solrを始めた場合に必ず使いづらいと思われる点だと思います。

で、4.0でその機能がありますという、「Solr 4.0: Partial documents update」の記事を見つけました。ただ、SolrのWikiや4.0 ALPHAの紹介のページには「partial update」という記述が見当たりません。（あれ、これかな？Update semantics）あと、まだ完成していないので、載っていないのかもしれないです。（このチケットSOLR-139が部分更新に関するもののはず。チケット番号をみても古くから望まれている機能だということがわかります。）

ということで、調べてみました。

###機能概要

Solrの機能として、特定のフィールドのみを更新するという機能です。あくまでも、Solrレベルでの機能となり、Luceneの機能を利用したものではありません。つぎのような流れになっています。

Solrに対して特定フィールドを更新したいという形のドキュメントを投げる
Solrはドキュメントを受け取ると、内部のインデックスに保存してあるデータを取り出す
取り出したドキュメントオブジェクトに対して、更新対象フィールドの値だけデータを更新する
ドキュメントオブジェクトをインデックスに保存する

このような流れです。まぁ、言われてみれば当たり前な処理です。ただし、この機能を使う場合はいくつかの前提条件があります。

###前提条件

前提条件はつぎのとおりです。

すべてのフィールドをstored=“true"にする
「version」という特殊なフィールドを用意する

1点目は、データの保存方法についてです。先ほど流れに書きましたが、Solrが内部に保存してあるデータを取り出して、更新対象以外のデータを保存しなおしてくれます。このため、stored=“true"にしておかないと、元のデータがSolr内部で取得できません。

2点目の「version」というフィールドは4.0から導入されたフィールドです。 SolrCloudに必要な機能としてドキュメントのバージョン管理を行うために導入されたフィールドだと思います。（あまり詳しく調べていない。。。） SolrCloud内でレプリカの更新などに使ってるのかなぁと（そのうち調べます。）以上の2点が前提条件です。すべてのデータをstored=“true"としなければならない点は、インデックスのサイズや性能に関わってくるので考えて利用するほうがいいかと思います。

###利用方法

Solrのサンプルデータ（exampledocs/mem.xml）を例として利用します。部分更新を行うにはつぎのような形のデータを投げると部分更新が可能です。（JSONでの更新のサンプルについては、こちらの記事を参考にしてください。） ####XMLのサンプル（partial_update.xmlというファイルで保存する）

<add&gt;
<doc&gt;
  <field name="id"&gt;VS1GB400C3</field&gt;
  <field name="_version_"&gt;バージョン番号</field&gt;
  <field name="cat" update="add"&gt;cats_and_dogs</field&gt;
  <field name="popularity" update="inc"&gt;10</field&gt;
  <!-- set empty for SOLR-3502 bug --&gt;
  <field name="price_c" update="set"&gt;0.0,USD</field&gt;
</doc&gt;
</add&gt;

上記サンプルのうち、バージョン番号の部分は、現在Solrに登録してある値を指定します。（Solrの管理画面で検索すれば表示されます。）上記ファイルを「SOLR_HOME/example/exampledocs」に保存し、同フォルダにてつぎのコマンドを実行すると、部分更新されるのがわかります。 Solrに更新であるというフィールドがわかるように、fieldタグにupdateという属性を指定してあります。


java -Durl=http://localhost:8983/solr/update?versions=on -Dout=yes -jar post.jar partial_update.xml

ちなみに、上記post.jarのオプションで、「-Durl」「-Dout」を追加してあります。「-Durl」はverions=onというパラメータを追加したいためです。「-Dout」はPOSTした結果をターミナルに表示するために追加しています。これらのオプションを指定すると、データ更新後のバージョンが取得できるようになります。

####更新に利用できるコマンド？部分更新にはつぎの3つのコマンド？（正式名は不明）が用意されています。fieldタグのupdate属性に指定します。

コマンド？	説明
add	値を追加します。multiValuedのフィールドでない場合はエラーが出ます。
set	値を新規に登録しなおします。現在入っているデータは無くなります
inc	指定された数値を加算（数値形式のみ）

以上が、部分更新の機能になります。ちなみに、登録されているバージョンと更新データに入っているバージョンが異なる場合はエラーが発生する仕組みになっているようです。

それとは別に、この機能を調べていて、copyFieldのバグにぶつかってしまいました。。。 multiValuedでない、copyFieldを利用しているしている場合には注意が必要です。

###copyFieldのバグ（SOLR-3502）

4.0-ALPHA（3.6.0でも再現しました。）のexampleのデータで部分更新の機能を確認できると言いました。ただし、「price_c」というフィールドのせいで、2回部分更新を行うと2回目にエラーが発生します。根本的な問題は、部分更新ではなくcopyFieldのバグのようです。（部分更新の処理にも問題は有るような気がしますが。。。）

バグの内容はつぎのとおりです。

multiValued=“false"のフィールドをdestに指定
srcに指定されたフィールドに値を設定（exampleのpriceフィールドに「1」を指定）
destに指定されたフィールドに値を設定（exampleのprice_cフィールドに「2,USD」を指定）

上記のように設定した場合、「price_c」フィールドに、指定された値＋「price」の値がcopyにより追加されます。通常は「price_c」フィールドはmultiValued=“false"なのでエラーが出るはずなのですが、エラーが発生せず2つの値が登録されてしまいます。

このバグのため、exampleのデータを利用して部分更新を行うとつぎのような状態が発生します。更新を行う対象のデータはprice、price_cフィールド以外のフィールドとします。

1回目の登録後：priceフィールド「“185.0”」、price_cフィールド「“185.0,USD”」
2回目の登録後：priceフィールド「“185.0”」、price_cフィールド「[“185.0,USD”,“185.0,USD”]」
3回目の登録：エラーが発生

部分更新の処理で、すでに登録済みのデータをSolrが自動で取り出すため、2回目の登録処理にて「price_c」の登録済みの値がSolrから取り出され、さらにcopyField設定により、「price」の値が追加されます。本当は2回目の登録でエラーが発生すべきなのですが、バグのためエラーが発生せずに登録できてしまいます。部分更新の処理としては、copyフィールドのdestに指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）

autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)

Thu, 14 Jun 2012 01:09:00 +0900

久々にSolrの話です。といっても、結構前からの話でして。。。

schema.xmlのfieldTypeの設定に「autoGeneratePhraseQueries」という属性があります。 Solr3.1で導入されました。動作に関しては関口さんのブログで説明されています。 Solr 1.4までは、Analyzerがトークンを複数返してくる場合（例：lucene-gosenで「Solr入門」という文字列を入れた場合など）にフレーズクエリとして処理していました。 Lucene 3.1.0から、この処理がデフォルトfalse（つまり、フレーズクエリにならない）という挙動になりました。（詳しくは関口さんのブログで。）ただ、Solr 3.1.0では、下位互換性を考慮して、autoGeneratePhraseQueriesの設定値はデフォルトが「true」でした。

このデフォルト値がSolr 3.3以降で提供されているschemaのバージョン（1.4以上）からデフォルト値が「false」に変更されています。 schemaのバージョンを1.3以前のものから1.4以上に移行する場合は注意が必要です。

とまぁ、偉そうに書きましたが、私もちゃんと追えてませんでした。 Solr勉強会第６回で、関口さんの発表できちんと説明されていて、参加してたのに聞けてなかったですし。（メモ取ってるのに、書いてない。）

ということで、Solr入門のサンプルschemaも少し修正しました。こちらとこちらの記事に追記してありますので、参考にしてください。

Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)

Tue, 17 Apr 2012 01:16:11 +0900

先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、メモとして残しておきます。

SynonymFilterFactoryの属性「tokenizerFactory」に関連する話です。（「Apache Solr入門」の36-37ページに記載があります。）

SynonymFilterFactoryでは、類義語設定ファイルを読み込む際に利用するTokenizerFactoryを「tokenizerFactory」という属性で指定できます。（以下は書籍の記述を抜粋）


  <filter class="sold.SynonymFilterFactory" synonyms="synonyms.txt" ... tokenizerFactory="solrbook.analysis.SenTokenizerFactory"/>

このように、TokenizerFactoryが指定できます。

ただ、こちらの記事で書いたように、 Solr 3.6.0のexampleのschema.xmlではCJKのフィールドは次のように設定されています。


    <!-- CJK bigram (see text_ja for a Japanese configuration using morphological analysis) -->
    <fieldType name="text_cjk" class="solr.TextField" positionIncrementGap="100">
      <analyzer>
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <!-- normalize width before bigram, as e.g. half-width dakuten combine  -->
        <filter class="solr.CJKWidthFilterFactory"/>
        <!-- for any non-CJK -->
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.CJKBigramFilterFactory"/>
      </analyzer>
    </fieldType>

3.6.0以前は、solr.CJKTokenizerFactoryを利用していましたが、3.6.0からはCJKTokenizerFactoryがdeprecatedになってしまい、代わりにStandardTokenizerFactory＋CJKBigramFilterFactoryの組み合わせになっています。 exampleのCJKのフィールドタイプ設定を利用して、かつ、そのフィールドにSynonymFilterを利用する場合に、 StandardTokenizerFactoryを指定してしまうと、類義語が展開できなくなってしまうので注意が必要です。

CJKのフィールドでSynonymFilterを利用する場合は、類義語の設定ファイル内の記述を自力でCJKTokenizerが分割する形で記述する（まぁ、やらないでしょうが）か、deprecatedですが、CJKTokenizerFactoryを利用するのが現時点での対応でしょうか。

なお、これに絡んで、このようなチケットもできています。

SyntaxHighlighterを導入してみました。

ちょっとはみやすくなってますかね？

まだ、SyntaxHighlighterの設定を調べながら使っているので、コロコロ変わるかもしれないですが、気にしないでください。

「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)

Sat, 14 Apr 2012 02:58:00 +0900

先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。なお、前回も説明しましたが、3.6.0からKuromojiという形態素解析器がSolrに同梱されるようになりました。これから説明する2章の変更点の手順ですが、Kuromojiとlucene-gosenそれぞれの利用方法について説明します。添付のschema.xmlについては、基本的にKuromojiを利用する形に変更してあります。それに加えて、lucene-gosen用のフィールドを別途追加で定義しました。これらのフィールド名については、次の表の用になります。適宜、書籍のフィールド名と置き換えながら読み進めたり、試したりしてください。

Kuromojiフィールド	lucene-gosenフィールド
title	title_gosen
author	auther_gosen
summary	summary_gosen
intended_reader	intended_reader_gosen
from_author	from_author_gosen
toc	toc_gosen

2章

2.1.3 schema.xmlのバージョン（27ページ）

Solr3.xではschema.xmlのファイルの最新バージョンは**1.5**になっています。

2.2.3 代表的なトークナイザ（35ページ）

solrbook.analysis.SenTokenizerFactoryは必要ありません。 Solr 3.6.0からはKuromojiと呼ばれる形態素解析器が用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。これとは別に、lucene-gosenを利用する場合、Solr向けのトークナイザが用意されています。 solr.GosenTokenizerFactoryがそれに該当します。

2.2.4 代表的なトークンフィルタ（37ページ）

以下の2つについてはKuromojiが同等のトークンフィルタを提供しています。また、lucene-gosenを利用する場合は、lucene-gosenに同等のトークンフィルタが存在します。

solrbook.analysis.KatakanaStemFilterFactory
solrbook.analysis.POSFilterFactory

次のものがSolr 3.6.0に用意されているので、こちらを利用します。

solr.JapaneseKatakanaStemFilterFactory
solr.JapanesePartOfSpeechStopFilterFactory

それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。

solr.GosenKatakanaStemFilterFactory
solr.GosenPartOfSpeechStopFilterFactory

2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。

3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）

以上が4章までの修正点になります。

昨日に引き続き、眠い目をこすりながら修正したので、おかしいかも。動かない、意味がわからないなどあれば、コメントorツイートいただければと思います。

2012/06/14提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。

Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)

Sat, 14 Apr 2012 02:45:00 +0900

以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。

以下、各リリース内容について簡単に説明されているページへのリンクです。

Solrリリースのお知らせ

Luceneリリースのお知らせ

Solr 3.6.0の変更の目玉は各言語のAnalyzer/Tokenizerの設定がexampleのschema.xmlに含まれるようになったことです。 Kuromojiという日本語用の形態素解析器もexampleを起動すればすぐに利用できる形になっています。 Kuromojiを利用する場合は、exampleのschema.xmlが参考になるでしょう。

あと、大きな変更は、Ivyに対応した点です。ソースをダウンロードするとわかりますが、依存するjarファイルが含まれない形に変更されています。 SVNからチェックアウトした場合も同様です。ビルドにはネットワークに接続している環境が必要になりました。

また、このリリースに合わせて、以前書いた「Apache Solr入門」のサンプルについての記事も変更が必要かと思い、前回の記事をベースに以下に変更した記事を書いたので、参考にしてください。今回は、Kuromojiという日本語形態素解析がデフォルトで含まれるようになったので、 Kuromojiの利用方法とあわせて、lucene-gosenの利用方法も記載します。サンプルのschema.xmlについては、Kuromoji、lucene-gosenが同時に利用できる形のものを用意しました。

サンプルのschema.xmlを最新版（Solr 3.6 + lucene-gosen-2.0.0-ipadic）のものを用意しました。なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。

以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。

1章

1.6.1 N-gram（17ページ）

1.6.1の手順に変更はありません。サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりにこちらのschema.xmlを利用してください。 ※なお、Solr 3.6.0から、SOLR_HOME/example/solr/conf/schema.xmlにデフォルトでN-gramで利用しているCJKTokenizerの設定が入るようになっています。（実際にはCJKTokenizerではなく、CJKBigramFilterとCJKWidthFilterに変更されています。）

1.6.2 形態素解析（18ページ～20ページ中盤まで）

CJKと同様、exampleにKuromojiを利用した設定がすでに記述されています。text_jaというフィールドタイプになります。書籍の21ページ1行目に記載のある、「Field」のテキストボックスに入力する文字列を「text_ja」とすると、Kuromojiを利用した形態素解析結果が表示されます。exampleですでに幾つかのフィルタも設定されているため、書籍の出力結果とは異なる表示となるはずです。

lucene-gosenを利用する場合は手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。

jarファイル（lucene-gosen-2.0.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。（-Dsen.homeは必要なし）


$ java -jar start.jar

あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。ほぼ、図1-6と同じ結果になっていると思います。（lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）

2章については後日説明することにします（眠くなってきた。。。）

動作しないなどあれば、コメントください。

2012/06/14追記提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。

Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)

Tue, 08 Nov 2011 13:02:00 +0900

最近忘れやすいので、記録しておこうかと。読んだスライドの簡単な内容と感想です。ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすべてPDFへのリンクになっていますので、注意が必要です。

Solr 4 Highlights（PDF）

Solrの次期バージョン4.0で採用される機能の紹介でした。紹介されているのは次の機能。各機能について、JIRAの番号も記載があるので便利ですね。

DirectSolrSpellChecker
NRT (Near RealTime search)
Realtime Get
SolrCloud - search side
SolrCloud - indexing side (WIP)

これまでと異なるSpellChecker、Commit前のデータが検索できるNRT（なんでNRSじゃないんだろう？）、Commit前の登録済みデータを取得することが出来るRealtime Getなどの簡単な紹介です。あと、個人的に興味のあるSolrCloud周りが絵付きで紹介されてます。ZooKeeperもちょっと出てきます。まだ、ちゃんとまとめてないですが、NewSolrCloudDesignの翻訳したものも参考までに。（その１、その２）

Archive-It: Scaling Beyond a Billion Archival Web-pages

InternetArchiveの事例紹介。1996年からWebページのアーカイブを行なっているサイトですね。その一部でSolrが利用されています。「1,375,473,187 unique documents」との記述もあり、データ量が巨大です。データ量が多いのに、ここでFieldCollapsing/Groupingも利用しているようで、インデックス作成、検索両方に対してカスタマイズしたものをgithubで公開している模様です。

[**Scaling search at Trovit with Solr and Hadoop**](http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/MarcSturlese_scalingsearchTrovit_eurocon2011.pdf)

次は、Trovitという会社のSolr＋Hadoopの事例紹介です。最初はLuceneをベースに検索サーバ作ってたけど、Solrが出てきたので、Solrを使うようになったようで。データ保存先として最初はMySQLを利用してDataImportHandlerでSolrにデータ登録してたけど、データ量が増加するが、MySQLのShardingが面倒なので、Hadoop（Hive）でデータをパイプライン処理してSolrのインデックスを作成しましょうという流れになったようです。私が以前、Solr勉強会で紹介したSOLR-1301のパッチをベースにMap/Reduceの処理を2段階にして性能をアップさせたという話が記載されてました。ただ、これで早くなるのかはよくわからないんですが。。。一応、資料では、いきなり大きなSolrのインデックスを作らずに、最初のM/Rで小さなインデックスを作成し（TaskTrackerの数＞＞Solrのshardサーバ数だから小さくしたほうが速い？）、 2段目のM/Rでインデックスをマージしてshardサーバ数のインデックスに集約する？という形みたいです。（英語力のなさが。。。）あとは、テキスト処理を幾つかHadoopでやってますよという紹介でした。 SOLR-1301の利用者が他にもいて、違うアプローチをとっていたのが印象的。毎回全データインデックス生成するときは、SOLR-1301を利用してshard数が増えてもすぐに対応が可能になるので、かなり便利ですよ。

Solr @ Etsy

Etsyは個人の作家（編み物とかシールとか）の方が出店するためのショッピングモールのようなサイトです。実は、最近、MacBookAirのステッカーを購入したのがここでした。で、検索にSolrを使っています。面白いのが、検索サーバとWebアプリ（PHPで書かれている）の間のデータのやり取りにThriftを利用していること。 Solrの前にThriftを話すサーバを別途用意しているようです。ネットワークのデータ量を減らすことが目的らしいです。そのあとは、少しThriftのサーバでのLoadBalancingの話が続きます。次にレプリケーションの性能問題のはなし。定期的にレプリケーションに異様に時間がかかるのが問題になったようで、 Multicast-Rsyncを試してみたけどダメでしたというはなし。 Bit Torrent + Solrという組み合わせで回避したらしいのですが、いまいち仕組みがわからなかったです。。。こちらもgithubに公開されている模様。あとは、QParser、Stemmerをカスタマイズしたものの話です。

Architecting the Future of Big Data and Search

LuceneのカンファレンスにHortonworksが出てきてびっくりしました。まぁ、Luceneの生みの親＝Hadoopの生みの親ですから、問題ないのかもしれないですが。大半が予想通り、Hadoopに関する話でした。知らないApacheのプロジェクト「Ambari」というのが出てきました。これは、HadoopConferenceJapan2011 Fallでの発表にもチラッと出てきたようです。「Ambari is a monitoring, administration and lifecycle management project for Apache Hadoop clusters.」ということで、Hadoopクラスタの統合管理のツールになるんでしょうか？最後の2枚くらいにLuceneが出てきます。絡めてみたって感じですかね。

Configuring mahout Clustering Jobs

今度はMahoutが出てきました。はやりのものが満載です。まぁ、MahoutもLuceneのインデックスを利用するという話もありますので。スライドはクラスタリングとはどういうものか、Mahoutの説明とテキストクラスタリング処理のお話、最後はstuckoverflowでのMahoutとSolrの活用の仕方について。

ということで、英語力がない中、かなり流し読みな感じですが、あとで思い出すために書きだして見ました。何かの役に立てれば幸いです。

他に、こんなスライドが面白かったとか、このスライドについても書いてほしいなどあれば、コメントください。

Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)

Wed, 05 Oct 2011 19:43:00 +0900

Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。ほんとにちょっと触っただけですが、いくつかキャプチャ撮ってみたので、アップしときます。 ※以下ではサムネイル画像に元画像（100Kくらいの画像）へのリンクが設定されています。携帯などでは見づらいかもしれませんが、ご容赦を。

URLは旧管理画面とことなり、http://localhost:8983/solr/になります。

まずはトップ画面ダッシュボードと呼ばれるトップ画面。メモリの利用率や起動してからの時間、Luceneなどのバージョンが表示されます。

次は検索画面すっきりしてます。facetが指定できるようになったのは大きいかな。ただし、facet.fieldを複数指定などができないが。結果についてはとくに指定がなければXMLで帰ってきます。ただ、パラメータの追加ができなくなってる気がするなぁ

ちなみに、Solrを止めて検索したらこんな感じの画面になりました。クエリの実行ならこのようにエラーがわかったのですが、停止後に左のメニューにあるSchemaなどをクリックしても白い画面が出るだけで、エラーかどうかがわかりにくいです。

Analysis画面。入力画面がシンプルになりました。フィールド名はリストで表示されるので選択するだけです。あとは、これまでどおり。サンプルはlucene-gosenの解析結果です。ハイライトもきちんと表示されます。ただし、長い文章の場合は結果部分だけがスクロールできる形になり、ちょっとわかりにくかったです。

Analysisの入力画面を表示したあとにSolrを停止して解析してみたらこんなエラー画面が出ました。ちなみに、その後、画面を切り替えずにSolrを起動して解析したら、赤い帯のエラーは出たままでした。一度別画面にすれば、元に戻りますが。

Pluginsの画面（旧管理画面のstatisticsに相当）。キャッシュの状態が確認できます。今まであった画面と情報的には一緒かと。一段カテゴリ（CACHEとかCOREとか）の選択ができるようになり、見やすくなりました。

同じくPluginsの画面。こちらはupdateHandlerについての情報です。commit数やoptimizeの回数、updateして、commitする前の状態のドキュメント数などが表示されます。前より表示される項目が多くなってるかな？

最後はスキーマブラウザこの画面が一番良くなっています。旧管理画面では、フィールド名がすべて大文字で表示され、しかもソートがされていない状態だったため、ダイナミックフィールドを利用しているとフィールドを探すのが一苦労でした。今回は、プルダウンでフィールドやフィールドタイプのリストが表示され、辞書順で並んでいます。Filterなどもわかりやすい表示になっているかと。

おまけ

Solritasと呼ばれるVelocityを使った、3.x系で入ってきた新しいサンプル画面です。URLはhttp://localhost:8983/solr/browseです。ファセットなどを使った簡単なサンプル画面なので、検索結果画面でこんなことができるというデモにも使えるかと。ただ、これも旧管理画面よりはましですが、デザインが。。。

とまぁ、簡単ですが、4.x系の管理画面をいくつか触ってみて、キャプチャをとって見ました。デザインは前よりもすっきりしています。ただ、クエリについてはパラメータの追加ができなくなっているので、もう少し改良されるといいかなぁ（自分でやれよと言われそうですが。。。）

New SolrCloud Designの翻訳（その2）(Jugemより移植)

Tue, 04 Oct 2011 18:32:00 +0900

遅くなりましたが、続きです。さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。

一応、訳してみたのですが、訳すのに必死になってしまい、つながりがわかっていない点もちらほら。このあと一旦見直しつつ、再度理解する「理解編」をアップしようかと思います。できれば、シーケンス図とかも交えつつ。（そうしないと理解ができない可能性が。。。）前回同様、原文は最後に付加しておきます。

Boot Strapping

Cluster Startup（クラスタの起動）

ノードはZookeeperのホストとポートを指定することから始めます。クラスタの最初のノードはクラスタのschema/configとクラスタの設定を指定するとこから開始します。最初のノードはZookeeperに設定をアップロードしてクラスタをブートします。クラスタは「ブートストラップ」状態です。この状態ではノード->パーティションマッピングは計算されず、クラスタはクラスタ管理コマンド以外のどんなread/writeリクエストも受け付けません。

クラスタの最初のノード集合が起動した後、クラスタ管理コマンド（TBD記述？？？）が管理者によって発行されます。このコマンドは整数「partitions」パラメータを受け取り、次のステップを実行します。

Cluster Lockを取得
「partitions」をパーティション数として割り当て
各パーティションのためのノードを取得
ZooKeeperのノード->パーティションマッピングを更新
Cluster Lockをリリース
全ノードに対して最新版のノード->パーティションマッピングをZooKeeper経由で更新させる

Node Startup

ノードが起動すると、自分がすでに存在するシャードの一部かどうかZooKeeperでチェックします。もし、ZooKeeperがノードのレコードを持っていない、またはどのシャードの一部でもないと判断したら、ノードは後述の「New Node」のステップを実行します。すでに存在するノードの場合は後述の「Node Restart」のステップを実行します。

New Node

新しいノードはクラスタの一部ではなく、クラスタのキャパシティを増強するためのものです。

「auto_add_new_nodes」クラスタプロパティが「false」の場合、新しいノードはZooKeeperに「idle」として登録され、他のノードが参加してくれと言うまで待機します。そうでない場合（auto_add_new_nods=true）は次のステップを実行します。

Cluster Lockを取得します。
適切なnode->partitionエントリを選び出します。
利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。
全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。
もし、選んだノード->パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。
ZooKeeper内のノード->パーティションマッピングを更新します

ZooKeeper内のノードステータスを「リカバリ」状態にします

Cluster Lockをリリースします

「リカバリ」はパーティションのリーダーから開始します。

リカバリが終了したら、再度、Cluster Lockを取得します。

元のエントリはZooKeeperのノード->パーティションマッピングから削除されます。

Cluster Lockをリリースします

元のノードはZooKeeperからノード->パーティションマッピングを更新させられます

ステップ1に戻ります。

Node Restart

ノードの再起動とは次のいずれかを意味しています。

JVMがクラッシュし、手動または自動でのリスタート
ノードが一時的にネットワークから切り離された。もしくは、ZooKeeperに接続できなかった（死んでいると思われた）。または、ある一定期間、リーダーからの更新を受信できなかった。
このシナリオが表す書き込み処理のライフサイクルの間にネットワークから分断された
ハード故障もしくはメンテナンスウインドウによりクラスタからノードが分断され、ノードをクラスタにrejoinさせるために起動した。

ノードが各パーティションに対してメンバーであるパーティションのリストを読み、パーティションのリーダーがリカバリプロセスを実行する。その時、ノードは「auto_add_new_nods」プロパティをチェックして、「New Node」処理のステップを実行する。これはクラスタが。。。（元の文章が切れてて意味が不明）

クライアントは標準的なSolrの更新形式を利用して書き込みできます。書き込み処理はクラスタの任意のノードに送信されます。ノードはハッシュ関数を利用して、どのパーティションに所属するか決めるためにrange-パーティションマッピングを使います。 ZooKeeperはシャードのリーダーを識別して、書き込み処理をそこに送ります。 SolrJはリーダーに対して書き込みを直接送信するための拡張がされています。

リーダーはPartitionバージョンの操作を割り当て、そのトランザクションログの操作を書き込み、シャードに属する他のノードにドキュメントバージョンハッシュを転送します。ノードはインデックスにドキュメントハッシュを書き込み、トランザクションログに操作を記録します。リーダーは、min_writesの最小数のノード以上のノードが「OK」とレスポンスを返したら「OK」とレスポンスを返します。クラスタプロパティのmin_writesは書き込みリクエスト時に指定することで、異なる値を指定できます。

クラウドモードはコミット/ロールバック操作を明示的には行いません。コミットは特定の間隔で（commit_within）リーダーによりオートコミットにより管理されます。また、シャードの全メンバーのコミットはトリガーにより管理されます。ノードが利用可能な最新バージョンはコミットの時点で記録されます。

Transaction Log

トランザクションログは2つのコミットの間にインデックスに対して実行された操作全てを記録したもの
コミットはそれ以前に実行された操作の耐久性を保証するために、新しいトランザクションログを開始します。
同期は調整が可能です。例えば、flush vs fsynです。fsyncがデフォルトで、JVMクラッシュに対して保証できるが、電源異常の場合には保証できないが、速度的には早いです。

Recovery

次のトリガーにより復旧が可能です。

Bootstrap
パーティション分割
クラスタの再構築

ノードは自身に「recovering」というステータスを設定して復旧を開始します。このフェーズの間、ノードは読み込みリクエストを受けることができませんが、トランザくkションログに書きこまれるすべての新しい書き込みリクエストを受け取ります。ノードは自身が持つインデックスのバージョンを調べて、パーティションの最新バージョンのリーダーに問い合わせます。リーダーはシャード内の残りのノードと同期する前に実行されるべき操作の集合を返します（？？？）。

最初にインデックスをコピーし、最新のノードにあるトランザクションログをリプレイします。もし、インデックスのコピーが必要ならば、インデックスファイルをローカルにまずコピーし、その後トランザクションログをリプレイします。トランザクションログのリプレイは通常の書き込みリクエストの流れと同じです。この時、ノードは新しい書き込みを受け付けるかもしれません。その書き込みはインデックスに再生されるべきです。ある時点でノードは最新のコミットポイントに追いつき、自身のステータスを「ready」にします。この時点で、このノードは読み込みリクエストを処理できます。

Handling Node Failures

一時的にネットワークが分断され、幾つかのノードとZooKeeperの間の通信が遮断されるかもしれません。クラスタはデータの再構築（リバランシング）の前にしばらく待ちが発生します。

Leader failure

ノードが故障し、もしそれがシャードのリーダだった場合、他のメンバーがリーダー選出のプロセスを開始します。新しいリーダーが選出されるまで、このパーティションへの書き込みは受け付けられません。この時、これはリーダー以外の故障ステップを処理します。（？？？）

Leader failure

シャードの一部に新しいノードが割り当てられる前にリーダーはmin_reaction_timeの間待ちます。リーダーはCluster Lockを取得し、シャードの新規メンバーとしてノードを割り当てるためのノード-シャード割り当てアルゴリズムを使用します。 ZooKeeperのノード->パーティションマッピングが更新され、Cluster Lockがリリースされます。新しいノードはZooKeeperからノード->パーティションマッピングを強制的にリロードされます。

Splitting partitions

明示的なクラスタ管理コマンドもしくはSolrによる自動的な分割戦略（ストラテジ）はパーティションを分割することができます。明示的な分割コマンド（split command）は対象となるパーティションを分割するために実行されます。

パーティションXが100から199のハッシュの範囲を持つものとし、X（100から149）、Y（150～199）に分割するとします。 Xのリーダーは、XとYの新しい値の範囲をZooKeeperに分割アクションを記録します。ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）

XのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション->ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。
Xのリーダーは分割が完了するまですべてのコミットを停止します。
Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます
XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。
Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？
Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。
#5で作成されたインデックスはYのリーダーに送られ、登録されます。
Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。
パーティションYのすべてのノードがバージョンVに到達したならば
YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。
Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ->パーティションマッピングを変更します。
YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます
YのリーダーはXのリーダーに、ZooKeeperからレンジ->パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。

Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。

この時点で分割は完全に終了し、Xのリーダーはcommit_withinパラメータによるコミットをレジュームします（？？？）

Notes:

分割操作が完了するまで、commit_withinパラメータによるパーティションの分割は実行されない
#8b開始から#8c終了までの間の分散検索は一貫しない検索結果を帰す場合がある（例えば：検索結果が異なる）

Cluster Re-balancing

クラスタは明示的なクラスタ管理コマンドにより再構築（リバランシング）できる。

TBD （to be determined）

Cluster Re-balancing

TBD （to be determined）

Configuration

solr_cluster.properties

これはクラスタ内の全ノードにわたって適用される一般的なSolr設定ファイルとは別のプロパティファイルの集合である。

replication_factor：クラスタによって管理されるドキュメントのレプリカの数
min_writes：書き込み操作が成功になる前の最小の書き込み？？？？。これは書き込みごとに上書き設定可能
commit_within：検索に現れるまでの書き込み操作の最大回数
hash_function：ドキュメントのハッシュ値を計算するための関数の実装
max_hash_value：ハッシュ関数が出力することができる最大値。理論的には、この値はクラスタが保持できるパーティションの最大数でもある
min_reaction_time：起動、停止の後に再配分/分割にかかる時間（？？）
min_replica_for_reaction：レプリカノード数がこの値以下になったら、min_reaction_timeにならなくても分割が実行される。
auto_add_new_nodes：booleanフラグ。もしtrueなら新しいノードは自動的にパーティションからレプリカを読み込む。そうでない場合は新しいノードはクラスタに「idle」状態で登録される

Cluster Admin Commands

すべてのクラスタ管理コマンドはすべてのノードでパス（/cluster_admin）を与えることで実行できます。全ノードは同じコマンドを受け付けることができ、振る舞いも同じものになるでしょう。以下のコマンドはユーザが利用できるパブリックなコマンドです。

init_cluster：（パラメータ：パーティション）このコマンドはノードの集合の初期化後に実施されます。このコマンドが実行されるまで、クラスタは読み込み/書き込みコマンドを受け付けません。
split_partition：（パラメータ：パーティション（任意））パーティションを2つに分割します。もしパーティションパラメータが指定されない場合は、ドキュメント数が最大の
add_idle_nodes：このコマンドはauto_add_new_nodes=falseの場合に利用できます。このコマンドはクラスタに対して「idle」状態のすべてのノードを追加するトリガーとなります。
move_partition：（パラメータ：パーティション、from、to）fromのノードからtoの別のノードに引数で指定されたパーティションを移動します。
command_status：（パラメータ：completion_id（任意））上記コマンドはすべて非同期で実行され、completion_idを返します。このコマンドは特定の実行中のコマンドもしくは全ての実行中のコマンドの状態を表示するために利用できます。
status：（パラメータ：パーティション（任意））パーティションのリストを表示し各パーティションの次の情報を表示します。
リーダーノード
ノードのリスト
ドキュメント数
平均読み込み回数（reads/sec）
平均書き込み回数（writes/sec）
平均読み込み時間（time/read）
平均書き込み時間（time/write）

Migrating from Solr to SolrCloud

クラウドに移行するときに幾つかの特徴は不要かもしれないし、サポートされないかもしれません。既存の（クラウドでない）バージョンでのすべての特徴をSolrCloudでサポートし続けなければなりません。

レプリケーション：これは必要ありません。
CoreAdminコマンド：明示的なコアの操作は許可されません。内部にコアがあるかもしれないが、暗黙的に管理されるでしょう
複数スキーマのサポート？：単純化のため、ver1.0ではサポートしないかもしれない
solr.xml：SolrCloudでほんとに必要？

Alternative to a Cluster Lock

リーダーを選出する常設の調停ノード（masterはインデックスレプリケーションで利用している用語なので、「調停」とする）を持つほうが単純かもしれません。「truth」状態をZookeeperの状態としてみなすような次のパターンでは、将来の柔軟性（クラスタを制御するためのZookeeperの状態を直接変更するような外部管理ツールのような）を考慮に入れることができます。（毎回ロックを取得するよりも）調停ノードを持つことにより、よりスケーラブルになるかもしれません。特定条件下でのみCluster Lockを利用するハイブリッドも意味があるでしょう。

Single Node Simplest Use Case

単一ノードでスタートして、ドキュメントをインデックス登録できないといけません。また、あとで、クラスタに2番目のノードを追加できないと行けません。

1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。
他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。

いくつかのドキュメントをインデックスします

他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。 * 出来れば、同一ホスト上に同じシャードはコピーしない * この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば）

原文はこちらからです。

Boot Strapping

Cluster Startup

A node is started pointing to a Zookeeper host and port. The first node in the cluster may be started with cluster configuration properties and the schema/config files for the cluster. The first node would upload the configuration into zookeeper and bootstrap the cluster. The cluster is deemed to be in the “bootstrap” state. In this state, the node -> partition mapping is not computed and the cluster does not accept any read/write requests except for clusteradmin commands.

After the initial set of nodes in the cluster have started up, a clusteradmin command (TBD description) is issued by the administrator. This command accepts an integer “partitions” parameter and it performs the following steps:

Acquire the Cluster Lock
Allocate the “partitions” number of partitions
Acquires nodes for each partition
Updates the node -> partition mapping in ZooKeeper
Release the Cluster Lock
Informs all nodes to force update their own node -> partition mapping from ZooKeeper
The Cluster Lock is acquired
A suitable source (node, partition) tuple is chosen:
The list of available partitions are scanned to find partitions which has less then “replication_factor” number of nodes. In case of tie, the partition with the least number of nodes is selected. In case of another tie, a random partition is chosen.
If all partitions have enough replicas, the nodes are scanned to find one which has most number of partitions. In case of tie, of all the partitions in such nodes, the one which has the most number of documents is chosen. In case of tie, a random partition on a random node is chosen.
If moving the chosen (node, partition) tuple to the current node will decrease the maximum number of partition:node ratio of the cluster, the chosen tuple is returned.Otherwise, no (node, partition) is chosen and the algorithm terminates
The node -> partition mapping is updated in ZooKeeper

The node status in ZooKeeper is updated to “recovery” state

The Cluster Lock is released

A “recovery” is initiated against the leader of the chosen partition

After the recovery is complete, the Cluster Lock is acquired again

The source (node, partition) is removed from the node -> partition map in ZooKeeper

The Cluster Lock is released

The source node is instructed to force refresh the node -> partition map from ZooKeeper

Goto step #1

Node Restart

A node restart can mean one of the following things:

The JVM crashed and was manually or automatically restarted
The node was in a temporary network partition and either could not reach ZooKeeper (and was supposed to be dead) or could not receive updates from the leader for a period of time. A node restart ine node failure.
Lifecycle of a Write Operation this scenario signifies the removal of the network partition.
A hardware failure or maintenance window caused the removal of the node from the cluster and the node has been started again to rejoin the cluster.

The node reads the list of partitions for which it is a member and for each partition, starts a recovery process from each partition’s leader respectively. Then, the node follows the steps in the New Node section without checking for the auto_add_new_nodes property. This ensures that the cluster recovers from the imbalance created by th

Writes are performed by clients using the standard Solr update formats. A write operation can be sent to any node in the cluster. The node uses the hash_function , and the Range-Partition mapping to identify the partition where the doc belongs to. A zookeeper lookup is performed to identify the leader of the shard and the operation is forwarded there. A SolrJ enhancement may enable it to send the write directly to the leader

The leader assigns the operation a Partition Version and writes the operation to its transaction log and forwards the document + version + hash to other nodes belonging to the shard. The nodes write the document + hash to the index and record the operation in the transaction log. The leader responds with an ‘OK’ if at least min_writes number of nodes respond with ‘OK’. The min_writes in the cluster properties can be overridden by specifying it in the write request.

The cloud mode would not offer any explicit commit/rollback operations. The commits are managed by auto-commits at intervals (commit_within) by the leader and triggers a commit on all members on the shard. The latest version available to a node is recorded with the commit point.

Transaction Log

A transaction log records all operations performed on an Index between two commits
Each commit starts a new transaction log because a commit guarantees durability of operations performed before it
The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster

Recovery

A recovery can be triggered during:

Bootstrap
Partition splits
Cluster re-balancing

The node starts by setting its status as ‘recovering’. During this phase, the node will not receive any read requests but it will receive all new write requests which shall be written to a separate transaction log. The node looks up the version of index it has and queries the ‘leader’ for the latest version of the partition. The leader responds with the set of operations to be performed before the node can be in sync with the rest of the nodes in the shard.

This may involve copying the index first and replaying the transaction log depending on where the node is w.r.t the state of the art. If an index copy is required, the index files are replicated first to the local index and then the transaction logs are replayed. The replay of transaction log is nothing but a stream of regular write requests. During this time, the node may have accumulated new writes, which should then be played back on the index. The moment the node catches up with the latest commit point, it marks itself as “ready”. At this point, read requests can be handled by the node.

Handling Node Failures

There may be temporary network partitions between some nodes or between a node and ZooKeeper. The cluster should wait for some time before re-balancing data.

Leader failure

If node fails and if it is a leader of any of the shards, the other members will initiate a leader election process. Writes to this partition are not accepted until the new leader is elected. Then it follows the steps in non-leader failure

Non-Leader failure

The leader would wait for the min_reaction_time before identifying a new node to be a part of the shard. The leader acquires the Cluster Lock and uses the node-shard assignment algorithm to identify a node as the new member of the shard. The node -> partition mapping is updated in ZooKeeper and the cluster lock is released. The new node is then instructed to force reload the node -> partition mapping from ZooKeeper.

Splitting partitions

A partition can be split either by an explicit cluster admin command or automatically by splitting strategies provided by Solr. An explicit split command may give specify target partition(s) for split.

Assume the partition ‘X’ with hash range 100 - 199 is identified to be split into X (100 - 149) and a new partition Y (150 - 199). The leader of X records the split action in ZooKeeper with the new desired range values of X as well as Y. No nodes are notified of this split action or the existence of the new partition.

The leader of X, acquires the Cluster Lock and identifies nodes which can be assigned to partition Y (algorithm TBD) and informs them of the new partition and updates the partition -> node mapping. The leader of X waits for the nodes to respond and once it determines that the new partition is ready to accept commands, it proceeds as follows:
The leader of X suspends all commits until the split is complete.
The leader of X opens an IndexReader on the latest commit point (say version V) and instructs its peers to do the same.
The leader of X starts streaming the transaction log after version V for the hash range 150 - 199 to the leader of Y.
The leader of Y records the requests sent in #2 in its transaction log only i.e. it is not played on the index.
The leader of X initiates an index split on the IndexReader opened in step #2.
The index created in #5 is sent to the leader of Y and is installed.
The leader of Y instructs its peers to start recovery process. At the same time, it starts playing its transaction log on the index.
Once all peers of partition Y have reached at least version V:
The leader of Y asks the leader of X to prepare a FilteredIndexReader on top of the reader created in step #2 which will have documents belonging to hash range 100 - 149 only.
Once the leader of X acknowledges the completion of request in #8a, the leader of Y acquires the Cluster Lock and modifies the range -> partition mapping to start receiving regular search/write requests from the whole cluster.
The leader of Y asks leader of X to start using the FilteredIndexReader created in #8a for search requests.
The leader of Y asks leader of X to force refresh the range -> partition mapping from ZooKeeper. At this point, it is guaranteed that the transaction log streaming which started in #3 will be stopped.

The leader of X will delete all documents with hash values not belonging to its partitions, commits and re-opens the searcher on the latest commit point.

At this point, the split is considered complete and leader of X resumes commits according to the commit_within parameters.

Notes:

The partition being split does not honor commit_within parameter until the split operation completes
Any distributed search operation performed starting at the time of #8b and till the end of #8c can return inconsistent results i.e. the number of search results may be wrong.

Cluster Re-balancing

The cluster can be rebalanced by an explicit cluster admin command.

TBD

Monitoring

TBD

Configuration

solr_cluster.properties

This are the set of properties which are outside of the regular Solr configuration and is applicable across all nodes in the cluster:

replication_factor : The number of replicas of a doc maintained by the cluster
min_writes : Minimum no:of successful writes before the write operation is signaled as successful . This may me overridden on a per write basis
commit_within : This is the max time within which write operation is visible in a search
hash_function : The implementation which computes the hash of a given doc
max_hash_value : The maximum value that a hash_function can output. Theoretically, this is also the maximum number of partitions the cluster can ever have
min_reaction_time : The time before any reallocation/splitting is done after a node comes up or goes down (in secs)
min_replica_for_reaction : If the number of replica nodes go below this threshold the splitting is triggered even if the min_reaction_time is not met
auto_add_new_nodes : A Boolean flag. If true, new nodes are automatically used as read replicas to existing partitions, otherwise, new nodes sit idle until the cluster needs them.

Cluster Admin Commands

All cluster admin commands run on all nodes at a given path (say /cluster_admin). All nodes are capable of accepting the same commands and the behavior would be same. These are the public commands which a user can use to manage a cluster:

init_cluster : (params : partition) This command is issued after the initial set of nodes are started. Till this command is issued, the cluster would not accept any read/write commands
split_partition : (params : partitionoptional). The partition is split into two halves. If the partition parameter is not supplied, the partition with the largest number of documents is identified as the candidate.
add_idle_nodes : This can be used if auto_add_new_nodes=false. This command triggers the addition of all ‘idle’ nodes to the cluster.
move_partition : (params : partition, from, to). Move the given partition from a given node from to another node
command_status :(params : completion_idoptional) . All the above commands are asynchronous and returns with a completion_id . This command can be used to know the status of a particular running command or all the current running commands
status : (params : partitionoptional) Shows the list of partitions and for each partition, the following info is provided
leader node
nodes list
doc count
average reads/sec
average writes/sec
average time/read
average time/write

Migrating from Solr to SolrCloud

A few features may be redundant or not supported when we move to cloud such as. We should continue to support the non cloud version which supports all the existing features

Replication. This feature is not required anymore
CoreAdmin commands. Explicit manipulation of cores will not be allowed. Though cores may exist internally and they meay be managed implicitly
Multiple schema support ? Should we just remove it from ver 1.0 for simplicity?
solr.xml . Is there a need at all for this in the cloud mode?

Alternative to a Cluster Lock

It may be simpler to have a coordinator node (we avoid the term master since that is associated with traditional index replication) that is established via leader election. Following a pattern of treating the zookeeper state as the “truth” and having nodes react to changes in that state allow for more future flexibility (such as allowing an external management tool directly change the zookeeper state to control the cluster). Having a coordinator (as opposed to grabbing a lock every time) can be more scalable too. A hybrid model where a cluster lock is used only in certain circumstances can also make sense.

Single Node Simplest Use Case

We should be able to easily start up a single node and start indexing documents. At a later point in time, we should be able to start up a second node and have it join the cluster.

start up a single node, upload it’s configuration (the first time) to zookeeper, and create+assign the node to shard1. in the absence of other information when the config is created, a single shard system is assumed index some documents start up another node and pass it a parameter that says “if you are not already assigned, assign yourself to any shard that has the lowest number of replicas and start recovery process” avoid replicating a shard on the same host if possible after this point, one should be able to kill the node and start it up again and have it resume the same role (since it should see itself in zookeeper)

New SolrCloud Designの翻訳（その１）(Jugemより移植)

Wed, 28 Sep 2011 20:45:00 +0900

ちょっと興味があるので、訳してみました。（Wikiのページはこちら）更新されているようなので、もとの文章も残しておきます。（ページ下部の続きはこちら部分以降）全部訳そうと思ったのですが、終わらなかったので、まずは前半部分です。まだ、訳しただけで理解できてない。。。（英語力のなさをさらけ出してしまうのですが、これも修行です。。。おかしいところはツッコミを。）

What is SolrCloud?

Solrクラウドはクラウドでの検索サービスとしてのSolrを管理、運用するための既存のSolrを拡張するものです。

用語集

Cluster：クラスタは1単位として管理されるSolrノードの集合です。クラスタ全体で単一のschema、solrconfigをもたないといけません。
Node：ひとつのJVMインスタンスで起動しているSolrのこと
Partition：パーティションはドキュメント集合全体のサブセット（部分集合）のことです。パーティションは部分集合のドキュメントが単一のインデックスに含まれるような形で作られます。
Shard：パーティションはn（＝replication factor）個のノードに保存される必要があります。このn個のノードすべてでひとつのshardです。1つのノードはいくつかのshardの一部にで有る場合があります。
Leader：各Shardは1つのリーダとなるノードを持っています。パーティションに登録されたドキュメントリーダーからコピーされます
Replication Factor：クラスタによって保持されるレプリカの最小限の数
Transaction Log：各ノードによって保持される書き込み処理の追記ログ
Partition version：これは各shardのリーダーが持っているカウンターで、書き込み処理ごとに増加し、レプリカに送られます。
Cluster Lock：これはrange（※後述されているハッシュ値の範囲のことか？）->パーティションもしくはパーティション->ノードのマッピングを変更するために取得しなければいけないグローバルなロックのことです。

※用語だけだと関係がわかりづらかったので、図を書いてみました。

ドキュメントの集合とパーティションについての考え方

クラスタ、ノード、シャードの考え方。

処理原則

任意の処理はクラスタにある任意のノードに実行可能です。
リカバリできないSPOFはありません。
クラスタは伸縮自在（elastic）でなければならない
書き込みが失われないこと（耐久性）を保証する
書き込み順序が保証されなければならない
2つのクライアントが2つの「A」というドキュメントを同時に送信してきた場合、すべてのレプリカで一貫してどちらか一方が保存されなければならない。
クラスタの設定は中央管理されなければならない。また、クラスタのどのノードからもクラスタ設定が更新できます。
読み込み（検索）の自動的なフェイルオーバー
書き込み（インデクシング）の自動的なフェイルオーバー
ノードの故障が発生しても自動的にrepcation factorの数は守られます。（故障したら動的にレプリカを再配置？）

Zookeeper

ZooKeeperクラスタは次のために使用されます。

クラスタ設定の集中管理
分散同期に必要な操作のコーディネータ
クラスタ構成を保存するためのシステム

Partitioning

クラスタは固定されたmax_hash_value＝「N」が設定されます。 max_hash_valueは1000のような大きな値が設定されます。


hash = hash_function(doc.getKey()) % N

ハッシュ値の範囲がパーティションに割り当てられ、ZooKeeperに保存されます。次の例のような形で、パーティションに対して範囲が設定されます。


range  : partition
------  ----------
0 - 99 : 1
100-199: 2
200-299: 3

ハッシュはドキュメントにインデックスフィールドとして追加され、変更されない値です。これは、インデックスを分割するときにも利用します。

ハッシュ関数はプラガブルです。これはドキュメントを受け取り、一貫した正整数ハッシュ値を返します。デフォルトのハッシュ関数として、必須でかつ変更されないフィールド（デフォルトはユニークキーフィールド）からハッシュ値を計算する関数が提供されます。

Using full hash range

max_hash_valueは必ずしも必要ではありません。各shardはいずれにしろハッシュ値の範囲持っているので、完全な32 bitsハッシュを使うこともできます。設定可能なmax_hash_valueを利用しないで、クライアントからの値をもとにハッシュ値を作ることができます。例えば、電子メールの検索アプリでは次のようにハッシュ関数を作ることができます。


(hash(user_id)<<24) | (hash(message_id)>>>8)

ユーザIDから8bitのハッシュコードの先頭8ビットを利用することで、任意のユーザのメールがクラスタの同じ256番目（のノード？）にあるのを保証します。検索時はこの情報をもとにクラスタのその部分への問い合わせだけで情報が得られます。

おそらく、私たちは最大値から最小値をカバーする範囲を表現するのにハッシュ空間を輪（固定のハッシュではなく）とみなしたいです。（？？？円状のハッシュ空間とすることで、クラスタ内のノード数の増減に耐えられるようにするよということかな？）

shard naming

シャードからハッシュ値の範囲へのマッピングを別々に管理するよりも、ハッシュコードによりパーティションを構成するときに実際にはハッシュの範囲をシャード名にします。（シャード「1-1000」は1から1000の間のハッシュコードを持つドキュメントが含まれるという形）

現時点では（コレクション1つに対してシングルコアの1Solrサーバと仮定して）solrコア名はコレクション名をつけるようになっています。同一コレクションのためのマルチコアに対してのいい命名規則をつけるという課題が残っています。（※コレクションに対する説明がここまでないかな？）

Shard Assignment

ノード->パーティションのマッピングはZooKeeperにあるCluster Lockを取得したノードによってのみ変更が可能です。ノードの追加時に、まず、Cluster Lockを取得し、次にそれがどのパーティションを取得できるかを識別します。

Node to a shard assignment

新しいノードを探しているノードはまずCluster Lockを取得しないといけません。第一に、リーダーはシャードを決めます。シャードが持つ、すべての利用可能なノード数で最小の値を持つノードが選び出されます。もし、同値ならランダムにノードを選びます。

原文はこちらからです。

New SolrCloud Design

(Work in progress)

What is SolrCloud?

SolrCloud is an enhancement to the existing Solr to manage and operate Solr as a search service in a cloud.

Glossary

Cluster : Cluster is a set of Solr nodes managed as a single unit. The entire cluster must have a single schema and solrconfig
Node : A JVM instance running Solr
Partition : A partition is a subset of the entire document collection. A partition is created in such a way that all its documents can be contained in a single index.
Shard : A Partition needs to be stored in multiple nodes as specified by the replication factor. All these nodes collectively form a shard. A node may be a part of multiple shards
Leader : Each Shard has one node identified as its leader. All the writes for documents belonging to a partition should be routed through the leader.
Replication Factor : Minimum number of copies of a document maintained by the cluster
Transaction Log : An append-only log of write operations maintained by each node
Partition version : This is a counter maintained with the leader of each shard and incremented on each write operation and sent to the peers
Cluster Lock : This is a global lock which must be acquired in order to change the range -> partition or the partition -> node mappings.

Guiding Principles

Any operation can be invoked on any node in the cluster.
No non-recoverable single point of failures
Cluster should be elastic
Writes must never be lost i.e. durability is guaranteed
Order of writes should be preserved
If two clients send document “A” to two different replicas at the same time, one should consistently “win” on all replicas.
Cluster configuration should be managed centrally and can be updated through any node in the cluster. No per node configuration other than local values such as the port, index/logs storage locations should be required
Automatic failover of reads
Automatic failover of writes
Automatically honour the replication factor in the event of a node failure

Zookeeper

A ZooKeeper cluster is used as:

The central configuration store for the cluster
A co-ordinator for operations requiring distributed synchronization
The system-of-record for cluster topology

Partitioning

The cluster is configured with a fixed max_hash_value (which is set to a fairly large value, say 1000) ‘N’. Each document’s hash is calculated as:


hash = hash_function(doc.getKey()) % N

Ranges of hash values are assigned to partitions and stored in Zookeeper. For example we may have a range to partition mapping as follows


range  : partition
------  ----------
0 - 99 : 1
100-199: 2
200-299: 3

The hash is added as an indexed field in the doc and it is immutable. This may also be used during an index split

The hash function is pluggable. It can accept a document and return a consistent & positive integer hash value. The system provides a default hash function which uses the content of a configured, required & immutable field (default is unique_key field) to calculate hash values.

Using full hash range

Alternatively, there need not be any max_hash_value - the full 32 bits of the hash can be used since each shard will have a range of hash values anyway. Avoiding a configurable max_hash_value makes things easier on clients wanting related hash values next to each other. For example, in an email search application, one could construct a hashcode as follows:


(hash(user_id)<<24) | (hash(message_id)>>>8)

By deriving the top 8 bits of the hashcode from the user_id, it guarantees that any users emails are in the same 256th portion of the cluster. At search time, this information can be used to only query that portion of the cluster.

We probably also want to view the hash space as a ring (as is done with consistent hashing) in order to express ranges that wrap (cross from the maximum value to the minimum value).

shard naming

When partitioning is by hash code, rather than maintaining a separate mapping from shard to hash range, the shard name could actually be the hash range (i.e. shard “1-1000” would contain docs with a hashcode between 1 and 1000).

The current convention for solr-core naming is that it match the collection name (assuming a single core in a solr server for the collection). We still need a good naming scheme for when there are multiple cores for the same collection.

Shard Assignment

The node -> partition mapping can only be changed by a node which has acquired the Cluster Lock in ZooKeeper. So when a node comes up, it first attempts to acquire the cluster lock, waits for it to be acquired and then identifies the partition to which it can subscribe to.

Node to a shard assignment

The node which is trying to find a new node should acquire the cluster lock first. First of all the leader is identified for the shard. Out of the all the available nodes, the node with the least number of shards is selected. If there is a tie, the node which is a leader to the least number of shard is chosen. If there is a tie, a random node is chosen.

Lucene/Solr 3.4リリース（速報）(Jugemより移植)

Thu, 15 Sep 2011 09:31:00 +0900

Solr/Lucene 3.4がリリースされました。（速報）

以下、各サイトへのリンクです。

Solrリリースのお知らせ

Luceneリリースのお知らせ

ちなみに、先日のSolr勉強会で関口さんが話されていたインデックスが壊れるバグですが、先日のアメリカのハリケーン（Irene）で実際に電源が落ちて見つかったみたいです。

ということで、3.4がリリースされたので、3.1~3.3は利用しないほうがいいようです。

追記： lucidimagination.jpのサイトに日本語のリリースノートが公開されていたので、リンクを記載しておきます。

Lucene/Solr 3.3リリース（速報）(Jugemより移植)

Fri, 01 Jul 2011 15:29:39 +0900

Solr/Lucene 3.3がリリースされました。（速報）

以下、各サイトへのリンクです。

Solrリリースのお知らせ

 Luceneリリースのお知らせ

リリースのタイミングがどんどん早くなってる。。。

Solr on @johtaniの日記 3rd

第13回Solr勉強会を開催しました

1. 「はじめての検索エンジン＆Solr」 株式会社NTTデータCCS 鈴木 教嗣さん

2. 「Solr SearchComponent 再訪」 株式会社ロンウイット 関口 宏司さん

3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」 株式会社 ロンウイット 大須賀 稔さん

4. 「Lucene Revolution 2013 Dublin振り返り」 楽天株式会社 平賀 一昭さん

まとめ

lucene-gosen 4.6.1のリリースに関する注意点

ダウンロード先

Solrへのプラグインの配置方法について

Solr全体で利用するlibディレクトリ

コア単位で利用するlibディレクトリ

改訂版Solr入門のPDF版も発売

改訂版Solr入門を執筆しました

第12回Solr勉強会を主催しました。#SolrJP

ManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット 大須賀 稔さん

デモ

QA

Solrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社 鈴木 一弘さん

QA

Yokozuna ベンチマークしました 株式会社インターネットイニシアティブ 曽我部 崇さん、田中 義久さん

QA

Solr 4.5の新機能など @johtani

LT

@haruyama さん

MorphlinesのloadSolrをちょっとだけ調べてみた

Record＝Solrのドキュメント

Solrへの登録処理は？

DocumentLoader

感想＋妄想？

Morphlines入門？

誤解

誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ

疑問点

参考資料

メモ

現在のコマンドライブラリ（スライド 18-19ページ）

プラグインコマンド（スライド 20ページ）

新しいプラグインコマンドとして考えられるもの（22ページ）

第11回Solr勉強会を主催しました。#SolrJP

ManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット 大須賀さん

クロールジョブのハング。。。

MCFエラーによるジョブの停止

自作リアルタイムインデクシングの問題

リプリケーションのNW負荷

Cloudera Search 入門(仮) Cloudera 株式会社 嶋内さん

ClouderaとHadoop入門とか。

Search

Cloudera Search

Cloudera Searchの事例

Cloudera Searchのアーキテクチャ

QA

コンピュータビジョン 株式会社 Curious Vehicle 牧野さん

画像検索の流れ

1. 特徴情報の抽出

2. 特徴情報のクラスタリングによるword化

3. Solrによる画像情報の検索

つぎのステップ

ガウシアンによる画像ぼかしの例

QA

国土交通省のデータをSolrで検索 株式会社ネクスト 秀野さん

デモの想定機能

デモ環境

事前知識

環境

Solr 4.4新機能をちょっと紹介 @johtani

Yokozunaの気になる点というかなんというか

Riak Meetup Tokyo #2に参加しました。#riakjp

FreakOut 久森さん 「Riak環境をプロダクションで構築＆運用してみた（仮）」

FreakOutとRTB

構成とかとか

課題

まとめ

QA

感想

IIJ 曽我部さん、田中さん 「Yokozuna 日本語検索性能を評価しました」

Yokozunaって？

Yokozunaのインストールとか。

Wikipediaデータってstoreの性能とか。

Rubyでの性能評価

1. 「はじめての検索エンジン＆Solr」株式会社NTTデータCCS　鈴木教嗣さん

2. 「Solr SearchComponent 再訪」株式会社ロンウイット　関口宏司さん

3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」株式会社ロンウイット　大須賀稔さん

4. 「Lucene Revolution 2013 Dublin振り返り」楽天株式会社　平賀一昭さん

ManifoldCFのとSolrの組み合わせ（仮）株式会社ロンウイット　大須賀　稔さん

Solrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん

Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中義久さん

プラグインコマンド（スライド　20ページ）

ManifoldCFのとSolrの組み合わせ（仮）株式会社ロンウイット　大須賀さん

Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん

コンピュータビジョン　株式会社 Curious Vehicle　牧野さん

国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん

Solr 4.4新機能をちょっと紹介　@johtani

FreakOut 久森さん「Riak環境をプロダクションで構築＆運用してみた（仮）」

IIJ 曽我部さん、田中さん「Yokozuna 日本語検索性能を評価しました」