複数のインデックス (シャーディング)
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
インデックスシャーディングは、インデックス内のドキュメントを小さなパーティションに分割するプロセスです。これらの小さなパーティションは シャードと呼ばれます。その結果、すべてのドキュメントが1つの大きなインデックスに含まれるのではなく、ドキュメントがシャード間で分散されます。シャーディング プロセスには、ドキュメントをシャードに割り当てる方法を決定するロジック ("シャーディング戦略") があります。
1つのインデックスでほとんどのSitecoreソリューションのニーズを満たすことができますが、必要に応じて複数のインデックスを使用すると、より優れたスケーリングが可能になります。
シャーディングとSolr
シャーディングとSolr
Solrを使用する場合、Sitecoreはシャーディングを処理しません。代わりに、SolrアプリケーションのSolrCloud機能がシャーディングを処理します。
Solrは、ドキュメントをシャードに自動的に割り当てることができ (SitecoreがLuceneで実行できるのと同様)、レプリケートされたシャードなどの追加機能があります。レプリケートされたシャードは、障害やフェイルオーバーのシナリオを処理するのに役立ちます。
SolrのSitecore実装は、シャード化されていないエンドポイントと同じ方法でシャード化されたエンドポイントを処理します。Solrシャード・インデックスを操作するために、追加の構成は必要ありません。
Sitecoreはフェイルオーバーを完全にはサポートしていません。具体的には、現在のサーバー (リーダー) がダウンした場合、Sitecore (Solrクライアントとして) はSolrサーバー (Solrレプリカ) を切り替えることができません。
SolrCloudの構成の詳細については、https://cwiki.apache.org/confluence/display/solr/SolrCloudを参照してください。
シャーディングとLucene
シャーディングとLucene
Luceneを使用すると、3つのSitecoreデータベース (master、web、core) のそれぞれのデータがデフォルトで1つの検索インデックスに保存されます。検索インデックスが大きくなるにつれて、シャーディング戦略を実装して、各データベースのデータを個別の検索インデックスに格納できます。
他の方法でシャードすることもできます。たとえば、メディアライブラリ用に別のインデックスを持つことができます。
バケットを使用し、数千または数百万の項目がある場合、シャーディングはLuceneを引き続き使用する場合に使用できるアプローチです。検索インデックスが増大を続け、この戦略に対して大きくなりすぎる場合は、Solrを使用するように切り替える必要があります。
シャーディングを使用する場合は、他のLucene設定ファイルを有効にしておくと冗長なインデックスが作成されるため、オフにする必要があります。
複数の検索インデックスを構成する
Sitecoreには、各データベースのインデックスを作成するのに役立つ次の設定ファイルの例が用意されています。
Sitecore.ContentSearch.Lucene.Indexes.Sharded.Core.config.example
Sitecore.ContentSearch.Lucene.Indexes.Sharded.Master.config.example
Sitecore.ContentSearch.Lucene.Indexes.Sharded.Web.config.example
これらのファイルは、Includeフォルダ(wwwroot\<site name>\Website\App_Config\Include).
これらの設定ファイルが十分にシャード化されていない場合は、ニーズに合わせて設定を変更できます。
次のコード サンプルと表を使用して、追加する必要があるものを確認します。
|
名前 |
形容 |
例 |
|---|---|---|
|
<Root> |
インデックスに含めるコンテンツ ツリーのルート ノードを指定します。 |
<Root>/sitecore/media library</Root> |
|
<name> |
検索インデックスの名前。 |
<param desc="name">$(id)</param> |
|
<Database> |
データベース名。 |
<Database>core</Database> |
|
<strategies> |
実行するインデックス戦略のリスト。 |
<strategies hint="list:AddStrategy"> <strategy ref="contentSearch/indexUpdateStrategies/intervalAsyncCore" /> </strategies> |
|
<CommitPolicy> |
インデックスがメモリ内または一時ファイルにあるものをディスクにコミットするタイミングを制御します。これは、時間ベースまたはドキュメント数ベースにすることができます。 |
<commitPolicy hint="raw:SetCommitPolicy"> <policy type="Sitecore.ContentSearch.TimeIntervalCommitPolicy,Sitecore.ContentSearch"/> </commitPolicy> |
|
<commitPolicyExecutor> |
コミットを実行するクラス。 |
<commitPolicyExecutor hint="raw:SetCommitPolicyExecutor"> <policyExecutor type="Sitecore.ContentSearch.CommitPolicyExecutor, Sitecore.ContentSearch" /> </commitPolicyExecutor> |
インデックス コンテキスト スイッチャー
シャーディングを使用する場合、SitecoreはContext.Itemに関連する <Root> 要素を使用して、使用するインデックスを決定します。このインデックスの切り替えは自動的に行われます。
<Root>が具体的であるほど、設定ファイルに上位にリストする必要があります。インデックス コンテキスト スイッチャーは、インデックスをリストされている順序で使用します。
たとえば、インデックス<Root>要素が /sitecore/content/Homeの場合、<Root> 要素のインデックスの下に配置する必要があります/sitecore/content/Home/Flights
デフォルトのシャーディング戦略
Sitecoreには、LucenePartitionShardingStrategyと呼ばれるデフォルトのシャーディング戦略が用意されています。この戦略では、ドキュメントを取得し、IDのハッシュを計算して、どのシャードに配置するかを決定します。このハッシュは非常に高速で、共有状態やID生成に依存しません。このアプローチでは、完全に均等な分散が得られるわけではありませんが (たとえば、100個のドキュメントが50/50に分割されないなど)、パフォーマンスが大幅に向上します。
この戦略には、shardDistributionパラメーターという1つのオプションしかありません。このパラメーターは係数2 (2、4、8、16、...) に設定する必要があり、これによりインデックスが分割されるシャードの数が指定されます。
新しいシャーディング戦略の作成
デフォルトの戦略が必要としない場合は、独自の戦略を実装できます。これを行うには、Sitecore.ContentSearch.Sharding.IShardingStrategyインターフェイスを使用し、実装をインデックスに渡します。
戦略を適用した後でインデックスを再構築する必要があります。これは必須ではありませんが、インデックスにドキュメントのより均一な分布を提供します。