次の状況を考えてみましょう。作家と本を 2 つの別々のテーブルに格納するデータベースがあります。1 つの本には、その本を書いた作家への参照が保存されていることは明らかです。Solr の場合、この構造を 1 つの大きなドキュメントに非正規化し、すべての本に関連する作家の詳細が含まれている必要があります。このインデックスは、書籍のクエリに使用されるようになりました。
システムの 1 人のユーザーが、システム内のライター レコードを更新することにしました。多くの本を関連付けることができるため、このライター レコードからのデータが埋め込まれた Solr 内のすべてのドキュメントを更新する必要があります。私の知る限り、影響を受けるすべてのドキュメントを削除して再度追加する必要があるため、これは非常に苦痛です。
これを行うより良い方法はありますか？参照データの 1 つが変更された場合、システム内のインデックスをほぼリアルタイムで更新する必要があります。
これは、ネストされたドキュメントの完璧なユースケースになります。私の知る限り、luceneはネストされたドキュメントをサポートしていますが、Solrはサポートしていません。この機能の現在の状態については、完全にはわかりません。
ただし、この機能はelasticsearchで使用できます。あなたはそれを見てみたいと思うかもしれません、私の意見でelasticsearchの何がそんなにクールなのか知りたいのなら、私が書いたばかりの記事が面白いかもしれません。あなたの質問は、私が私の記事でネストされたドキュメント機能について言及しなかったことを思い出させました。これも本当にクールです。マッピングでネストされたタイプを使用できます。もっと知りたい場合は、この記事をご覧ください。ちなみに、それは正確に本/著者の例を含んでいます。
Elasticsearchは、ドキュメントの更新中にも役立ちます。ドキュメント全体のインデックスを再作成する必要はありませんが、スクリプトを介して変更のみを送信します。インデックスが作成されたソースドキュメントを格納しているため、内部で取得し、スクリプトを実行して更新し、インデックスを再作成します。これが、インデックスセグメントがライトワンスであるため、luceneが内部的に機能する方法です。間もなくリリースされるSolr4では、変更のみを提供するドキュメントを更新できますが、私が知る限り、これはすべてのフィールドが保存されている場合にのみ機能します。保存されていないフィールドは、インデックスから取得できません。
Near Real Timeの更新について話している場合、elasticsearchはLucene Near Real Time APIを使用し、インデックスリーダーを毎秒自動的に更新します。Solr 3はまだこれらのAPIを使用していませんが、Solr4は使用しています。
SOLR でネストされた型を更新するには、dataimporters とデルタ インポートを使用できます。https://wiki.apache.org/solr/DataImportHandler#Delta-Import_Exampleの例は、これがどのように機能するかを示しています。明らかに、solr がデータベースにアクセスする必要があります。