こんにちは、Janさん、

TRA（または任意のRouted Alias）について覚えておくべき重要なことは、次の2つのことを行うだけだということです：
1）ドキュメントの更新を正しいコレクションにルーティングするために、ドキュメント内のルーティングフィールドを調べます。
2）新しいコレクションが必要な場合に検出し、作成します。

データを送信しない場合、何も起こりません。コレクションはデータが必要になるまで作成されません（次のインターバルに「近い」タイムスタンプの更新を検出すると、非同期の作成が可能です。詳細は、router.preemptiveCreateMathのドキュメントを参照してください）。

A）2018年のアクティベートのトークで、Daveがその半分について話しています：https://youtu.be/RB1-7Y5NQeI?t=839
B）Time Routed Aliasは、コレクションの自動作成とドキュメントの作成されたコレクションへのルーティング手段です。個々のコレクションのサイズとパフォーマンスは特に特別なものではなく、作成後は個々のコレクションとやり取りできます。ただし、おそらく、クライアントプログラムが両方のタイプのドキュメントをどのように処理するかを知らない限り、スキーマが同期されないような操作は行いたくないでしょう。ルーティングのあまり明白でない結果として、データは決して同じドキュメントを異なるルートキー（TRAの場合は日付）で再公開してはいけません。それはコレクション全体で重複したIDを引き起こす可能性があります。通常の使用例は、イベントデータ、発生したこと、そして正確に記録されたもの（または少なくともその時間が正確に記録されたもの）です。
C）レプリカの数を増やし、不要な場合は古いものを手動で削除します。クエリ時には「単なるエイリアス」です。ここで最近のものに基づいてコレクションを管理することは自動化できます。自動スケーリングが非推奨になる前に、TRAがコレクションの作成に反応するようにいくつかのフックを追加することで、ElasticのHot/Warmアーキテクチャのような場所に到達すると考えていました。ただし、自動スケーリングを置き換えるために行われていることを追跡していません。一度Atriもそれに興味を持っていたようです。
D）TRAは、手動で行うのと同じように、作成されるコレクションをフックの下に作成します（TRAの設定に基づいて）。その配置に影響を与えるSolrの何かがある場合、それが適用されるはずです。
E）上記のDを参照してください。時間の経過とともに新しいノードを利用することは、新しいノードを追加して新しいコレクションが作成されるのを待つだけで簡単です。他のコレクションと同様にレプリカを手動で移動することもできます（注：8.6以前のバージョンのMOVEREPLICAドキュメントを参照する場合、いくつかの箇所が不完全でさらに間違っていたことがあります）。
F）ここでrouter.autoDeleteAgeについて話しているのであれば、古いコレクションの削除は通常のDELETEです（ただし、自動的に発行されます）。回転間隔とは何かはわかりません。
G）これらは、更新中に解析されて入力ドキュメントの宛先を選択するための特別な名前のコレクションです。
H）これらはただのコレクションであり、スキーマをアップグレードすることを妨げるものは何もありません。新しいコレクションがそれを使用し始めますが、個々のコレクションは再読み込みする必要があります。一般的な意味での安全でないスキーマ変更については、通常どおり再インデックスが必要です。クラウド環境では、一時的にマシンやディスクを追加できるため、再インデックスにかかる時間を除いて、それほど悪い状況ではありません。オンプレミスの場合は、セグメントのマージの危険ゾーンに自分自身を追い込まないように、十分な予備ディスクを備えることを計画してください。
H.2）TRAは、ファンシーなコレクションの作成（および命名）というだけのエイリアスです。一度コレクションが存在すると、それはただのエイリアスです。すべてのアクション（この時点では）は更新時に行われます。コレクションがZooKeeperのaliases.jsonにTRAにリストされている限り*（正確な（年代降順）の順序で）、およびコレクションの名前がTRAコードによって解析できる限り、問題ありません。更新が行われると、受信中の更新はコレクションのリストを下に反復し、ドキュメントのルーティングフィールドの日付と一致する最初のコレクションで停止します。通常のTRAでは、更新の大部分が最も新しい2つまたは3つのコレクションのいずれかに当たります。非常に多くの時間スライス（サブコレクション）を持つTRAで古いデータを頻繁に更新する場合、これは単純な線形反復なので若干の問題が発生する可能性があります。最適化は、それが重要な場合に備えて誰かの通常ではない使用例に遅延されました :)

それ以外の場合、それはただの不思議な名前のコレクションのエイリアスです（私が見ていない間に誰かが何かを追加した場合を除きます ;)）。

Gus

こんにちは、Gus、Jan、

大規模なSolr展開でTRAを実装することを検討しています。Q&Aが役立ちます！

手動で古いコレクションを削除したり、router.autoDeleteAgeを変更して削除年齢を短縮または延長したりする場合に、TRAエイリアスを変更する経験やアイデアがあるかどうかについて興味があります。いくつかの具体的な質問があります。

1）古いコレクションを手動で削除（コレクションAPI経由）してから、TRAの開始日を編集して（より新しい日付に）削除されたコレクションをもはや参照/処理しないようにできますか？
2）TRA内のコレクションの削除を管理する唯一の方法は、自動削除構成を使用することですか？ router.autoDeleteAgeパラメータ。
3）router.autoDeleteAgeパラメータを使用して削除を管理する場合、このパラメータを更新して、次のどちらかを行うことはできますか？

• 削除年齢を早めに設定して、古いコレクションが早めに自動削除されるようにしますか？
• コレクションの寿命を延長するために削除年齢を大きな値に設定しますか？元々コレクションを5年間残したいと思っていましたが、その後7年間に変更したいと思っています。

私はおそらくいくつかの実験を行うでしょうが、TRAのこれらの使用ケースをカバーしたかどうかについて知ることに興味があります。

ありがとうございます、
Matt

テスト中に役立つ情報を見つけました：

私たちのユースケースでは、autoDeleteAgeを設定することに躊躇しています（それが修正可能である場合を除きます - まだテストする必要があります）。そのため、少し手動の削除管理アプローチについて考えました。

登録されたTRAの一部として削除されているコレクションを単純に削除することはできないことを確認しました。削除コレクションAPI呼び出しは、そのコレクションがエイリアスの一部であるというメッセージで失敗します。

私は、使用したTRAを作成するために使用した同じcreate TRA API呼び出しを使用できることを学びましたが、その際にrouter.startを、TRAに関連付けられた1つまたは複数の古いコレクションよりも新しい日付に変更できます。その後、TRAをクエリしたときに、新しいrouter.start日付以降のコレクションからのドキュメントのみを受け取りました。また、今度は、標準のコレクション削除コマンドで古いコレクションを正常に削除できました。

既存のTRAを修正し、古いコレクションを削除できるようにするための初期のユースケース要件を満たしていると考えています。

Matt

TRAの成功を祈っています！

TRAの連鎖の末尾からいくつかのコレクションを削除することはできますが、まずこれらのコレクションを除外するようにTRAを更新する必要があります。これはテストされています：
https://github.com/apache/solr/blob/f6c4f8a755603c3049e48eaf9511041252f2dbad/solr/core/src/test/org/apache/solr/update/processor/TimeRoutedAliasUpdateProcessorTest.java#L184
TRAがエイリアスから自動的に削除されると良いですね。

〜 David Smiley
Apache Lucene/Solr検索開発者
http://www.linkedin.com/in/davidwsmiley

David、このテストリンクは役立ちますね。

David、Gus、あなたの視点から見て、SolrCloud内でTRAは受け入れられた/実証されたテクニックと見なされていますか？私の小さなPOCはうまく機能しています。他の人々がTRAを本番環境で大規模に成功裏に展開しているかどうかを聞いてみたいです。

ありがとうございます、
Matt

他の方々がTime Routed Aliases（TRA）をどのように活用しているかについての情報を再度お送りします。

私たちのチームは非常に大規模なSolrCloud展開でTRAの利用を計画しているため、他の方々がこのアプローチをどのように成功裏に利用しているかを知りたいと思います。

ありがとうございます、
Matt

こんにちは、Matt

TRAは、Daveと私が実装した直後から、少なくとも1つの組織でほぼすぐに使用されました。そして、同じ組織がデータをさらに細分化したいと考えて、CRAやDRAが続いて実装されました。これらは長い間存在しており、現在はクライアントがそれらを使用する移行を支援していますし、過去のクライアントも採用しています。実際にどれだけの機能が使用されているかは常にわかりにくいですが、他の方々もそれらを使用しているという言及を聞いたことがあり、まだ失敗した話は聞いたことがありません。ですので、あなたのユースケースがそれらに適している場合（大量のデータ、同じドキュメントを異なるルーティング日付で再インデックスしない、通常はデータが経時的に流れ込み、オプションで古いデータが定期的に削除される必要があるなど）、うまく機能するでしょう。もちろん、各ケースは個別であり、微妙な点を発見したり、何かがうまくいかなくなるスケールを見つけるかもしれませんが、最初の利用者ではないことは確かです : )。TRAは、大量の時系列データを処理するのをより簡単にするために作られています。

また、オープンソースですので、何か調整が必要な場合はそのプロセスが公開されており、定義されています。技術的なことは常によくテストし、よくテストしてください。

Gus

ありがとうございます、Gus！この情報は大変参考になります。POCから、TRAは非常に強力で非常に役立つことがわかりました。私は、標準的なTRAの使用の境界と完全な実装を構築することに興奮しています。

Matt