CentauriはProxima CEの前身です。 このトピックでは、さまざまなシナリオでのCentauriのデータパフォーマンスについて説明します。
シナリオ1: 512のディメンションを持つBINARYデータ型の100万件のデータレコードを含むdocテーブルとクエリテーブルでテストします。
このテストシナリオでは、docテーブルとクエリテーブルの両方のデータレコード数は100万、データ型はBINARY、ディメンション数は512です。 50行と4列は、検索のために手動で指定されます。
テストの結論
Proxima CEのハッシュシャーディングのデータパフォーマンスは、Centauriのデータパフォーマンスよりも約20% 高くなっています。
- | K-meansフェーズの期間 (秒) | オートチューニングフェーズの期間 (秒) | ビルドフェーズの期間 (秒) | シークフェーズの期間 (秒) | 合計所要時間 (分) |
ケンタウリ | - | 1,524 | 12,653 | 5,914 | 336 |
プロキシマCEのハッシュシャーディング | - | - | 9,647 | 6,431 | 268 |
K-meansは、Proxima CEのクラスタシャーディングに固有のフェーズであり、元のdocテーブルのクラスタ重心テーブルを取得するために使用されます。 オートチューニングは、Centauriに固有のフェーズであり、インデックス付けアルゴリズムのパラメータの値を計算するために使用されます。 ビルドはインデックス作成フェーズです。 シークは検索フェーズです。
テストの実行手順
ビルド段階でのパフォーマンス比較
ケンタウリ

プロキシマCE
のハッシュシャーディング
結果分析: Centauriを使用すると、1つのノードでのインデックス作成が非常に高速に実行され、残りの3つのノードではインデックス作成にほぼ同じ時間が必要になります。 Proxima CEのハッシュシャーディングが実行される場合、2つのノードに対するインデックス構築は過度に高速で実行され、他の2つのノードに対するインデックス構築は比較的低速で実行される。
シークフェーズでのパフォーマンス比較
ケンタウリ

プロキシマCE
のハッシュシャーディング
結果分析:
Centauriのノードでのインデックス探索に必要な時間は、Proxima CEのハッシュシャーディングのためのノードでのインデックス探索に必要な時間に近い。
プロキシマCEのハッシュシャーディングのためのノードでの結果マージに必要な時間は、Centauriのノードでの結果マージに必要な時間よりも約12分長くなります。
プロキシマCEのハッシュシャーディングが実行されるとき、ノード上の最速の結果マージは8分であり、ノード上の最も遅い結果マージは20分である。
Centauriを使用する場合、ノードでの最速の結果マージは4分で、ノードでの最も遅い結果マージは9分です。
ランニングの詳細
ケンタウリ
Vector search Data type:BINARY , Vector dimension:512 , Search method:graph , Measure:hamming , Building mode:build:seek Information about the doc table Table name: doc_table_pailitao_binary , Partition:20210712 , Number of data records in the doc table:100000000 , Vector delimiter:~ Information about the query table Table name: doc_table_pailitao_binary , Partition:20210712 , Number of data records in the query table: 100000000 , Vector delimiter:~ Information about the output table Table name: output_table_pailitao_binary_centauri , Partition:20210712 Row and column information Number of rows: 50 , Number of columns:4 , Number of data records in the doc table of each column for index building:25000000 Whether to clear volume indexes:false Time required for each worker node (seconds): worker:TmpDataTableJoinWorker , times:0 worker:TmpTableWorker , times:16 worker:CleanUpWorker , times:4 worker:AutotuningFastWorker , times:46 worker:RowColWorker , times:53 worker:SeekJobWorker , times:5914 worker:BuildJobWorker , times:12653 worker:AutotuningNormalWorker , times:1478 Total time required (minutes):336 Top recall rate User setting train: top200:0.95 Top recall rate normal train: top200:98.061% Autotuning Fast Build Params: proxima.general.builder.memory_quota=0 proxima.graph.common.max_doc_cnt=27500000 proxima.general.builder.thread_count=15 proxima.hnsw.builder.efconstruction=400 proxima.graph.common.neighbor_cnt=100 Autotuning Normal Search Params: proxima.hnsw.searcher.ef=400 Sample commands: jar -resources centauri-1.1.5.jar,libcentauri-1.1.5.so -classpath /data/jiliang.ljl/centauri_1.1.5/centauri-1.1.5.jar com.alibaba.proxima.CentauriRunner -proxima_version 1.1.5 -doc_table doc_table_pailitao_binary -doc_table_partition 20210712 -query_table doc_table_pailitao_binary -query_table_partition 20210712 -output_table output_table_pailitao_binary_centauri -output_table_partition 20210712 -data_type binary -dimension 512 -app_id 201220 -pk_type int64 -clean_build_volume false -distance_method hamming -binary_to_int true -row_num 50 -column_num 4;プロキシマCEのハッシュシャーディング
Vector search Data type:1 , Vector dimension:512 , Search method:hnsw , Measure:Hamming , Building mode:build:build:seek Information about the doc table Table name: doc_table_pailitao_binary2 , Partition:20210712 , Number of data records in the doc table:100000000 , Vector delimiter:~ Information about the query table Table name: doc_table_pailitao_binary2 , Partition:20210712 , Number of data records in the query table:100000000 , Vector delimiter:~ Information about the output table Table name: output_table_pailitao_binary_ce , Partition:20210712 Row and column information Number of rows: 50 , Number of columns:4 , Number of data records in the doc table of each column for index building:25000000 Whether to clear volume indexes:false Time required for each worker node (seconds): SegmentationWorker: 2 TmpTableWorker: 1 KmeansGraphWorker: 0 BuildJobWorker: 9647 SeekJobWorker: 6431 TmpResultJoinWorker: 0 RecallWorker: 0 CleanUpWorker: 3 Total time required (minutes):268 Sample commands: jar -resources proxima_ce_g.jar -classpath /data/jiliang.ljl/project/proxima2-java/proxima-ce/target/binary/proxima-ce-0.1-SNAPSHOT-jar-with-dependencies.jar com.alibaba.proxima2.ce.ProximaCERunner -doc_table doc_table_pailitao_binary2 -doc_table_partition 20210712 -query_table doc_table_pailitao_binary2 -query_table_partition 20210712 -output_table output_table_pailitao_binary_ce -output_table_partition 20210712 -data_type binary -dimension 512 -app_id 201220 -pk_type int64 -clean_build_volume false -distance_method Hamming -binary_to_int true -row_num 50 -column_num 4;
シナリオ2: 128のディメンションを持つFLOATデータ型の10億のデータレコードを含むdocテーブルとクエリテーブルでテストします。
このテストシナリオでは、docテーブルとクエリテーブルの両方のデータレコード数は10億、データ型はFLOAT、ディメンション数は128です。 50行と60列が検索用に指定されています。
テストの結論
Proxima CEのハッシュシャーディングのデータパフォーマンスは、Centauriのデータパフォーマンスよりも約30% 高くなっています。 Centauriと比較して、Proxima CEのクラスターシャーディングは、データパフォーマンスを約2倍向上させ、クラスターシャーディングのシークフェーズでのデータパフォーマンスは約7.5倍向上します。 INT8量子化はデータ性能を約10% 改善する。
移動方法 | クラスターシャーディングまたはオートチューニング時間 (秒) | ビルドフェーズの期間 (秒) | シークフェーズの期間 (秒) |
ケンタウリ | 1,220 | 9,822 | 37,245 |
プロキシマCEのハッシュシャーディング | 非該当 | 9,841 | 23,462 |
プロキシマCEのハッシュシャーディングとINT8量子化 | 非該当 | 7,600 | 21,624 |
プロキシマCEのクラスターシャーディング | 1,247 | 14,404 | 5,028 |
テストの実行手順
ビルドフェーズの詳細
移動方法
マッパー
ビルドReducer
合計所要時間 (秒)
ケンタウリ
-
-
-
プロキシマCEのハッシュシャーディング
00:01:23.116
レイテンシ:{min:00:00:03, avg:00:00:23, max:00:01:00}
02:41:43.563
レイテンシ:{min:00:02:40、平均: 01:32:33、max:02:41:33}
9,841
プロキシマCEのハッシュシャーディングとINT8量子化
00:01:36.166
レイテンシ:{min:00:00:09, avg:00:00:25, max:00:01:09}
02:04:11.440
レイテンシ:{min:00:06:56、平均: 01:06:06、max:02:03:53}
7,600
プロキシマCEのクラスターシャーディング
00:15:33.022
レイテンシ:{min:00:00:03, avg:00:03:24, max:00:15:21}
03:43:37.529
レイテンシ:{min:00:03:57、平均: 01:33:32、max:03:43:35}
14,404
シークフェーズの詳細
移動方法
マッパー
Topnリデューサー
マージReducer
合計所要時間 (秒)
補足
ケンタウリ
00:15:45.000
34秒から11分まで
08:33:50.000
98分から489分
01:30:20.000
30分から70分まで
37,245
データ処理全体は、レデューサタスクがロギングを終了してから30〜40分後に完了します。
マッパー、topNリデューサー、およびマージリデューサータスクのシングルノードランタイムは、Logviewの別のテストから取得されます。
プロキシマCEのハッシュシャーディング
00:06:29.791
レイテンシ:{min:00:00:02, avg:00:01:39, max:00:05:56}
04:50:42.422
レイテンシ:{min:00:01:48、平均: 01:54:33、max:03:47:54}
04:50:42.422
レイテンシ:{min:00:00:35, avg:00:33:39, max:01:32:16}
23,462
マッパーおよびマージレデューサタスクで消費される合計時間は、maxタスクで消費される時間と同様です。 この結果は予想に近い。 時間消費はロングテールマシンによってのみ影響を受けます。
topNリデューサタスクで最後に停止した2つのノードのフェールオーバーが遅れて開始されます。 2つのノードが消費する時間を無視すると、合計時間から1時間短縮できます。
プロキシマCEのハッシュシャーディングとINT8量子化
00:06:25.718
レイテンシ:{min:00:00:17, avg:00:01:27, max:00:06:02}
03:58:00.566
レイテンシ:{min:00:00:25, avg:01:06:41, max:02:40:07}
01:54:35.620
レイテンシ:{min:00:01:56, avg:00:20:54, max:01:39:55}
21,624
非該当
プロキシマCEのクラスターシャーディング
00:23:51.623
レイテンシ:{min:00:00:04, avg:00:03:01, max:00:08:34}
01:00:38.382
レイテンシ:{min:00:05:15, avg:00:18:00, max:01:00:10}
00:12:39.341
レイテンシ:{min:00:00:31, avg:00:07:08, max:00:12:33}
5,028
非該当
シナリオ3: ドキュメントテーブルとクエリテーブルのクラスターシャーディングで、どちらも128のディメンションを持つFLOATデータ型の1.6億のデータレコードが含まれています。
このテストシナリオでは、docテーブルとクエリテーブルの両方のデータレコード数は1.6億、データ型はFLOAT、ディメンション数は128です。 行と列のデータは自動的に計算されます。
docテーブルとクエリテーブルの両方のデータレコードのデータ量が1.6億個になると、過度に多くなります。 プロキシマCEのクラスターシャーディングのみを正常に実行できます。 次の表に、基本的なデータ情報を示します。
移動方法 | クラスターシャーディングまたはオートチューニング時間 (秒) | ビルドフェーズの期間 (秒) | シークフェーズの期間 (秒) |
ケンタウリ | 1,127 | 19,962 | メモリ不足 (OOM) エラーのため、タスクは2回失敗しました。 |
プロキシマCEのハッシュシャーディング | 非該当 | 14,637 | 出力データ量が一時テーブルの上限値を超えたため, タスクは1回失敗しました。 |
プロキシマCEのクラスターシャーディング | 5,478 | 17,911 | 6,801. |