Alibaba Cloud Elasticsearch Agent Engine Edition では、Collection と Slice が連携して、多数のテナント、ナレッジベース、コードリポジトリをサポートし、これらのビジネス空間の成長に合わせて水平スケーリングを継続します。アプリケーションは単一の Collection エントリポイントを通じてデータにアクセスし、各 Slice は 1 つのビジネス空間を表すため、テナントごとに個別のインデックスを作成および維持する必要はありません。
ビジネス空間が拡大すると、システムは新しい Slice を利用可能なバッキングインデックス (Backing) に割り当てます。Backing が割り当てのしきい値に達すると、システムは他の Backing に切り替えるか、新しい Backing を作成して、より多くのシャードが新しい Slice を保持できるようにします。Collection レベルでは、ビジネスの規模は単一インデックスの事前設定されたシャード数によって制限されなくなり、アプリケーションは元の Collection 名と Slice のアクセス方法を使い続けます。このスケーリングは Collection 全体に適用されます。個々の Slice は、それが所属する Backing のシャード設定を引き続き使用し、システムが新しい Backing を作成しても、既存の Slice が自動的に分割または移行されることはありません。
Agent Engine Edition は、ステートレスアーキテクチャに基づいて構築されています。永続ストレージはデータ量に応じて拡張され、実際の使用量に基づいて課金されます。また、書き込みリソースとクエリリソースは個別にスケーリングします。これにより、データ規模、テナント数、アクセス負荷が、それぞれのペースで成長できます。
基本用語
用語 | 意味 | 例 |
Collection | アプリケーションがデータにアクセスするためのエントリポイントとして使用するデータセットです。Collection は、フィールドタイプ (マッピング) とインデックス設定 (設定) を一元的に定義します。 |
|
Slice | Slice は、業務単位で分割され |
|
バッキングインデックス (Backing) | システムが実際にドキュメントを格納する Elasticsearch インデックスです。1 つの Backing は複数の Slice を保持できます。システムが割り当てを処理し、アプリケーションは Collection と Slice を通じてデータにアクセスします。 |
|
Slice はアカウントのアクセス許可の境界ではありません。テナント認証は、お客様のアプリケーション、または Agent Engine Edition がサポートするセキュリティメカニズムの役割です。マルチテナント設計を最終決定する前に、「次のステップ」に記載の Agent Engine Edition の使用制限と Collection のアクセス許可に関するトピックをご確認ください。
同じ Collection 内の Slice はマッピングを共有しますが、ドキュメントはそれぞれ独自に管理します。たとえば、tenant-a と tenant-b は、互いに上書きすることなく同じドキュメント ID を使用できます。アプリケーションで、Slice 名とドキュメント ID の両方を保存してください。
ビジネスに合わせたデータスコープの選択
アプリケーションがクエリに必要なデータを識別する方法に適したデータスコープモードを選択してください。クエリの実行前に、アプリケーションがテナント、ナレッジベース、またはリポジトリ識別子をすでに認識している場合、_slice を使用して 1 つ以上のスライスを選択します。このアプローチは、名前空間モード (exact) と呼ばれます。exact の設定箇所を示す完全な例については、「開始方法: テナントまたはナレッジベースによる検索」をご参照ください。
ベクターがオフラインですでにクラスタリングされており、クエリベクターから候補クラスターを自動的に選択する必要がある場合は、ベクタークラスターリコールを使用してください。ベクタークラスターリコールの候補 Slice 数は、再現率とクエリコストの両方に基づいて設定してください。どちらのモードも Sliced DiskBBQ をサポートしており、選択された Slice 内でベクター検索を実行できます。詳細については、「DiskBBQ と Sliced DiskBBQ によるベクター検索」をご参照ください。
テナント一括登録前の Backing の準備
デフォルトでは、Backing はオンデマンドで作成されます。テナントを登録したり、データを一括でインポートしたりする前に、いくつかの Backing を事前に作成し、その後で Slice を登録してビジネスドキュメントをインポートしてください。事前に作成することで、初回書き込み時のインデックス作成の待機時間が短縮され、新しい Slice のデータが複数の Backing に分散されるため、読み取りおよび書き込み負荷の分散に役立ちます。この操作は、既存のデータを再配布したり、コンピューティングノードを追加したりするものではありません。実際の負荷は各 Slice のデータ量とアクセス頻度に依存するため、これら 2 つの要因に基づいて事前作成する Backing の数を決定してください。
リクエストパラメーター、割り当てしきい値と割り当てポリシーの変更、レスポンス、リトライ ルールについては、「Backing の事前作成」をご参照ください。
水平スケーリングは Collection 全体に適用され、個々の Slice には適用されません。キャパシティパラメーターとその有効範囲については、「キャパシティパラメーターが有効になる仕組み」をご参照ください。
クエリスコープとコストの制御
テナントまたはナレッジベースでクエリを実行する際、ターゲットの Slice のみにアクセスすることで、他の Slice のデータの読み取りと計算が削減されます。新しいテナントが Collection に継続的に追加されても、単一のクエリは Collection 全体に拡大されるのではなく、現在のテナントのデータに集中します。
キーワードおよび全文インデックスクエリは、デフォルトで有効になっているメカニズムである スライスポスティング を通じて、無関係なデータをスキップします。ベクター検索は、Sliced DiskBBQ を通じてアクセススコープを絞り込みます。どちらのメカニズムも、無関係なデータの読み取りと計算を削減し、多数の Slice があり、各クエリがそのうちの少数にしかアクセスしないようなアクセスパターンに適しています。
通常のクエリは、1 つまたは少数の Slice 内に留めるようにしてください。フルクエリはターゲットの Slice ではなく Collection 全体に拡大され、そのコストは Backing とシャードの数に応じて増加します。したがって、フルクエリは、明確なスコープと負荷の予算がある分析タスクに適しています。
次のステップ
フィールド、キャパシティ、Slice のライフサイクル、およびアクセス名の設定： Collection と Slice の管理。
データの書き込みとクエリスコープの選択： ドキュメントの書き込み、読み取り、クエリ操作。
初回アクセス時のクエリ待機時間を短縮するには： 事前に Slice キャッシュのウォームアップ を行うことで、後続のクエリが毎回キャッシュをウォームアップするのではなく、キャッシュを再利用できるようにします。
完全なデータコピーの準備： Slice のコピー。独立して変更可能なブランチの迅速な作成： 書き込み可能なデータブランチ：Branch Slice (ベータ版)。
本番稼働の準備： Agent Engine Edition の使用制限 を確認し、Collection のアクセス許可 を設定してください。