公共開始番号MXPlayer技術チーム、注目を歓迎します。
Faissプロフィール
Faissは、オープンソースのクラスタリングと密ベクトルのための効率的な類似検索を提供するためのオープンソースのライブラリの類似検索のためのFacebookのAIチームである、ベクトル検索10億レベルをサポートし、近似近傍検索ライブラリーの最も成熟の一つです。L2、ベクトル積等は、を参照して詳細に説明することができるような距離を提供Faiss様々なインデックス・タイプインデックスをFaiss、我々は索引クラスタリングベクトルセットの異なるタイプのために適切なサイズを選択することができます。
MXの紹介サービスでは、現在では主にFaissを通じてリコール類似性とスコアリングを行います。我々の異なる埋め込みアルゴリズムの出力データ項目とユーザがインデックスFaissにロードされ、アルゴリズムは、そのようなようにアイテムベース/ユーザベースとして、実現することができます。これと同時に、ビジネスシナリオに従ってソートFaissスコアリングを使用して、対応する結果を、必要とされるかもしれません。
サービス選択
最初は、FaissサーバのMXは、フラスコServerのWebでのオープンソース開発フレームワークに基づいています（Faiss-Webサービス）の改善は、オンラインでの実験、およびなし詳細設計と最適化、そのパフォーマンスを行うためには、できるだけ早くライン上に来ます非常に良いではない、おそらく平均応答時間は約6msで、他の貧しい人々スケーラビリティ、追加またはインデックスを削除する多くの方法で制限することにより、フレームです。完全な調査と技術選択した後、最終的な決定は、RPCフレームワークを使用して再構築されます。
現在、オープンソースのRPCフレームワークの多くは、Java言語の開発に起因するMX紹介サービスは、そのようrpcxなどスリフト、ダボ、gRPC、と、ありますが、Faissは現在、唯一、考慮に多言語サポートのニーズを取って、C ++とPythonの両方の言語をサポートしていますgRPCとスリフトは、要件を満たしています。（基準調査見出さ「RPC人気のあるフレームワークベンチマーク」）、ビジネス・プロセス・レベル10msのは、スループット及び遅延の点で、GRPCより倹約は、特定の利点を有している場合、それらはGRPCフレームを選択しました。
要件分析
図1に示すように、多型ベクター負荷
命名S3に格納された出力タイムスタンプ（バージョン番号）の異なるアルゴリズムアルゴリズムタイプ+ +アイテム名にベクトル出力は、例えば、キーS3はdeepwalk /映画/ index.20190821_043002_64ファイルで出力アルゴリズムdeepwalkあります映画の種類のベクトルアイテム。Faissサーバは、要求タイプおよびアイテムタイプに応じて、対応するアルゴリズムからベクター構築インデックスの様々なタイプ、および類似検索索引をロードできるようにする必要があります。
図2に示すように、マルチタイプインデックス試験
Faissは、ここで効果を含め、我々はベクトル型とマッピング効果のインデックスタイプの最良のセットを見つけるためにこのように、ベクトルの同じタイプは、小さな流れ試験のために使用されているインデックスの異なるタイプにロードされている使用することができ、インデックスの種類を豊富に提供してインデックスの推薦結果、Faissサーバのメモリ使用量、CPU使用率と応答時間。
3、簡単に設定できインデックス
裁判が進むにつれて、各指標のオンラインパフォーマンスは同じではありませんので、インデックスが新しい出力ベクトルアルゴリズムの下にいくつかの秋もFaissサーバは柔軟にインデックスを設定することができる必要があるので、タイムトライアルに行われる必要があることが必要です。
図4に示すように、インデックスバージョン管理
また、ベクトルのユーザーの同じ出力項目の出力、ユーザー推薦システムは、同じベクトル空間の下の項目ベクトルをリコールするために使用することができますが、ナキウサギにおけるユーザーベクトル記憶は、アイテムベクトルに後れを取るだろう出力は、があるかもしれませんいくつかの理由を書いているので推薦システムにつながるユーザーベクトルの問題は、古いベクトルから取り出され、そしてFaissサーバは新しいインデックスで更新されているので、Faissサーバーは、上のベクトルの同じタイプの複数のバージョン、当該勧告システムをロードできるようにする必要がありますあなたは、指定されたバージョンで同じベクトル空間とユーザーベクトル隣人のアイテムを取得することができます。
5、不快指数の更新
ベクトルの異なるアルゴリズムの出力は時折、毎日更新される、Faissサーバの負荷がベクトルに加え、最新のサービスの開始時にインデックスを構築するだけでなく、最新のベクトルインデックスとタイムリーなアップデートの必要はなく、適切に要求に応答することができます。
設計と実装
1. Faissサーバー
1.1組織構造
絵は、図Faissサーバーの組織構造を示しています。1,2,4のニーズを満たすために、我々は中FaissHandlerにカプセル化されたインデックスをFaissます。FaissHandlerは5つのフィールド、algorithm_type、カテゴリとユニークINDEX_TYPEインデックスが割り当てられ、これは、簡単にマルチベクトル型と複数のインデックス・タイプをサポートすることができ、かつ実際のFaissインデックスを保存index_dict、ベクトル（インデックス）バージョンキー、Faissが含まれています容易にあなたが検索のベクトルのバージョンを指定していない時に最新バージョンをindex_dict保存するlatest_version分野に加えて、最近傍検索サービスの特定のバージョンをサポートすることができ、インデックス値は、インデックスの最新バージョンを使用します検索。
私たちは、FaissHandlerを使用するには、現在のニーズにHandlerCollectionを設定することができ、インデックスの更新は、インデックスを更新するために、1、コレクション1を通過することができます。唯一の1行のコードは非常に便利なことができ変更する必要があり、3のニーズを満たすための追加、変更、または削除することもあります。そしてgRPCは組立用のサービスパラメータを要求する必要があり、その後、ハンドラの操作で、残りが終了したライン上の対応するハンドラにルーティングされます。
1.2インターフェイスデザイン
Faissサーバは、最近傍検索項目RPCインターフェイスを検索する必要があり、検索要求のインタフェースは、以下の通りである指標、またはターゲットアイテムIDのベクトルと特定の使用を示す、要求の本体のメインフィールドが必要です。
message SearcRequest {
string algorithmType = 1;
string category = 2;
int32 num = 3;
string indexType = 4;
repeated string itemId = 5;
repeated FloatArray vector = 6;
}复制代码SearchRequest最初の4つのフィールドは4依存のフィールドは、ハンドラを見つけることがあるため必要であり、品目ID及び少なくとも一つのベクトルが存在している必要があります。itemIdおよびベクターは、マルチアイテム、マルチベクトル探索をサポートするために、変更して繰り返されます。
message SearchResponse {
message Str2FloatMap {
map<string, float> innerMap = 1;
}
map<string, Str2FloatMap> similarItems = 1;
} 复制代码応答は、最近傍の画分と比較して、唯一のマップ、キー対象項目またはベクター（SearchRequestで）、値その結果、非常にシンプルです。
1.3検索処理
2.インデックス更新
画像は、図のインデックス更新のアーキテクチャを示し、セロリは2分を作成するために、すべてのインデックス更新タスクはすべてHandlerCollectionハンドラ対応するインデックスは、対応するベクトルAWS S3からファイルをダウンロードするために労働者のタスクを受け取った後、荷重ベクトルを更新している必要がビートインデックス作成、インデックスは、ファイルにシリアライズ、インデックスファイル索引更新通知に直接荷重を受けるように通知（コール）GRPCセロリインターフェースを提供Faissサーバ。建物の操作は非常に時間がかかるダウンロードするとセロリの完了と呼ばインデックスベクトルは、効率的に実行している安定したサーバーを確保するため、サーバーのリソースを節約することができます。インデックスの更新処理の詳細を以下に示します。
この図は、詳細な更新プロセスを伝えますが、流暢さと読みやす処理するために詳細を隠します。操作は、我々は多くのインデックスを持っているので、ハンドラーコレクションを横断しながら、インデックスは、サービスを提供するために、できるだけ早く更新され、すべての方法ダウンシングルスレッドではありません更新し、各ハンドラのためのセロリのタスクのチェックのバージョンを作成し、その後、セロリの労働者が同時に移動しますあなたが本当に更新する必要がある場合は、同じタスクを同時実行のダウンロードベクトルを作成することが、問題があると、各タスクのために、これらのタスクを実行し、タスクセロリは、インデックスが2分ごとに更新されたビートを作成することですが、ダウンロードは非常にベクトルであります時間のかかる操作の最後の更新は、ダウンロードベクトル実行にまだある、とこれは、このように同じベクトルのダウンロードに同時複数のワーカーを引き起こし、このステップのダウンロードベクトルに来ている場合は、ベクトルファイルは、大きくなる可能性があるため、これは唯一の廃棄物ワーカー資源につながるだけでなく、ネットワークIOの浪費につながるので、あなたが実際にベクトルをダウンロードする前に、最初のダウンロードベクトルタスクを実行している作業員を示す、あなたがロックを取得できない場合は、特定のベクターのためにロックを取得しようとします現在の労働者は直接、終了を返します 追加のタスクを受け取るのを待っているタスク、。ベクトルをダウンロードした後、負荷インデックスと通知サーバのアップデートによって複雑になります。
配備します
Python言語の開発とFaissサーバ、グローバルインタプリタロック付きパイソンが効果的にマルチコアCPUを使用することはできませんので、私たちは、展開のための単一のマルチモードサービスのインスタンスを使用しているため。
オンラインプレゼンス
完全にライン上の圧力の前にテストされている、結果は以前よりも2倍よりも高い単一QPSは、応答時間が約67％減少していることを示しています。newrelicの応答時間以下のライン上の新しいサービスの前と後の比較：
概要
FaissサーバはgRPCに効果的ように元のサービスに存在する様々な問題、高効率、高拡張性とを解決するために、高度にカスタマイズされたビジネス・サービスの需要をベースにしています。