Cells: Zoekt

1. 定義

2. データフロー

3. 提案

組織をあるセルから別のセルに移行するとき、Zoekt のデータは、 組織が所有するものか、セル内に限定されるものかによって、異なる方法で扱います。

組織が所有する有効化の状態

zoekt_enabled_namespaces テーブルは、Zoekt が有効な名前空間を記録しており、 組織が所有しています。このテーブルは、組織の他のデータとともに 移行先のセルに移行する必要があります。これにより、移動後も完全一致検索の 有効化の状態が保持されます。

セル内に限定される Zoekt の状態

特定のセル上の Zoekt の稼働状態を追跡するテーブル — zoekt_indices、zoekt_repositories、zoekt_replicas を含む — は、そのセル内に限定され、 移行先のセルに移行してはいけません。代わりに、次のようにします。

1. 移行先のセルは、自身の Zoekt ノードを使って、組織の リポジトリのインデックスを最初から作成し、インデックス作成の 進行に合わせて、これらのテーブルに新しい行を作成します。
2. 移行元のセル内に限定される行は移動後も保持し、 クリーンアップを進めるために使用します。行自体を削除する前に、移行元のセルの Zoekt ノードから組織のデータを削除します。

Zoekt の組織移行戦略は、高度な検索で使用する アプローチと似ています。組織が所有する 設定を移行先のセルに移行する一方で、セル内に限定される稼働 状態は最初から再構築し、セル間の直接的なデータ転送を避けます。

組織移行のワークフロー

flowchart TD
    A[Organization scheduled for migration] --> B
    B(Migrate zoekt_enabled_namespaces to destination cell) --> C
    C(Destination cell enqueues indexing for all organization repositories) --> D
    D(Source cell retains zoekt_indices/zoekt_repositories/zoekt_replicas for cleanup) --> E
    E(Source cell Zoekt nodes delete organization data using retained rows) --> F
    F(Source cell-local rows deleted)

4. 評価

4.1. 利点

1. セル間の Zoekt 移行を実装する必要がありません。
2. 既存のフレームワークは十分にテストされており、チームメンバーも理解しています。

4.2. 欠点

1. 組織によっては、インデックス作成に時間がかかりすぎる可能性があります。異なる 組織規模でベンチマークを行う必要があります。
2. インデックス作成の完了を示す UI 表示がありません。 レプリカの準備が整うまでは、組織の完全一致コード検索は、 空または部分的な結果を返すのではなく、利用できない状態になります。
3. Sidekiq、Gitaly、PostgreSQL など、GitLab インスタンスに追加の負荷がかかります。 セル内の他の Sidekiq ジョブが、インデックス作成の完了に影響します。

ページのソースコードを見る - ページの編集 - please contribute.