ExtractRequest ハンドラーを使用して、type=parent を使ってドキュメントをインデックスする方法
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/8phv1bysxk2fq4ml85l5hclj6228wdw3 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは。
私は長い間、/update/extract を使ってドキュメントをインデックスしてきました。これまではすべてうまく動作していましたが、「ネストされたドキュメントを追加する」という新しい要件が出てきました。
そのため、schema.xml に以下を追加しました：
<field name="type_level" type="string" indexed="true" stored="true" docValues="true" />
<field name="_root_" type="string" indexed="true" stored="true" multiValued="false" required="false" />
ユニークキーの定義は以下の通りです：
<field name="DocID" type="string" indexed="true" stored="true" />
<uniqueKey>DocID</uniqueKey>
これを行った後、/update/extract に対して再インデックスのリクエストを送ると、同じドキュメントが Solr に重複して登録されてしまいます。
以下が私のリクエスト内容です。違うのは新しいパラメータ type_level=parent を追加したことだけです：
http://server:8983/solr/document/update/extract?
literal.id=6584239&
resource.name=&
wt=xml&
literal.DocID=6584239&
literal.CoreID=6584239&
literal.DocIsAttachToPNB=False&
literal.DocAuthorID=1455&
literal.DocIsAttachToPerson=True&
literal.DocIsAttachToAssign=False&
literal.DocIsAttachToCompany=False&
literal.DocVersionID=4504527&
literal.InsertDateSD=2011-01-03T07%3a51%3a00.0Z&
literal.DocNameS=Squires+David+RES.doc&
literal.DocCateNameS=Resume%2fCV&
literal.DocAreaCateNameS=Person+Module&
literal.type_level=parent&
stream.url=http%3a%2f%2flocalhost%3a8081%2f4%2f50%2f45%2fSquires%2520David%2520RES15EAC416-AF05-4D38-A4F9-7B489962C167.docx&
overwrite=true&
commit=true
このリクエストの後、ドキュメントが重複して表示されます。違いは type_level:parent だけです。
どなたか、なぜこうなってしまうのか分かる方はいらっしゃいませんか？
よろしくお願いします。
Sergio Maroto
こんにちは。
「ドキュメントが2回表示される」とは具体的にどういう意味でしょうか？
ID だけが異なるエントリであれば、ドキュメントは何百回でも表示される可能性があります。インデクサがこれを適切に処理していることを確認してください。
また、あなたのユニークIDフィールドは "DocID" であり、サンプルによればその値は id と一致しているように見えます。
この2つが常に一致していることを確認してください。そうでない場合、SQLデータベースでの複合主キーのように扱われることになります（実際には Solr のデータベースは NoSQL ですが、これはデータのクエリ方法にのみ関係します）。
さらに、クエリ内で parent ID と ID が混同されていないかを確認してください。
これはクエリアプリケーションにバグがあると起こり得ることです。
Mag.phil. Robert Ehrenleitner, BEng.
迅速なご返信ありがとうございます。もう少し詳しく説明させてください。
本番環境には、既存のインデックスがあり、DocID をユニークキーとして使って、常にドキュメントを再インデックスしています。
新しいリクエストが /update/extract を使って来ると、そのドキュメントは再インデックスされ、新しいデータで置き換えられます。
この点については問題ありません。
しかし、スキーマに _root_ および type_level フィールドを追加した後、Solr に既に存在している古いドキュメントはそのまま残り、
新しいドキュメントが作成されてしまいます。
そして、同じドキュメントをもう一度再インデックスすると、新しい方のドキュメントは再インデックスされて上書きされますが、
古い方のドキュメントは依然として残っています。
最初に _root_ と type_level をスキーマに追加したときに、/update/extract が
「古いドキュメント」と「新しいドキュメント」が同一であると認識できていないように感じています。
これにより、インデックスを削除してゼロから再インデックスするか、すべてのドキュメントを再インデックスしてから、
最後に type_level:parent を持っていない古いドキュメントを削除するしかない状況になっています。
この件について、何か良い案はありますか？
こんにちは、Sergio。
スタンドアロン（通常の単独ドキュメント）インデックスにネストされたドキュメントを追加することは、
そもそもサポートされたり、考慮されたりしているとは思えません。
その通りです。
以下のリンクの太字部分を確認してみてください：
https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-nested-documents.html#schema-configuration
--
よろしくお願いします、
Mikhail Khludnev
私たちも似たような問題を抱えていたので、どのように対処したかをお伝えします。
私たちの場合、インデクサーはクローラーで、ウェブサイトのREST APIからデータを取得しています。
このプログラムには、ウェブサイト上のデータ構造とSolrインデックス内の構造に関するすべての知識が組み込まれています。
アプリケーションレベルでこれを処理することで、すべてをより細かく制御できます。
クローラーは、すでにインデックスにあるドキュメントのファイル名を、クロール開始前にキャッシュへ取り込むことができます。
クロール中、クローラーはソース内のドキュメントとキャッシュ内のドキュメントを比較すべきです。
Solrの設定で苦労する必要はありません。
Mag.phil. Robert Ehrenleitner, BEng.
ザルツブルク・パリス・ロドロン大学
なるほど。それで納得がいきました。インデックスを削除したくなかったんですが。
混乱したのは、通常の /update ハンドラーを使って、ドキュメントの内容を含んだ XML を POST したときにはうまく動作していたからです。
ところが /update/extract ハンドラーを使った場合は、なぜかうまくいきません。
おそらく、古いドキュメントに _root_ がないと、それが同じドキュメントだと認識できない何かがあるのでしょう。
残念ですが、コレクションを削除して再インデックスする必要がありそうです。
みなさん、ありがとうございました。
Sergio
こんにちは、Sergio さん。
インデックスを最初から再構築する手順をあらかじめ用意しておくのは、常に良い考えです。
私たちも、設定やスキーマの変更、Solr のバージョンアップの際にはそうやって対応しています。
万が一、災害復旧が必要になった場合でも、その手順が準備されていて、実際に動作実績があることは非常に心強いはずです。
Thomas
_root_ フィールドを追加しただけで再インデックスをしない方法はサポートされていません。
再インデックス後にネストされていないドキュメントが混在している状態で動かすことは可能ですが、
その場合はネストドキュメントのクエリ処理がどのように低レベルで動いているかを深く理解し、
ネストドキュメントに対して正しいクエリを組み立てる必要があります。
特に重要なのは、「child（子）」とは「parent（親）ではないこと」を意味し、
「parent（親）」とは「child（子）ではないこと」を意味するという点です。
これらの否定は補集合にならない場合もあり（ネストしないドキュメントが存在するとき）、
これは真偽値（True, False）だけでなく NULL も扱うような非常にややこしい論理を扱うようなものです。
すべてが同じ種類のネストドキュメントであれば話はずっと簡単なので、
可能な限りその状態を目指すことをおすすめします。
トピックへ返信するには、ログインが必要です。