エイリアス
SolrCloud は、代替名を使用して1つまたは複数のコレクションをクエリする機能を備えています。コレクションのこれらの代替名はエイリアスとして知られており、次のような場合に役立ちます。
-
ダウンタイムなしで、新しく(再)インデックスされたコレクションの使用にアトミックに切り替える(エイリアスの再定義によって)
-
クライアントプログラミングをコレクション名の変更から保護する
-
同一のスキーマを持つ複数のコレクションに対して単一のクエリを発行する
エイリアスには、標準エイリアスとルーティングエイリアスの2種類があります。ルーティングエイリアス内には、カテゴリルーティングエイリアスと時間ルーティングエイリアスの2種類があります。これらの種類については、このセクションで説明します。
コレクション更新コマンドをエイリアスに送信することは可能ですが、単一のコレクションに解決されるもの、または複数のコレクション間のルーティングを定義するもの(ルーティングエイリアス)のみです。それ以外の場合は、複数のコレクション間でドキュメントを分散させるロジックがないため、更新コマンドはエラーで拒否されます。
標準エイリアス
標準エイリアスは、CREATEALIAS コマンドを使用して作成および更新されます。
エイリアスのメンバーであるコレクションの現在のリストは、CLUSTERSTATUS コマンドで確認できます。
エイリアスのすべての定義（ルーティングエイリアスの場合はメタデータを含む、下記参照）は、LISTALIASES コマンドで確認できます。
あるいは、ネイティブ ZooKeeper クライアントまたは管理 UI のクラウドメニューのツリーページで ZooKeeper の/aliases.jsonを確認することで、この情報を入手できます。
エイリアスは、DELETEALIAS コマンドで削除できます。エイリアスを削除しても、基盤となるコレクションには**影響ありません**。
|
複数のコレクションを参照するエイリアス（標準またはルーティング済み）は、関連性の複雑化を招く可能性があります。デフォルトでは、SolrCloudはシャードごとにドキュメントのスコアを計算します。 エイリアスに複数のコレクションが含まれる場合、これは常に問題となります。そのため、BM25またはTF/IDFの関連性が重要なユースケースがある場合は、ExactStatsCacheの実装のいずれかを有効にする必要があります。 ただし、数値、日付、または英数字のフィールド値で結果をソートする分析的なユースケースの場合、関連性の計算ではなく、これは問題になりません。 |
ルーティング済みエイリアス
標準エイリアスに関連する更新の制限に対処し、追加の便利な機能を提供するために、ルーティング済みエイリアスの概念が開発されました。現在、時間ベースルーティングとカテゴリベースルーティングの2種類のルーティング済みエイリアスがあります。これらについては以下で詳しく説明しますが、いくつかの共通の動作を共有しています。
ルーティング済みエイリアスの更新を処理する場合、Solrは通常どおりUpdate Request Processorsチェーンを初期化しますが、DistributedUpdateProcessor（DUP）が初期化されると、更新がルーティング済みエイリアスをターゲットにしていることを検出し、自身の前にRoutedAliasUpdateProcessor（RAUP）を挿入します。RAUPは、オーバーシーアと連携して、ルーティング済みエイリアスの主要部分であり、DUPの直前に配置する必要があります。RAUPとDUPの間に他のタイプのUpdateRequestProcessorsを使用してカスタムチェーンを設定することはできません。
理想的には、ルーティング済みエイリアスのユーザーは、コレクションの命名パターンを詳細に知る必要はありません。クエリと更新の両方をエイリアス経由で行うことができます。データを追加する場合は、通常、ドキュメントをエイリアスに直接送信する必要があります（つまり、コレクションではなくエイリアス名を指定します）。SolrサーバーとCloudSolrClientは、エイリアスが指す最初のコレクションに更新リクエストを送信します。サーバーがデータを受信すると、必要なルーティングを実行します。
| すべてのルーティング済みエイリアスにおいて、ルート値を変更しないことが非常に重要です。同じIDを持つドキュメントを異なるルート値で再インデックスすると、エイリアスからアクセスできる同じIDを持つ2つの異なるドキュメントが作成されます。重複するIDが存在する場合、ルーティング済みエイリアスのすべてのクエリ時の動作は未定義であり、容易に予測できません。 |
| ルーティング済みエイリアスでは、「データ駆動型」モード（別名スキーマレスモード）を使用することはお勧めできません。重複するスキーマの変更が同時に発生し、エラーが発生する可能性があります。 |
時間ベースルーティング済みエイリアス
時間ベースルーティング済みエイリアス（TRA）は、エイリアスと時間順序付けられたコレクションのシーケンスを管理するSolrCloud機能です。
タイムスタンプに基づいてドキュメントを正しいコレクションにルーティングするため、新しいコレクションを自動的に作成し（オプションで）、古いコレクションを削除します。このアプローチにより、単一インデックスの継続的な成長によって発生するパフォーマンスの低下なしに、データの無期限のインデックス作成が可能になります。
ログやIoTセンサーデータなど、大量のタイムスタンプ付きデータをSolrに保存する必要がある場合、この機能は、単一のシャード化されたハッシュルーティング済みコレクションを作成するよりも適切です。
動作方法
最初に、必要なルーター設定を使用してCREATEALIASコマンドで時間ベースルーティング済みエイリアスを作成します。設定のほとんどは、後でALIASPROPコマンドを使用して編集できます。
最初のコレクションは、それを指すエイリアスとともに自動的に作成されます。TRAのメンバーであるコレクション内の各基盤となるSolr「コア」には、エイリアスを参照する特別なコアプロパティがあります。各コレクションの名前は、TRA名と開始タイムスタンプ（UTC）で構成され、末尾のゼロと記号は切り捨てられます。
TRAのコレクションリストは常に逆順にソートされるため、リクエストの接続パスはリードコレクションにルーティングされます。基盤となる物理的なHTTPリクエストの数を1つ減らすことができるため、CloudSolrClientの使用が推奨されます。特定のドキュメントセットが特定の古いコレクションに配信されることがわかっている場合、クライアント側から最適化としてそこに直接送信できますが、必須ではありません。CloudSolrClientはまだこれを行っていません。
RAUPは、初期化時にエイリアスプロパティからTRA構成を最初に読み取ります。各ドキュメントを確認すると、TRAプロパティの変更を確認し、必要に応じてキャッシュされた構成を更新し、ドキュメントが属するコレクションを決定します。
-
RAUPがクライアントが通信するために選択したコレクション以外の、コレクションによって表される時間セグメントにドキュメントを送信する必要がある場合、DUPと共有されるメカニズムを使用してそうします。ドキュメントが正しいコレクション（つまり、正しいTRA時間セグメント）に転送されると、ターゲットコレクションのDUPに直接スキップし、通常どおり続行され、ターゲットコレクション内の正しいシャードとレプリカに再びルーティングされる可能性があります。
-
現在のコレクションに属している場合（イベントが発生したときに処理している場合がほとんどです）、ドキュメントはDUPを通過します。DUPは、ドキュメントを別のシャードとレプリカにルーティングする可能性のある、通常の集合レベルの処理を実行します。
-
ドキュメントのタイムスタンプが最新のTRAセグメントよりも新しい場合、TRAの先頭に新しいコレクションを追加する必要があります。RAUPはこのコレクションを作成し、エイリアスに追加し、作成したばかりのコレクションにドキュメントを転送します。複数のコレクションを作成する必要がある場合、これは再帰的に発生する可能性があります。
新しいコレクションが追加されるたびに、構成されている場合は、TRA内の最古のコレクションを削除の可能性について調べます。これらすべては同期的に発生するため、更新リクエストとインデックス作成の待ち時間に数秒追加される可能性があります。
router.preemptiveCreateMathが構成されており、ドキュメントがこのウィンドウ内に到着した場合、非同期的に発生します。時間ベースルーティング済みエイリアスパラメーターの詳細を参照してください。
コミットや削除などの他のタイプの更新は、RAUPによってすべてのコレクションにルーティングされます。一般的に、これはパフォーマンス上の懸念事項ではありません。何も削除されていないか、コミットする必要がない削除またはコミットをSolrが受信した場合、非常に安価です。
制限事項と仮定
-
サポートされているのは時間ベースルーティング済みエイリアスのみです。代わりに、他の連続番号がある場合は、時間として偽装できます（たとえば、あるエポックを仮定してタイムスタンプに変換し、増分します）。
可能な最小間隔は1秒です。他のルーティングスキームはサポートされていませんが、この機能は他のスキームに拡張/改良できることを考慮して開発されました。
-
基盤となるコレクションは、ギャップのない連続シーケンスを形成します。基盤となるデータに大きなギャップがある場合は、適切ではありません。Solrは、各増分のコレクションが存在することを要求します。これは、部分的には、Solrが次のコレクションのタイムスタンプに基づいて各インターバルコレクションの終了時間を計算するためです。それ以外の方法では保存されません。
-
古いコレクションを自動的に削除するように構成している場合、最古のコレクションに更新を送信しないでください。インデックス作成クライアントに例外がバブルバックされる可能性があります。
カテゴリベースルーティング済みエイリアス
カテゴリベースルーティング済みエイリアス（CRA）は、単一フィールドの値に基づいてエイリアスと一連の依存コレクションを管理する機能です。
CRAは新しいコレクションを自動的に作成しますが、パーティション分割は連続した数値ベースの値ではなくカテゴリ情報に基づいているため、自動削除のためのロジックはありません。このアプローチにより、クラスタ管理またはセキュリティ上の理由でコレクションに分割する必要があるデータの簡素化されたインデックス作成が可能になります。
動作方法
最初に、必要なルーター設定を使用してCREATEALIASコマンドでカテゴリベースルーティング済みエイリアスを作成します。設定のほとんどは、後でALIASPROPコマンドを使用して編集できます。
エイリアスは、常にmyAlias__CRA__NEW_CATEGORY_ROUTED_ALIAS_WAITING_FOR_DATA__TEMPという名前の特別なプレースホルダーコレクションとともに作成されます。CRAにインデックスされた最初のドキュメントは、foo（ルーティングされたフィールド値がfooの場合）という名前の2番目のコレクションを作成します。インデックスされた2番目のドキュメントにより、一時的なプレースホルダーコレクションが削除されます。その後、フィールドの新しい値が検出されるたびにコレクションが作成されます。
| コレクション作成の暴走を防ぐために、カテゴリの総数を制限し、一致しない値を拒否するためのオプションとして、正規表現パラメーターが提供されています（詳細についてはカテゴリベースルーティング済みエイリアスパラメーターを参照してください）。 |
+ これらのオプションに非常に大きい値または非常に許容範囲の広い値を指定すると、データの破損により数千のコレクションが作成され、クラスタが停止するリスクを受け入れることになります。
フィールド値（したがってコレクション名）は大文字と小文字が区別されます。
Solrの他の場所と同様に、データの操作とクレンジングは、データがSolrに送信される前に外部プロセスによって実行されることが期待されます。ただし、例外が1つあります。Solr全体では、コレクション名で使用できる文字に制限があります。ASCII英数字（A-Za-z0-9）、ハイフン（-）、またはアンダースコア（_）以外の文字は、カテゴリのコレクション名を計算するときにアンダースコアに置き換えられます。myAliasという名前のCRAの場合、次の表にコレクション名の計算方法を示します。
| 値 | CRAコレクション名 |
|---|---|
foo |
myAlias__CRA__foo |
Foo |
myAlias__CRA__Foo |
foo bar |
myAlias__CRA__foo_bar |
FOÓB&R |
myAlias__CRA__FO_B_R |
中文的东西 |
myAlias__CRA_______ |
foo__CRA__bar |
400 Bad Requestエラーが発生します |
<null> |
400 Bad Requestエラーが発生します |
コレクションの作成には1〜3秒かかることがあるため、CRAにデータ挿入するシステムは、新しいコレクションが作成されるたびにこのような一時停止を処理するように構築する必要があります。時間ベースルーティング済みエイリアスとは異なり、次の値を予測する方法はないため、このような一時停止は避けられません。
カテゴリを自動的に削除する手段はありません。CRAからカテゴリを削除する必要がある場合は、次の手順をお勧めします。
-
削除するカテゴリに対応する値を持つドキュメントが、インデックス作成の中止または受信データストリームの修正によって送信されないようにします。
-
ZooKeeperのエイリアス定義を変更し、カテゴリに対応するコレクションを削除します。
-
カテゴリに対応するコレクションを削除します。最初にコレクションをエイリアスから削除しないと、この手順は失敗することに注意してください。
多次元ルーティングエイリアス
データの必要な分離が2つのフィールドに関連し、インデックス作成時の単一フィールドへの結合が非現実的である場合、または複数のカテゴリにわたってTRAの動作が望ましい場合、多次元ルーティングエイリアスを使用できます。この機能は、任意の数と組み合わせのカテゴリと時間ディメンションを任意の順序で処理するように設計されていますが、ユーザーは、このような構成から生じるコレクションの総数を慎重に検討する必要があります。数百から1000個程度の大量のコレクションは、ZooKeeperで大きな課題となります。
| DRAは新しい機能であり、現在は2つのディメンションのみがサポートされています。将来、より多くのディメンションがサポートされます（進捗状況についてはhttps://issues.apache.org/jira/browse/SOLR-13628を参照してください）。 |
動作方法
まず、各ディメンションに必要なルーター設定で多次元ルーティングエイリアスを作成します。ディメンションごとの設定の指定方法の詳細については、CREATEALIASコマンドのドキュメントを参照してください。典型的なコレクション名は、次のような形式になります（例は、カテゴリ×時間の例で、30分間隔）。
myalias__CRA__someCategory__TRA__2019-07-01_00_30初期コレクションは、カテゴリベースのディメンションを含むすべてのDRAの使い捨てのプレースホルダーになります。コレクション名の各サブパートの生成は、対応するコンポーネントディメンションタイプのポーションと同一です（例：カテゴリ値を生成するCRAまたはTRAは、依然としてエラーを生成します）。
| 異なるルート値を持つドキュメントの再インデックス作成に関する前の警告は、DRAのすべてのディメンションに適用されます。DRAは、ルーティングに使用されるカテゴリまたはタイムスタンプが変更されるドキュメントには適していません（これはもちろん、将来のRAタイプにおける他のルート値にも適用されます）。 |
すべてのルーティングエイリアスと同様に、DRAはデータが適切に動作しない場合、いくつかのコストを課します。各コンポーネントディメンションの通常の注意事項に加えて、DRAがしばらく実行された後に新しいカテゴリを送信する場合に注意が必要です。順序付きディメンション（時間）は、順序付けられていない（カテゴリ）ディメンションとは少し異なる動作をします。順序付きディメンションは、エイリアス内のコレクションの反復順序に依存するため、コレクション名の順序外での生成を許容できません。つまり、時間のような順序付きディメンションがDRAのコンポーネントであり、DRAが開始時間スライス以外の時間値を持つ新しいカテゴリを持つドキュメントの受信を経験した場合、ドキュメントをインデックス作成する前に、いくつかのコレクションを作成する必要があります。この「新しいカテゴリ効果」は、開始日を過去に設定しすぎた場合にTRAで得られる動作と同じです。
たとえば、開始時間が2019-07-01T00:00:00ZであるDimensional[time,category] DRAの場合、4つのドキュメントに対して作成されるコレクションのパターンは次のようになります。
ドキュメントなし
エイリアスコレクション
myalias__TRA__2019-07-01__CRA__NEW_CATEGORY_ROUTED_ALIAS_WAITING_FOR_DATA_TEMPドキュメント1
-
時間：2019-07-01T00:00:00Z
-
カテゴリ：someCategory
エイリアスコレクション
myalias__TRA__2019-07-01__CRA__NEW_CATEGORY_ROUTED_ALIAS_WAITING_FOR_DATA_TEMP
myalias__TRA__2019-07-01__CRA__someCategoryドキュメント2
-
時間：2019-07-02T00:04:00Z
-
カテゴリ：otherCategory
エイリアスコレクション
myalias__TRA__2019-07-01__CRA__someCategory
myalias__TRA__2019-07-01__CRA__otherCategory // 2 collections created in one update
myalias__TRA__2019-07-02__CRA__otherCategoryドキュメント3
-
時間：2019-07-03T00:12:00Z
-
カテゴリ：thirdCategory
エイリアスコレクション
myalias__TRA__2019-07-01__CRA__someCategory
myalias__TRA__2019-07-01__CRA__otherCategory
myalias__TRA__2019-07-02__CRA__otherCategory
myalias__TRA__2019-07-01__CRA__thirdCategory // 3 collections created in one update!
myalias__TRA__2019-07-02__CRA__thirdCategory
myalias__TRA__2019-07-03__CRA__thirdCategoryドキュメント4
-
時間：2019-07-03T00:12:00Z
-
カテゴリ：someCategory
エイリアスコレクション
myalias__TRA__2019-07-01__CRA__someCategory
myalias__TRA__2019-07-01__CRA__otherCategory
myalias__TRA__2019-07-02__CRA__otherCategory
myalias__TRA__2019-07-01__CRA__thirdCategory
myalias__TRA__2019-07-02__CRA__thirdCategory
myalias__TRA__2019-07-03__CRA__thirdCategory
myalias__TRA__2019-07-02__CRA__someCategory // 2 collections created in one update
myalias__TRA__2019-07-03__CRA__someCategoryしたがって、DRAの最適なポイントは、変更されない標準化されたディメンションセットを持ち、すべての順列が定期的に発生するデータセットです。後で新しいカテゴリが導入され、インデックス作成の待ち時間が重要なSLA機能である場合、この効果を軽減するためのいくつかの戦略があります。
-
作成する必要がある追加の時間スライスの数がそれほど多くない場合は、通常のインデックス作成から帯域外で単一のドキュメントを送信し、コレクションの作成が完了するまで待ってから、新しいカテゴリをSLA制約プロセス経由で送信することを許可します。
-
上記の手順によって大量のコレクションが作成される可能性があり、新しいカテゴリの可能な限り早いドキュメントがわかっている場合は、ALIASPROPコマンドを使用して、時間ディメンションの開始時間を調整できます。
改善の可能性
ルーティングエイリアスはSolrCloudの比較的新しい機能であり、改善されることが予想されます。まだ実装されていない潜在的な改善分野をいくつか紹介します。
-
TRA：時間フィルターを使用した検索は、該当するコレクションのみにアクセスする必要があります。
-
TRA：更新を受け取ると予想されず、検索需要が少ない可能性のある古いコレクションを自動的に最適化（またはリソースを削減）する方法。
-
CRA：Base64エンコードによる英語以外のテキストの固有のサポート。
-
CRA：事前にわかっている場合に値の初期リストを提供し、インデックス作成中の停止を減らす。
-
DRA：2つ以上のディメンションのサポート。
-
CloudSolrClientは、常に最新/最初のものを選択するのではなく、ルート値に基づいてドキュメントを正しいコレクションにルーティングできます。 -
現在、更新のみがルーティングされ、クエリはエイリアスのすべてのコレクションに分散されていますが、将来の機能では、特別なパラメーターまたはルーティングされたフィールドのフィルターに基づいて、クエリを単一の適切なコレクションにルーティングできるようになる可能性があります。
-
コレクションは、時間またはカテゴリ値の代わりに、または時間またはカテゴリ値に加えて、サイズによって制限される場合があります。これは、別のタイプのルーティングエイリアスとして、または既存のルーティングエイリアスのオプションとして実装される可能性があります。
-
基礎となるコレクションも1つのステップで削除するエイリアスの削除オプション。ルーティングエイリアスは、初期テスト中に予想以上に多くのコレクションを迅速に作成する可能性があります。このようなイベント後の削除は非常に面倒です。
いつものように、パッチとプルリクエストは大歓迎です！
コレクションコマンドとエイリアス
SolrCloudは、通常コレクション名が期待される場所で、コレクションコマンドでエイリアス名を使用することをサポートしています。これは、次の基準が満たされている場合のみ機能します。
-
リクエストパラメータ
followAliases=trueが使用される -
エイリアスは、1つを超えるコレクションを参照してはならない
-
エイリアスはルーティングエイリアスを参照してはならない
すべての基準が満たされている場合、コマンドはすべてのエイリアス名を解決し、コレクション名が代わりに使用されたかのように、エイリアスが参照するコレクションで動作します。それ以外の場合は、コマンドは実行されず、例外がスローされます。
followAliases=trueパラメータは、解決されたターゲットが実際に意図したものであるように、注意して使用する必要があります。複数レベルのエイリアスまたはシャドウエイリアス（既存のコレクションと同じ名前だが、他のコレクションを指しているエイリアス）の場合、このオプションの使用は、効果を正しく予測することが困難なため、強くお勧めしません。