すべてのプロダクト
Search
ドキュメントセンター

MaxCompute:Centauriのデータ性能

最終更新日:Jan 07, 2025

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に固有のフェーズであり、インデックス付けアルゴリズムのパラメータの値を計算するために使用されます。 ビルドはインデックス作成フェーズです。 シークは検索フェーズです。

テストの実行手順

  • ビルド段階でのパフォーマンス比較

    • ケンタウリ Centauri

    • プロキシマCEHash sharding of Proxima CEのハッシュシャーディング

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

  • シークフェーズでのパフォーマンス比較

    • ケンタウリ Centauri

    • プロキシマCEHash sharding of Proxima 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.