Solr 保存された検索モジュール
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/mmhmp6fwc61dpbsxjkv5zhdz79mzbzm2 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
Solrが検索を保存し、マッチするドキュメントに基づいてそれらを効率的に表示する機能をサポートするようになるかどうか、考えたことはありますか？
この質問に確実に答えることはできませんが、そのために過去1年間に行われた作業の一部を共有したいと思います。提案されている「保存された検索モジュール」は、ドキュメントを受け取り、マッチするクエリを取得するリクエスト応答APIを提供することを試みています。これは、ElasticのPercolatorに似たものです。Solrのストリーミング式表現APIは、非常に多くのクエリを取得する必要がある場合にも機能するはずです。
ドキュメントはここにあります（現在作業中）
https://github.com/kotman12/solr/tree/solr-monitor-doc/solr/modules/saved-search#overview
実際に試してみたい場合は、JIRAの最新の更新に添付されたパッチを実行できます：
https://issues.apache.org/jira/browse/SOLR-4587
すでにlucene-monitorをこの機能のために使用している場合、特に興味があるかもしれません。提案されたモジュールは、ドキュメントとクエリの変換に関してlucene-monitorの巧妙な最適化をすべて使用しています。その上で、キャッシュに関するいくつかの独自の最適化も行い、潜在的にメモリ使用量を低減させ、クエリが更新によってブロックされることを防ぐことができます。これは、独自にlucene-monitorを実行しているときに遭遇するかもしれない問題です。また、このモジュールはデフォルトでスケーラブルで、Solrスキーマやアナライザーを保存された検索にシームレスに再利用できます。
このリストに興味のある方がいれば、フィードバックや関与をいただけると非常にありがたいです。こちらまたはPR、あるいはJIRAでのご意見をお待ちしています。
ありがとうございます。
Luke
これは非常に大きな機能ですね！
この機能の歴史的な系譜についてもう一度教えてもらえますか？
あなたは「lucene-monitor」に言及していますが、それ自体もどこかから来たものですよね。
私の記憶が正しければ、これの元になったSolrのプラグインがあり、それはAlan Woodwardによって作られたものではなかったでしょうか？
Solr における保存検索の実装に最も近いものとして、以下の2つを見つけました：
- solcolator: https://github.com/SOLR4189/solcolator
- Solr-monitor（提案されている保存検索モジュールとは無関係）: https://github.com/o19s/solr-monitor
これらの問題点は、Lucene-Monitor（元々は OSC によって提供された luwak）のデータ構造を side-car（補助的なもの）として扱い、Solr にデータ管理をさせることを想定していない点です。そのため、一貫性やレプリケーションなどのメリットを活かせません。
私が提案する解決策は、保存検索を 第一級の機能 として扱うことです。なぜなら、よく見ると通常のドキュメント検索とそれほど違いはないからです。
この Lucene PR https://github.com/apache/lucene/pull/13993 について Alan と話しました。これは、今回提案した保存検索モジュールに触発されたものです。
もし Alan がまだ Solr メーリングリストにいれば、彼が過去に行った作業についてコメントしてくれるかもしれません。あるいは、私が見つけられなかっただけで、活用できるモジュールが存在する可能性もあります。
また、Charlie Hull がこのメーリングリストにいることは知っています。彼なら lucene-monitor (luwak) の起源や歴史、また提案されている保存検索モジュールの代わりになるような Solr との統合について、より詳しい情報を持っているかもしれません。
Solr の β版のまま正式リリースされなかった topic streams は、この分野と関係がありましたが、パフォーマンスの高いリバース検索ソリューションを目指していたわけではなかったと思います。
理論的には、これらを統合することも可能かもしれません。しかし、高速な Percolator ライクのリバース検索を リクエスト・レスポンス API（またはレスポンスストリーム）としてサポートすること自体、十分に価値があると考えています。
トピックへ返信するには、ログインが必要です。