Apache Solr は広く使用されている検索エンジンです。Solr を使用する有名なプラットフォームがいくつかあり、Netflix や Instagram などもその例です。tajawal のアプリケーションでは Solr と ElasticSearch を使用しています。この記事では、最適化されたスキーマファイルを作成する方法に関するヒントをいくつか紹介します。Solr の基本については説明しませんが、Solr がどのように機能するかを理解していただければ幸いです。
スキーマファイルでフィールドといくつかのデフォルト値を定義できますが、必要なパフォーマンス向上は得られません。特定のキー構成に注意する必要があります。この投稿では、パフォーマンスの面で Solr を最大限に活用するために使用できるこれらの構成について説明します。
早速、これらの構成が何であるかを理解しましょう。

1. キャッシュを構成する

Solr キャッシュはインデックスサーチャーの特定のインスタンスに関連付けられており、インデックスの特定のビューはそのサーチャーの存続期間中は変更されません。
パフォーマンスを最大化するには、キャッシュの構成が最も重要な手順です。

「filterCache」を設定します。

フィルターキャッシュは、SolrIndexSearcher によってフィルターに使用されます。フィルターキャッシュを使用すると、フィルタークエリの処理方法を制御してパフォーマンスを最大化できます。FilterCache の主な利点は、新しいサーチャーを開いたときに、そのキャッシュに古いサーチャーのキャッシュのデータを事前に設定または「自動ウォームアップ」できることです。したがって、パフォーマンスを最大化するのに間違いなく役立ちます。例えば：

<filterCache
class="solr.FastLRUCache"
size="512"
initialSize="512"
autowarmCount="0"
/>

クラス: SolrCache は LRUCache (LRUCache または FastLRUCache) を実装します。
size: キャッシュ内の最大エントリ数
。initialSize: キャッシュの初期容量 (エントリ数)。(java.util.HashMap を参照)
autowarmCount: 古いキャッシュから事前に入力するエントリの数。

`queryResultCache` と `documentCache` を設定します。

queryResultCache キャッシュには、以前の検索の結果、つまり要求されたクエリ、並べ替え、およびドキュメントスコープに基づいたドキュメント ID の順序付きリスト (DocList) が保持されます。

documentCache キャッシュは、Lucene Document オブジェクト (各ドキュメントのストレージフィールド) を保持します。Lucene の内部ドキュメント ID は一時的なものであるため、このキャッシュは自動的にウォームアップされません。

アプリケーションに応じて設定できます。主に読み取り専用のユースケースを使用する場合、パフォーマンスが向上します。
ブログがあるとします。ブログには投稿と投稿に対するコメントを含めることができます。Post の場合、データベースの読み取り数が書き込み数をはるかに上回るため、これらのキャッシュを有効にすることができます。したがって、この場合、投稿に対してこれらのキャッシュを有効にすることができます。
例えば：

<queryResultCache 
  class="solr.LRUCache"
  size="512" 
  initialSize="512" 
  autowarmCount="0"
/><documentCache 
  class="solr.LRUCache"               
  size="512"               
  initialSize="512"               
  autowarmCount="0"
/>

主に書き込み専用のユースケースを使用している場合は、ソフトコミットごとに queryResultCache と documentCache を無効にすると、これらのキャッシュはフラッシュされるため、パフォーマンスに大きな影響はありません。したがって、上記のブログの例を念頭に置いて、コメントの場合にはこれらのキャッシュを無効にすることができます。

2. SolrCloud を構成する

クラウドコンピューティングは最近非常に人気があり、スケーラビリティ、高可用性、耐障害性を管理できます。Solr を使用すると、フォールトトレランスと高可用性を組み合わせた Solr サーバーのクラスターをセットアップできます。
setupSolrCloud 環境では、「マスター」レプリケーションと「スレーブ」レプリケーションを構成できます。「マスター」インスタンスを使用して情報のインデックスを作成し、複数のスレーブ (要求に基づいて) を使用して情報をクエリします。マスターサーバー上の solrconfig.xml ファイルに、次の構成を含めます。

<str name="confFiles">
solrconfig_slave.xml:solrconfig.xml,x.xml,y.xml
</str>

詳細については、Solr ドキュメントを参照してください。

3.「コミット」を設定する

データを検索可能にするには、データをインデックスに送信する必要があります。数十億のレコードがある場合、場合によってはコミットが遅くなることがあります。Solr はさまざまなオプションを使用してコミット時間を制御し、データをいつコミットするかをより詳細に制御できるようにします。アプリケーションのプログラム選択オプションに基づいて決定する必要があります。

「コミット」または「ソフトコミット」:

更新リクエストで commit=true パラメータを送信することで、データをインデックスに簡単にコミットできます。これにより、すべての Lucene インデックスファイルが安定したストレージにハードコミットされ、すべてのインデックスセグメントが確実に更新され、コストがかかる可能性があります。ビッグデータがあるとき。
データをすぐに検索に使用できるようにするには、追加のフラグ SoftCommit=true を使用できます。これは、Lucene データ構造への変更を迅速にコミットしますが、Lucene インデックスファイルが安定したストレージに書き込まれることは保証されません。この実装は Near と呼ばれます。リアルタイム、改善されたドキュメントの可視性。他の操作を行う前に、バックグラウンドのマージとストレージ (SolrCloud を使用している場合は ZooKeeper) が完了するのを待つ必要がありません。

自動コミット:

autoCommit 設定は、保留中の更新を自動的にインデックスにプッシュする頻度を制御します。このコミットをトリガーする時間制限または更新されるドキュメントの最大制限を設定できます。更新リクエストを送信するときに「autoCommit」パラメータを使用して定義することもできます。リクエストハンドラーで次のように定義することもできます。

<autoCommit>
<maxDocs>20000</maxDocs>
<maxTime>50000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>

maxDocs: 最後のコミット以降に発生した更新の数。
maxTime: コミットされていない最も古い更新からのミリ秒数
openSearcher: コミットの実行時に新しいサーチャーを開くかどうか。これが false の場合、コミットすると最近のインデックス変更が安定したストレージにフラッシュされますが、それらの変更を表示するために新しいサーチャーが開かれることはありません。デフォルトは true です。
場合によっては、autoCommit を完全に無効にすることができます。たとえば、数百万のレコードを別のデータソースから Solr に移行しており、以下のデータのバッチ送信であっても、挿入ごとにデータをコミットしたくない場合です。移行が遅くなる可能性があるため、2,000、4,000、または 6,000 回の挿入ごとにこれを行う必要はありません。この場合、「autoCommit」を完全に無効にして移行の最後にコミットすることも、3 時間 (つまり 3*60*60*1000) などのより大きな値に設定することもできます。<maxDocs>50000000</maxDocs> を追加することもできます。これは、5,000 万のドキュメントを追加した後でのみ自動コミットが行われることを意味します。すべてのドキュメントが公開されたら、手動または SolrJ からコミットを呼び出します。コミットにはしばらく時間がかかりますが、通常ははるかに高速です。
また、一括インポートを完了した後、Solr への増分投稿がより速くコミットされるように、maxTime と maxDocs を減らします。

4. 動的フィールドの構成

Apache Solr の驚くべき機能は、dynamicField です。これは、フィールドが数百あり、そのすべてを定義したくない場合に非常に便利です。

動的フィールドは、名前にワイルドカードが含まれていることを除けば、通常のフィールドと同じです。明示的に定義されたフィールドに一致しないフィールドは、ドキュメントのインデックス作成時に動的フィールドと照合できます。

たとえば、スキーマに *_i という動的フィールドが含まれているとします。Cost_i フィールドを使用してドキュメントにインデックスを付けようとしたが、cost_i フィールドがスキーマで明示的に定義されていない場合、cost_i フィールドには *_i に対して定義されたフィールドタイプと分析が含まれます。
ただし、dynamicField を使用する場合は注意が必要です。dynamicField にはいくつかの欠点もあるため、広範囲に使用しないでください。射影 (「abc.*.xyz.*.fieldname」など) を使用して特定の動的フィールド列を取得する場合は、次を使用してください。正規表現フィールドの解析には時間がかかります。また、クエリ結果を返す際の解析時間も増加します。次に、動的フィールドの作成例を示します。

<dynamicField
name="*.fieldname"
type="boolean"
multiValued="true"
stored="true"
/>

動的フィールドを使用すると、ワイルドカードを指定するため、フィールド名の組み合わせを無制限にできることになりますが、Lucene では一意のフィールド (列) 名ごとにメモリが割り当てられるため、コストが高くなる場合があります。 A、B、C、D、そして別の行に E、F、C、D がある場合、Lucene は 4 ブロックではなく 6 ブロックのメモリを割り当てます。これは、6 つの一意の列名があるためです。したがって、6 つの一意の列名があるとしても、10,000 100 万行の場合、50% の余分なメモリが使用されるため、ヒープがクラッシュする可能性があります。

5. インデックスとストレージフィールドを構成する

フィールドのインデックス付けは、フィールドを検索可能にすることを意味します。indexed="true" を指定すると、フィールドが検索可能、並べ替え可能、およびファセット可能になります。たとえば、indexed="true" の test1 というフィールドがある場合、q= search it のような操作を行うことができます。 test1:foo のように、foo は検索する値であるため、検索に必要なフィールドのみをindexed="true"に設定し、検索で必要な場合は残りのフィールドをindexed="false"にする必要があります。結果。例えば：

<field name="foo" type="int" stored="true" indexed="false"/>

これは、インデックスの再作成にかかる時間を短縮できることを意味します。インデックスを再作成するたびに、Solr がフィルター、トークナイザー、アナライザーを適用するため、インデックスの数が少ない場合、処理時間が多少追加されます。

6. コピーフィールドを設定する

Solr は、複数のフィールドのコピーを 1 つのフィールドに保存するメカニズムである copyField と呼ばれる非常に優れた機能を提供します。copyField の使用方法はシナリオによって異なりますが、最も一般的なのは、ユーザーまたはクライアントがクエリするフィールドを指定しない場合にデフォルトのクエリフィールドとして使用される単一の「検索」フィールドを作成することです。
すべての共通テキストフィールドに copyField を使用し、それらを 1 つのテキストフィールドにコピーして検索に使用すると、インデックスサイズが削減され、パフォーマンスが向上します。たとえば、ab_0_aa_1_abcd のような動的データがあり、サフィックス _abcd を持つすべてのフィールドをコピーしたい場合などです。 1つのフィールドに。次のように schema.xml に copyField を作成できます。

<copyField source="*_abcd" dest="wxyz"/>

source: コピーするフィールドの名前
dest: コピーされるフィールドの名前

7. フィルタークエリ「fq」を使用します。

検索で Filter Query fq パラメーターを使用すると、パフォーマンスを最大化するのに役立ちます。スコアに影響を与えることなく返されるドキュメントのスーパーセットを制限するために使用できるクエリを定義し、クエリを個別にキャッシュします。
Filter Queryfq は、fq で指定されたクエリがメインクエリとは独立してキャッシュされるため、複雑なクエリを高速化するのに役立ちます。後続のクエリで同じフィルターが使用されると、キャッシュヒットが発生し、フィルター結果がキャッシュからすぐに返されます。
フィルタークエリを使用したカールの例を次に示します。

POST
{
 "form_params": {
  "fq": "id=1234",
  "fl": "abc cde",
  "wt": "json"
 },
 "query": {
  "q": "*:*"
 }
}

フィルタクエリパラメータは、1 つの検索クエリで複数回使用することもできます。詳細については、Solr フィルタークエリのドキュメントを参照してください。

8. ファセットクエリの使用

Apache Solr のファセットは、検索結果をさまざまなカテゴリに分類するために使用されます。これは、特定のフィールドによるグループ化、カウント、グループ化などの集計操作を実行するのに非常に役立ちます。そのため、すべての集計固有のクエリに対して、すぐに使える Facet 集計を使用できます。純粋にこのタイプの操作用に設計されているため、箱から出してすぐにパフォーマンスを向上させることもできます。
以下は、ファセットリクエストをsolrに送信するcurlの例です。

{
 "form_params": {
     "fq"            : "fieldName:value",
     "fl"            : "fieldName",
     "facet"         : "true",
     "facet.mincount": 1,
     "facet.limit"   : -1, 
     "facet.field"   : "fieldName",
     "wt"            : "json",
 },
 "query"      : {
     "q": "*:*",
 },
}

fq: フィルタークエリ
fl: 結果で返されるフィールドのリスト
facet: true/false ファセットカウントを有効/無効にし
ます facet.mincount: カウントが 1 未満の範囲を除外します
facet.limit: 結果で返されるグループの数を制限します。 -1 はすべての
facet.field を意味します: フィールドは (結果をグループ化するために) ファセットとして考慮される必要があります。

結論は：

パフォーマンスの向上は、Solr を運用環境に導入する際の重要なステップです。Solr には、システムのパフォーマンスを最大化するのに役立つ調整ノブが多数あります。その一部については、このブログで説明します。最適な構成を使用するように solr-config ファイルを変更したり、適切なインデックスオプションでスキーマを更新したり、フィールドファイルタイプ、可能な場合はフィルター queriesfq を使用し、適切なキャッシュオプションを使用しますが、これもアプリケーションによって異なります。
それでおしまい。

この記事	https://architect.pub/cconfiguring-solr-optimum-performance
ディスカッション: Knowledge Planet [Chief Architect Circle] または WeChat トランペット [cea_csa_cto] を追加するか、QQ グループを追加する [792862318]
一般公開なし	【jiagoushipro】【スーパーアーキテクト】アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。お待ちしておりますので、ぜひスキャンしてご注目ください。
WeChatのトランペット	[cea_csa_cto] 50,000 人が参加するコミュニティ。エンタープライズアーキテクチャ、クラウドコンピューティング、ビッグデータ、データサイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論します。
QQグループ	[792862318] エンタープライズアーキテクチャ、ビジネスアーキテクチャ、アプリケーションアーキテクチャ、データアーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティアーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。
ビデオ番号	【スーパーアーキテクト】建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。
知識の惑星	著名人に質問したり、連絡を取ったり、個人情報を共有したりできます。
ヒマラヤ	道路や車の中で最新のブラックテクノロジー情報と建築体験について学びましょう。	[知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります]
知識の惑星	より多くの友人、職場、技術的なチャットに会いましょう。	ナレッジプラネット【職場とテクノロジー】
微博	【スマートな瞬間】	スマートな瞬間
ビリビリ	【スーパーアーキテクト】
チクタク	【cea_cio】スーパーアーキテクト
早い労働者	【cea_cio_cto】スーパーアーキテクト
小さな赤い本	[cea_csa_cto] スーパーアーキテクト

ご清聴、転送、いいね、ご視聴ありがとうございます。

[検索エンジン Solr] 最適なパフォーマンスを実現するために Solr を構成する