@johtani の日記

まだ、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と出力形式が異なるため。
　　

現在、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（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。

Tweet

今日は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の機能を利用したものではありません。
つぎのような流れになっています。

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

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

前提条件

---

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

• すべてのフィールドを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>
<doc>
  <field name="id">VS1GB400C3</field>
  <field name="_version_">バージョン番号</field>
  <field name="cat" update="add">cats_and_dogs</field>
  <field name="popularity" update="inc">10</field>
  <!-- set empty for SOLR-3502 bug -->
  <field name="price_c" update="set">0.0,USD</field>
</doc>
</add>

上記サンプルのうち、バージョン番号の部分は、現在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に指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）

久々に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入門のサンプル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入門」の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を設定する記述を追記しました。

以前より、アナウンスしていた、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が同時に利用できる形のものを用意しました。

---

最近忘れやすいので、記録しておこうかと。
読んだスライドの簡単な内容と感想です。
ちなみに、スライドの一覧はこちらです。
※スライドへのリンクはすべて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

次は、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の活用の仕方について。

---

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

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

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

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

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

Boot Strapping

Cluster Startup（クラスタの起動）

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

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

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

Node Startup

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

New Node

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

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

1. Cluster Lockを取得します。
2. 適切なnode->partitionエントリを選び出します。
   1. 利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。
   2. 全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。
   3. もし、選んだノード->パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。
   4. ZooKeeper内のノード->パーティションマッピングを更新します
3. ZooKeeper内のノードステータスを「リカバリ」状態にします
4. Cluster Lockをリリースします
5. 「リカバリ」はパーティションのリーダーから開始します。
6. リカバリが終了したら、再度、Cluster Lockを取得します。
7. 元のエントリはZooKeeperのノード->パーティションマッピングから削除されます。
8. Cluster Lockをリリースします
9. 元のノードはZooKeeperからノード->パーティションマッピングを更新させられます
10. ステップ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に分割アクションを記録します。 ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）

1. XのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション->ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。
2. Xのリーダーは分割が完了するまですべてのコミットを停止します。
3. Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます
4. XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。
5. Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？
6. Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。
7. #5で作成されたインデックスはYのリーダーに送られ、登録されます。
8. Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。
   1. パーティションYのすべてのノードがバージョンVに到達したならば
   2. YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。
   3. Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ->パーティションマッピングを変更します。
   4. YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます
   5. YのリーダーはXのリーダーに、ZooKeeperからレンジ->パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。
9. Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。
10. この時点で分割は完全に終了し、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. 1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。
   • 他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。
2. いくつかのドキュメントをインデックスします
3. 他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。
   • 出来れば、同一ホスト上に同じシャードはコピーしない
   • この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば）

原文はこちらからです。