いいえ。魅力的な考えかもしれませんが、Solrはデータベースではなく、検索エンジンです。いつでも検索インデックスを破棄し、データベースから再構築できる必要があります。ほとんどのRDBMSがあなたの望むことを行うことができますし、人気が高まっているNoSQLのMongoDBのルートに進むこともできますが、決して検索エンジンをこのように使用しないでください。クエリとスピードのための中間データストアとして使用することはできますが、それが目的ではありません。

同意します。このリストでは、古いバージョンのSolrにデータが閉じ込められているというメッセージをかなり定期的に受け取ります。

大規模なクラスターで再インデックス作業が1週間かかり、S3からデータを取り出すのが難しい場合でも、確実に行えるようにしてください！

こんにちは、

パフォーマンスとリソース使用のベストプラクティスとして、検索機能に必要なデータのみを保存、インデックス化、またはdocValues化することが推奨されています。ただし、インデックス内の新しい機能を実装または変更するには、そのインデックス内のすべてのデータを再インデックスする必要があります。

私は2つの解決策を提案します：

• 最初の解決策は、元の完全なJSONデータをインデックスの_str_フィールドに保存することです。

https://solr.apache.org/guide/8_11/transforming-and-indexing-custom-json.html#setting-json-default

• 二番目で、私の意見では最良の解決策は、JSONデータを中間的なフィーチャーニュートラルなデータストアに保存することです。例えば、単純なファイルシステムやさらに良い場合はMongoDBデータベースです。これにより、データを複数のインデックス（検索用のインデックス、サジェスター用のインデックスなど）で使用できるようになり、各インデックス内の_src_フィールドにデータを重複させる必要がありません。各インデックス内にuuidを含めることで、MongoDBで完全なJSONオブジェクトを取得できます。

もちろん、選択した解決策に応じたデータストアのバックアップ戦略が重要なポイントです。それはSolrインデックスかファイルシステムかMongoDBデータベースかによって異なります。

Dominique

Solrはデータベースではありません。RDBMSとはまったく異なる存在です。もしRDBMSが得意とするようなことを求めるのであれば、SolrではなくRDBMSを使用すべきです。

Solrで絶えず変化する検索要件を扱う場合、通常はスキーマの変更が必要であり、それに伴って完全な再インデックスが必要になることがあります。そのため、データの保存と検索に同じSolrインデックスを使用することは、通常は不可能でしょう。

あなたのニーズを満たすために2つのSolrインストールをセットアップする必要がある場合、Solrをデータの保存に使用するべきではないでしょう。データの損失に対してテストされ、強化されたものを使用すべきです。Solrはデータを失わないよう最善を尽くしますが、データの確実な耐久性を保証することはその設計目標の一部ではありません。そのような保証をするために必要な変更は、おそらく検索性能に極めて悪影響を与える可能性があります。

Solrの中核機能は常に検索です。検索がその得意分野であり、将来のバージョンでも最適化されるのはそれだけです。データベース機能ではありません。

ありがとう、
Shawn

Srijan、

頭の中にあるコメントをもとに、いくつかの注意点をお伝えしますが、購入時にはご注意ください。

ほとんどの場合、データを「ソース」から再インデックスできるようにすることが望ましいです。これにより、インデックスのようなデータストアや真の情報源としては適していません。その理由はさまざまです。インデックスは頻繁に最近のアイテムに重みがかかるため、データが古くなってしまうことがありますし、新しい情報をインデックスするために再インデックスが必要になることもあり、その処理中に問題が発生する可能性もあります。その他にも理由はいろいろあります。

かつて私はLuceneでインデックスデータのPOJOストアを構築したことがありますが、データを保持しているオブジェクトを、Javaのオブジェクトインスタンスのような言語レベルのオブジェクトに変換することは可能です。一般的なデータモデルからインデックスとしてのデータモデルにデータをモデル化するのはかなり直感的です。ただし、クエリの期待値などは少し異なることに注意が必要です。それでも、これは逆索引の主な焦点ではありません。逆索引の主な焦点は、非構造化の言語データを取り、できるだけ整然としたリストで結果を返すことにあります。

まず最初に、異なるデータソースを異なるトポロジーを持つクラスタとして扱うことができます。通常のインデックスよりもストライプ化を少なくし、ノード数を増やすかもしれません。なぜなら、通常のインデックスよりも少ないインデクシングが必要だからです。データを分離する決定を下した後、異なるインデックスが同じ「ドキュメント」を参照するようにするには、何らかの ID を使用して結びつける必要があります。また、インデックス内でのドキュメント ID を使用したい任意の形式のインデックス結合の能力を失うことになります。すべてのデータを同じインデックスに保持する場合、一般的な回答は再インデックスすることであり、その際に「メタデータ」についてどうするかわからなくなる可能性があります。

強く疑問に思うのは、メタデータをインデックス内に保持し、それをドキュメントと同様にシンプルに使用する方法を持つことです。クローリングを行う際に、ドキュメントの内容と一緒にそのドキュメントに関する情報を保持してください。全てのデータをやや奇妙な独立したスペースに保持する理由が思いつきません。より洗練されたアプローチを取りたい場合、ドキュメントを取得しインデックス可能な単位に変換する ETL を構築し、再インデックスのためにそのインデックス可能な単位を保存します。この方法は通常非常に迅速であり、クローリング、ETL、インデックス化/クエリの各部分を分離しますが、それが意味するすべてのものです。これはより複雑ですが、一般的に人々が考える方法としては標準的です。

Tim

「No」という回答は伝統的で少し時代遅れです。適切なバックアップやスナップショットがあれば、Solr（Lucene）を主要なデータストアとして使用することは完全に可能です。フィールドや設定の変更が必要な場合、既存のコレクションからコレクションをインポートし、フィールドの変換をリアルタイムで行うことができます。

Lucene/Elasticsearchを基盤とする製品が増えており、これらは主要なデータストアとして機能しています。Solrも同様に使用されない理由はありませんが、コア開発者のバグ修正やドキュメンテーションへの対応が遅いという問題があります。しかし、それはSolrを使用するかどうかについての質問の話題です。

すべてのソフトウェアソリューションと同様に、システムは冗長性と強靭性を備えて設計されるべきです。

幸運を祈ります！

同意します。私たちは長年、いくつかのユースケースでSolrを主要なデータストアとして使用しています。しかし、私たちが保存しているのは、ログまたは再現または再生成可能なデータだけです。

元のメッセージではCrawlDBの保存について言及していましたが、その場合、Solrに保存するのは問題ありません。災害時にデータを簡単に再現することができます。

同意します。私たちは長年、いくつかのユースケースでSolrを主要なデータストアとして使用しています。しかし、私たちが保存しているのは、ログまたは再現または再生成可能なデータだけです。

元のメッセージではCrawlDBの保存について言及していましたが、その場合、Solrに保存するのは問題ありません。災害時にデータを簡単に再現することができます。

Solrは「良い」主要データストアではありません。Solrは文書を見つけるために設計されており、それらを保存することを目的としていません。良い主要データストアは、重みを増やさず、定期的に変更することなく、無期限にデータを保持しますが、Solrはこのような要件には合致しません。その大きな理由の1つは、ある時点で最新バージョンにアップグレードしたくなることであり、私たちは単一の中間アップグレードしかサポートしていません。例えば、6から7へ、または7から8へのアップグレードなどです。6から7から8といった複数のステップのアップグレードは失敗する可能性があります。私はコードでこれが実際に強制されていると聞いたことがあるような記憶がありますが、素早くコードを見直しただけではそのチェックを見つけることができませんでした（これが存在しないという意味ではなく、私が見つけられなかっただけです）。いずれにせよ、多バージョンのアップグレードは一般的にサポートされておらず、これにより我々はバック互換性の重みを増やさずに改善を自由に行えるようにしています。通常、新しい索引機能が開発され、それを利用したい場合（例えば、ドキュメント値が導入されたときなど）、新機能を利用するためには再インデックスが必要です。検索エンジンは通常、事前計算され、非正規化されたまたは他の方法で処理された情報をインデックスに書き込み、情報の取得速度を優先し、スペースと長期保存よりも速度を重視します。他の人が言及しているように、常に変わる要件の問題もあります。通常、製品管理者またはもしあなたが運が悪ければCEOがSolrで行われたクールなことについて聞き、次のように言います。「それをやりましょう！きっと顧客を引き付けると思います！」…新しいものの9回中8回は、何かを分析する方法を変えたり、以前に受信したデータの新しい分析を追加したりすることを含みます。再インデックスできない場合、「古いデータではできません」と言う必要があり、PM/CEO/最大のクライアントなどから尋ねられた場合には、「新しいデータ用に別のコレクションが必要で、両方を検索するのが難しいことになるかもしれません」とも言うかもしれません。

ドキュメントにフィールドを追加する能力は、場所情報を持つドキュメントに検索可能な地理座標や、おっしゃるようなドキュメントのメタデータを追加するためのものであり、ドキュメントの内容自体を保存するためのものではありません。自己再インデックス化されたドキュメントを持つことは可能ですが、その場合、再インデックスに必要なすべてのデータを含んでおり、多くのスペースを必要とし、インデックスの処理速度を遅くします。さらに、これにはSolr内でupdateProcessorFactoriesを使用してすべてのインデックスの拡充やクリーニングなどを行う必要があります。これにより、インデックスの作業が検索クエリと競合することが増えます。あるいは、データを外部処理後にクエリして取り出し、再挿入する必要があり、これもユーザークエリと競合することになります（結果として、余分なハードウェアや2つのクラスターが必要になることがあります。クラスターを定期的に切り替える必要があることもあります。こうなると、複雑で高コストかつインデックスの遅延が高い状態になり、遅いクエリの代わりに）。元のデータを保存しようとすると問題が複雑化します。単純にするために、Solrを使用して情報を見つけ、それを主要なソースから提供することが、本当に最善の始め方です。

だから、うまくやれば制限を受け入れて主要なストアとして使用することができるかもしれませんが、自分が何をしているのかを認識し、ちゃんと機能する水晶玉が必要です。私はクライアントにこれを推奨したことがないです。私は私について良いことを言ってくれる幸せなクライアントを好むので :) だからあなたに対するアドバイスは、極めて説得力のある理由がない限り、それをやらないでください。

もし、本当に大量のデータを扱っていない場合で、社内イントラネットをインデックスしているだけで（それがAppleやGoogleのような規模ではないことを前提として）、そのような場合には、ページをクロールするためにクローラーが見つけたものをすべてファイルシステムに保存し、インデックス化に値すると考えるものを落としておくと良いでしょう（おそらく2つのファイル、コンテンツとリンクが見つかった場所などのメタデータが含まれたファイル）。その後、別のインデックス化プロセスが定期的にファイルシステムをスキャンし、メタデータを整形したり、他の有用な操作を行ったりして、その結果をSolrに書き込むようにします。クロールストアが設計されていて、同じドキュメントが常に同じ場所に配置されるようになっており、インデックス化するサイトの成長以外の成長を気にする必要がない場合は、この方法が適しています。さらに、新たに取得したドキュメントを識別するためのトピック用のKafkaインスタンスを追加することで、このプロセスを改善する方法もあります。また、コンテンツのハッシュをデータベースに保存しておくことで、クローラーが単に同じデータをダウンロードした場合にはインデクサーが無視するようにすることもできます。

そして、消えたページの参照を削除するか、移動/名前変更を検出するか、それとも削除を検出するかを決定する必要があります。これ自体が一つの大きな課題です。

私のサイドプロジェクトであるJesterJ.org https://www.JesterJ.org は、私が述べたインデクサー機能の多くを提供しています（ただし、まだKafkaコネクターが必要です。貢献は歓迎します :)）。いくつかの方々がこれを有益に使用していますが、率直に言って、まだ粗削りな部分があります。現在のメインブランチは、今から古いリリースされたベータ版よりもずっと優れています（これはおそらくアルファ版であるべきだったかもしれませんが、まあそういうことです）。

Gus

これは長い間読んだ中で最も興味深く、明瞭なメールの一つです。このメールは保存しておきます。

バック互換性の重みがどんどん増していくということです。

実際に、このために人々がSolrをElastic/OpenSearchに移行する理由です。Solrの主要な貢献者たちは、移行経路や安定性のサポートにあまり価値を見出しておらず、それゆえアップグレードには常にユーザーにとって重いコストがかかります。

ほとんどの人々がSolrがアップグレード間で安定しているとは考えていません（誰か？ブーラー… 誰か？）。これはつまり、アップグレード間でデータの移行（時間とストレージ）を計画する必要があることを意味します。これはソースから再インデックスする必要があるという意味ではありません（再インデックスは行いますが）、インデクシング時に含めなかった元のドキュメントからの新しいデータを取得することができないということです。インデクシングされていないフィールド（ストアされたドキュメント）から再インデックスすることを可能にする「完全なソースドキュメント」を格納する戦略があり、それにより完全に別個の永続化層を必要とせずに済むようになります。

Luceneは、セグメントを書き込むバージョンの記録を6.xのある時点から始めましたが、具体的なリリース番号はわかりません。

私は、8.xではインデックスが6.xのバージョンであるか、またはインデックスにバージョンが一切記録されていない場合、インデックスを開こうとすると拒否されることを知っています。7.xが同様のことを行ったという情報は聞いたことがないので、おそらく6.0以降のある6.xバージョンで最初にバージョンの記録が始まったのでしょう。

この変更前は、1つ以上のメジャーリリースへのアップグレードが保証されたことはありませんでしたが、現在は強制されています。

よろしくお願いします。
Shawn

製品間に違いがあることは驚くことではありません。もしその機能がお気に入りであれば、Elasticを使ってください。他にもさまざまな機能や、一部の人に重要なライセンスなどもあります。Amazonの取り組みは興味深いですが、これからも続くでしょうか？OracleがMySQL ABを買収したとき、dorsal source dot orgというサイトが登場しました（今は攻撃サイトになっているようですが、wayback machineで2008年ごろの情報が見られます）。これは友人が関わっていたものです。大企業の後ろ盾がなかったとは言え、一定期間有用でした。大企業でも時間とともに優先事項が変わり、プロジェクトが廃止されることがあります。オープンソースプロジェクトもアーカイブされることがありますが、LuceneとSolrは最も活発なプロジェクトの一部であり、それが近い将来のリスクではないことは明らかです。ただし、あなたの口調は少し熱心すぎるように聞こえ、Solrを維持する人たちが全てボランティアであることを忘れているようにも聞こえます。もし改善が必要だと思う点や、変更を提案したい点があれば、批判的なコメントを避けて議論することは歓迎します。そしてもしそのようなことに興味があれば、あなたの提案やコードも歓迎します。

Gus

私は、リリース間の安定性に焦点を当て、移行経路の選択肢を提供することを推奨したいと思っています。私は、競合他社よりも採用や保守が容易な技術にファンとしています。

基本的なレベルでは、Elasticsearch（ES）とSolrはどちらもほとんどの機能でLuceneを使用しているため、実行可能なことに大きな違いはありません。主な違いは、それぞれがデフォルトで提供する機能にあります。Solrは最大の機能と柔軟性を目指しており、設定できる項目の数が膨大で、初心者にとっては圧倒されることがあります。一方、ESは「典型的なユーザー」をターゲットにしています。本当に深く掘り下げたい場合、ESもSolrと同様の機能を提供していますが、これらの高度な機能はデフォルトの設定を見たときには目立たない形で提供されます。

私の理解では、ESはインデックス内のフィールドに入力ドキュメント全体を保存することで再インデックスの機能を提供しています。これにより、インデックスは本来必要なよりも大きくなるため、パフォーマンスに影響を与える可能性があります。フィールドがインデックスされていない場合、パフォーマンスへの影響は大きくないかもしれませんが、ゼロではありません。そして、完全な再インデックスのスピードを向上させるわけではなく、単に外部データソースなしで再インデックスを行うことが可能になるという点において便利です。

Solrでも同様のことができますし、Solrを主要なデータストアとして使用する場合にはインデックス設計の一部として必要だと断言します。その機能はSolrで利用可能であるべきですが、デフォルトで有効にすべきではないと考えています。

Solrの設定システムをもっと簡素化する可能性を探ることが楽しみです。初心者が簡単に始められるようなシステムにし、同時に上級ユーザーがより複雑な設定を作成するのに支障がないようなものにしたいです。

よろしくお願いします。
Shawn

あなたが述べているのは、すべてのデータをソースから再構築可能である必要性は厳格な要件ではないということです。元のソースにアクセスせずに再インデックスする方法があります（Solrにはドキュメント全体をインデックスしなくても、保存する必要があります）。この視点からSolrを見ると、主要なデータストアとしてアプローチしやすくなります。

ドキュメントが構造が単純であれば問題ありません。各フィールドについてのキーと値、または配列があれば、使えます。しかし、複数階層のものに関しては、うまくいかないことがあります。以下のリンクは今でもどれだけ関連性があるかは不明ですが、参考になるかもしれません：
https://stackoverflow.com/questions/22192904/is-solr-support-complex-types-like-structure-for-multivalued-fields

これは2017年の情報ですが、多くの場合、まだ有効であると考えています。ただし、ネストされたドキュメントのインデックス化に関する可能性があります：
https://solr.apache.org/guide/8_1/indexing-nested-documents.html

正直に言って、私自身は複雑なデータ構造のための子ドキュメントについて深くは掘り下げていません。複雑なデータ構造を単一の大きなテキストフィールドにJSON形式で格納し、検索対象となる部分のみをインデックス化するという方法もあります。

別の選択肢として、完全に異なるコア、あるいは完全に異なるSolrサーバー（私はよくスタンドアロンを使用します）を使用することを試みたことがあります。片方を検索に使用し、結果を他の「ストレージサーバー」から識別子を使って生データを引き出すことができます。これは実際には驚くほど速いです。

これはハック的な方法であり、適切なツールを使用しているわけではありませんが、本当にやりたいと思い、創造的になれば実現可能です。

成功を祈ります。あなたがどのような解決策を見つけるか興味深く思っています。
Dave

おそらく私の「主要なデータストア」という定義は異なるかもしれません。私にとっては、それは主要なデータのための格納庫です。

Dima