2

現在、主キーとしてタイプ 4 UUID (ランダム) を持つテーブルがあります。私たちのアプリケーション層は、DB へのバッチ挿入を行います。ただし、主キーはランダムであるため、複数のディスク スピンが発生します。4つのテーブルがあります。

CREATE TABLE process (
     process_id binary(16) not null, // uuid
     created_time bigint not null,
     owner varchar(150) not null,
     primary key (process_id),
     index idx_c_t (created_time),
     index idx_o (owner)
)
Records inserted = 2000/min

CREATE TABLE process_job (
     job_id binary(16) not null, //uuid
     process_id binary(16) not null,  //uuid
     info varchar(200),
     text varchar(500),
     primary key(job_id),
     index idx_p_id (process_id)
)
Records inserted = 10000/min

CREATE TABLE ob_status (
     job_id binary(16) not null, //uuid
     status ('STARTED', 'SUCCESS', 'ERROR') not null,
     job_code varchar(100) not null,
     info varchar(200),
     text varchar(500),
     primary key(job_id, status, job_code)
)
Records inserted = 20000/min


CREATE TABLE process_job_custom (
     job_id binary(16) not null, //uuid
     key varchar(100) not null,
     value varchar(500),
     primary key(process_id, key)
)
Records inserted = 10000/min

すべてのテーブルは DYNAMIC 形式を使用しています。

さらに、15 日前のデータを定期的に削除します。約 1000 レコードを考慮して、この削除をバッチで実行します。しかし、削除が実行されるたびに、データベース全体のパフォーマンスが低下します。ディスクの使用率が非常に高い (これは主キーのランダム性が原因であると考えられます)。

そのため、主キーを (時間ベースのキー、uuid) に変更し、(uuid) 列にインデックスを追加することを計画しています。

レコードはランダムな順序で到着する場合があります (正確に時間ベースのキーの順序ではありません)。しかし、時間ベースのキーのレコードは、ほとんど 5 分の間隔で到着します。また、削除は時間ベースのキーに基づいています。

これは挿入のパフォーマンスに影響しますか?

また、私たちの主なユースケースには、時間ベースのクエリが含まれます。それでセレクト性能も上がるの？

さらに、時間ベースのキーによるパーティション分割を計画しています。

これにより、全体的なパフォーマンスが向上しますか?

主な問題は、主キーのランダム性にあると思われます。

すべてのテーブルの主キーの最初の部分として時間ベースのキー (プロセスの作成時間のようなもの) を追加し、uuid 列に基づいてインデックスを作成すると役立ちますか?

4

0 に答える 0