Hologres:Tingkatkan kinerja tulis

Mode tulis

Memilih mode tulis:

• Gunakan Insert untuk pipeline hanya-tambah tanpa primary key.

• Gunakan InsertOrIgnore saat deduplikasi ditangani di hulu dan Anda menginginkan throughput tulis tertinggi pada tabel dengan primary key.

• Gunakan InsertOrReplace saat Anda memerlukan penggantian baris penuh dan pengisian NULL untuk kolom yang tidak ada dapat diterima.

• Gunakan InsertOrUpdate untuk pembaruan kolom parsial — menerima trade-off kinerja, karena mesin harus mencari baris yang ada sebelum menulis.

Periksa apakah operasi tulis menggunakan Fixed Plan

Di Konsol Hologres, periksa metrik RPS berikut:

• QE DML RPS — operasi tulis yang melewati jalur standar HQE/PQE (table locks, latensi lebih tinggi).

• FixedQE DML RPS — operasi tulis yang menggunakan Fixed Plan (row locks, konkurensi tinggi).

Untuk menemukan operasi tulis yang tidak menggunakan Fixed Plan, kueri log kueri lambat:

-- Temukan operasi INSERT, UPDATE, dan DELETE yang tidak menggunakan Fixed Plan dalam 3 jam terakhir
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
  AND command_tag IN ('INSERT', 'UPDATE', 'DELETE')
  AND ARRAY['HQE'] && engine_type
ORDER BY query_start DESC
LIMIT 500;

Skenario di mana Fixed Plan tidak digunakan

Pernyataan SQL yang memenuhi salah satu kondisi berikut akan kembali ke jalur HQE:

• Sintaksis multi-baris INSERT ON CONFLICT:

  INSERT INTO test_upsert(pk1, pk2, col1, col2)
      VALUES (1, 2, 5, 6), (2, 3, 7, 8)
  ON CONFLICT (pk1, pk2)
      DO UPDATE SET col1 = excluded.col1, col2 = excluded.col2;

• INSERT ON CONFLICT untuk pembaruan parsial di mana kolom tabel Hologres tidak sesuai dengan kolom data yang dimasukkan.

• Tabel Hologres berisi kolom bertipe SERIAL.

• Tabel Hologres memiliki properti Default yang diatur.

• UPDATE atau DELETE berdasarkan primary key (contoh: UPDATE table SET col1 = ?, col2 = ? WHERE pk1 = ? AND pk2 = ?).

• Tipe data yang tidak didukung oleh Fixed Plan.

Aktifkan Fixed Plan untuk skenario ini

Gunakan parameter GUC untuk memperluas cakupan Fixed Plan. Atur parameter ini di tingkat database:

Untuk detail lebih lanjut, lihat Percepat eksekusi SQL dengan fixed plan.

Saat operasi tulis menggunakan Fixed Plan, operasi tersebut dihitung dalam metrik FixedQE DML RPS, dan bidang engine_type dalam log kueri lambat menampilkan FixedQE.

Fixed Plan diaktifkan tetapi operasi tulis masih lambat

Jika operasi tulis sudah menggunakan Fixed Plan tetapi latensi tetap tinggi, penyebab paling umum adalah campuran operasi HQE dan FixedQE pada tabel yang sama. Operasi HQE memegang table locks, yang memblokir operasi tulis FixedQE. Untuk memeriksa:

-- Temukan operasi HQE pada tabel tertentu dalam 3 jam terakhir
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - interval '3 h'
  AND command_tag IN ('INSERT', 'UPDATE', 'DELETE')
  AND ARRAY['HQE'] && engine_type
  AND table_write = '<table_name>'
ORDER BY query_start DESC
LIMIT 500;

Tulis ulang operasi HQE sebagai pernyataan yang kompatibel dengan FixedQE. Gunakan Dapatkan wawasan kueri di HoloWeb untuk dengan cepat mengidentifikasi apakah lock HQE memblokir operasi tulis Fixed Plan.

Jika semua operasi tulis sudah merupakan operasi FixedQE dan latensi tetap tinggi, periksa penggunaan CPU. CPU yang konsisten tinggi menunjukkan bottleneck sumber daya instans — pertimbangkan untuk melakukan penskalaan horizontal.

Gunakan koneksi VPC

Gunakan koneksi Virtual Private Cloud (VPC) alih-alih jaringan publik. Jaringan publik memiliki batas trafik dan latensi lebih tinggi dibandingkan VPC. Hal ini terutama berlaku saat menghubungkan aplikasi melalui Java Database Connectivity (JDBC) atau psql.

Untuk jenis jaringan yang didukung Hologres dan panduan memilihnya, lihat Konfigurasi jaringan.

Hindari mengaktifkan Binlog pada tabel berorientasi kolom

Binlog mencatat setiap INSERT, UPDATE, dan DELETE pada level baris penuh. Untuk tabel berorientasi kolom, pencatatan perubahan baris penuh memerlukan kueri titik untuk membaca seluruh baris — yang lebih intensif sumber daya dibandingkan tabel berorientasi baris. Jika Binlog diperlukan, gunakan tabel berorientasi baris.

Hindari operasi tulis real-time dan batch konkuren pada tabel yang sama

Operasi tulis batch (misalnya, MaxCompute ke Hologres) menggunakan table locks. Operasi tulis aliran (misalnya, Flink atau DataWorks Data Integration) biasanya menggunakan row locks melalui Fixed Plan. Saat keduanya dijalankan secara konkuren pada tabel yang sama, table lock dari operasi batch memblokir semua operasi tulis real-time hingga dilepaskan. Pisahkan workload ini: jalankan operasi batch pada jendela pemeliharaan, atau tulis ke tabel berbeda.

Gunakan INSERT OVERWRITE untuk mengganti data partisi

Saat Anda perlu mengganti atau menghapus semua data dalam suatu partisi, gunakan INSERT OVERWRITE alih-alih DELETE diikuti INSERT.

INSERT OVERWRITE adalah operasi tingkat metadata yang mengganti data partisi dengan menukar pointer file. Operasi ini dieksekusi dengan cepat dan tidak memicu logika dynamic pruning. Sebaliknya, pernyataan DELETE mengharuskan mesin memindai semua file data dalam partisi untuk menemukan dan menghapus baris, menyebabkan overhead I/O dan CPU yang signifikan. Kinerja tulis dengan DELETE + INSERT jauh lebih rendah dibandingkan dengan INSERT OVERWRITE.

Saat Anda menggunakan tugas penjadwalan untuk menulis ke tabel partisi, gunakan parameter penjadwalan untuk menentukan partisi target secara langsung dalam pernyataan INSERT OVERWRITE. Hindari menggunakan subkueri untuk menentukan data mana yang harus dihapus dan dimasukkan kembali.

-- Direkomendasikan: gunakan INSERT OVERWRITE dengan parameter penjadwalan
INSERT OVERWRITE hologres_table PARTITION(ds='${bizdate}')
SELECT col1, col2, col3
FROM source_table
WHERE ds = '${bizdate}';

-- Tidak direkomendasikan: DELETE + INSERT
DELETE FROM hologres_table WHERE ds = '${bizdate}';
INSERT INTO hologres_table
SELECT col1, col2, col3
FROM source_table
WHERE ds = '${bizdate}';

Tulis dalam batch

Operasi tulis batch memberikan throughput jauh lebih tinggi dibandingkan tulis satu catatan.

• Holo Client secara otomatis membuat batch data. Gunakan konfigurasi default.

• JDBC — tambahkan reWriteBatchedInserts=true ke string koneksi:

  jdbc:postgresql://{ENDPOINT}:{PORT}/{DBNAME}?ApplicationName={APPLICATION_NAME}&reWriteBatchedInserts=true

Contoh berikut menunjukkan cara kerja batching:

-- Dua insert terpisah (throughput rendah)
INSERT INTO data_t VALUES (1, 2, 3);
INSERT INTO data_t VALUES (2, 3, 4);

-- Insert batch (throughput lebih tinggi)
INSERT INTO data_t VALUES (1, 2, 3), (4, 5, 6);

-- Alternatifnya, menggunakan unnest
INSERT INTO data_t
SELECT unnest(ARRAY[1, 4]::int[]), unnest(ARRAY[2, 5]::int[]), unnest(ARRAY[3, 6]::int[]);

Untuk detail lebih lanjut, lihat Holo Client dan JDBC.

Gunakan mode Prepared Statement

Hologres mendukung protokol extended PostgreSQL dan mode Prepared Statement. Ini menyimpan cache hasil kompilasi SQL di server, menghilangkan overhead parsing berulang dari frontend (FE) dan QO pada setiap operasi tulis — terutama bermanfaat untuk operasi tulis frekuensi tinggi.

Untuk cara mengaktifkan mode Prepared Statement dengan JDBC dan Holo Client, lihat JDBC.

Persyaratan tipe tabel

Tabel sumber Binlog:

• Flink mendukung kumpulan terbatas tipe data saat mengonsumsi Binlog Hologres. Jika tipe yang tidak didukung (seperti SMALLINT) ada dalam skema, pekerjaan mungkin gagal meskipun Anda tidak mengonsumsi bidang tersebut. Di Ververica Runtime (VVR) 6.0.3 dan versi lebih baru, gunakan mode JDBC untuk konsumsi Binlog — mode ini mendukung lebih banyak tipe data.

• Gunakan tabel berorientasi baris untuk sumber yang mengaktifkan Binlog. Mengaktifkan Binlog pada tabel berorientasi kolom mengonsumsi lebih banyak sumber daya dan mengurangi kinerja tulis.

Tabel dimensi:

• Gunakan tabel berorientasi baris atau hybrid baris-kolom. Tabel berorientasi kolom memiliki overhead tinggi dalam skenario kueri titik.

• Tetapkan primary key. Konfigurasikan primary key sebagai clustering key untuk kinerja lebih baik.

• Primary key tabel dimensi harus persis sesuai dengan bidang yang digunakan dalam klausa JOIN ON Flink — keduanya harus identik.

Tabel tujuan:

• Untuk penggabungan tabel lebar atau pembaruan parsial, tabel Hologres harus memiliki primary key. Setiap tabel sink harus mendeklarasikan dan menulis ke bidang primary key, menggunakan mode tulis InsertOrUpdate, dan mengatur ignoredelete = true untuk mencegah pesan retraction menghasilkan permintaan DELETE.

• Untuk tabel berorientasi kolom dalam skenario penggabungan tabel lebar, nonaktifkan Dictionary Encoding untuk bidang tabel guna mengurangi penggunaan CPU pada catatan per detik (RPS) tinggi.

• Tetapkan segment_key pada tabel yang memiliki primary key. Gunakan bidang timestamp atau tanggal yang memiliki korelasi kuat dengan waktu tulis — ini membantu mesin dengan cepat menemukan file data target selama operasi tulis dan pembaruan.

Konfigurasi konektor Flink yang direkomendasikan

Nilai default opsi konektor Hologres cocok untuk sebagian besar skenario. Sesuaikan saat Anda menghadapi masalah berikut:

Latensi tinggi dalam konsumsi Binlog:

Ukuran baca batch default (binlogBatchReadSize) adalah 100 baris. Jika ukuran baris individual kecil, tingkatkan nilai ini untuk mengurangi latensi konsumsi.

Kinerja kueri titik tabel dimensi buruk:

• Atur async = true untuk mengaktifkan mode asinkron, yang memproses beberapa permintaan secara konkuren dan menghilangkan blocking antar permintaan berurutan. Perhatikan bahwa mode asinkron tidak menjamin urutan permintaan yang ketat.

• Untuk tabel dimensi besar yang jarang diperbarui, aktifkan cache LRU: atur cache = 'LRU'. Ukuran cache default cacheSize adalah 10.000 baris (konservatif) — tingkatkan berdasarkan ukuran tabel aktual dan pola akses.

Kehabisan koneksi dengan banyak Flink Jobs:

Gunakan parameter connectionPoolName. Tabel dengan nama pool koneksi yang sama dalam TaskManager yang sama berbagi koneksi.

Preferensi pengembangan pekerjaan

Lebih utamakan Flink SQL daripada DataStream demi kemudahan pemeliharaan dan portabilitas:

Flink SQL > Flink DataStream (konektor) > Flink DataStream (holo-client) > Flink DataStream (JDBC)

Untuk pekerjaan DataStream, gunakan konektor Hologres DataStream atau Holo Client alih-alih JDBC mentah.

Diagnosis operasi tulis Flink lambat

Operasi tulis lambat di Flink dapat disebabkan oleh bottleneck di tahap awal pekerjaan, bukan di sink Hologres. Periksa tekanan balik (backpressure) node. Jika backpressure muncul di node sumber atau komputasi, data yang tiba di sink Hologres sudah lambat — optimalkan langkah Flink hulu terlebih dahulu.

Jika penggunaan CPU Hologres konsisten mendekati 100% dan latensi tulis tinggi, bottleneck berada di sisi Hologres.

Untuk error Flink umum dan solusinya, lihat FAQ dan diagnostik Blink serta Flink.

Pengaturan koneksi dan konkurensi

Dalam mode wizard, setiap thread konkuren menggunakan tiga koneksi. Dalam mode editor kode, konfigurasikan:

• maxConnectionCount — total koneksi untuk tugas.

• insertThreadCount — koneksi per thread konkuren.

Dalam sebagian besar kasus, pengaturan konkurensi dan koneksi default memberikan kinerja baik. Sesuaikan hanya saat Anda mengamati konflik sumber daya.

Ukuran kelompok sumber daya eksklusif

Sebagian besar pekerjaan Data Integration memerlukan kelompok sumber daya eksklusif. Spesifikasi kelompok sumber daya menetapkan batas kinerja maksimum untuk tugas. Untuk throughput optimal, alokasikan satu thread konkuren per core CPU dalam kelompok sumber daya.

Jika kelompok sumber daya terlalu kecil relatif terhadap konkurensi tugas, Anda mungkin melihat error memori JVM. Jika bandwidth kelompok sumber daya jenuh, pecah tugas menjadi tugas-tugas lebih kecil dan distribusikan ke beberapa kelompok sumber daya. Untuk spesifikasi dan metrik kelompok sumber daya, lihat Metrik kinerja.

Diagnosis apakah bottleneck berada di hulu atau Hologres

• Jika waktu tunggu sisi baca lebih lama daripada waktu tunggu sisi tulis, bottleneck berada di sumber data hulu.

• Jika penggunaan CPU Hologres konsisten tinggi dan latensi tulis meningkat, bottleneck berada di sisi Hologres.

Operasi tulis DataX lambat dengan penggunaan CPU tinggi

Jika operasi tulis DataX lambat dan pemantauan instans Hologres menunjukkan bahwa penggunaan CPU tetap tinggi (misalnya, beberapa node pekerja mencapai 100%), saturasi sumber daya CPU menyebabkan permintaan tulis masuk mengantre atau mengalami penundaan pemrosesan.

Untuk mengatasi masalah ini:

1. Periksa apakah operasi tulis menggunakan Fixed Plan. Di Konsol Hologres, periksa metrik RPS. Jika operasi tulis muncul di QE DML RPS (jalur HQE) alih-alih FixedQE DML RPS, berarti operasi tersebut tidak menggunakan Fixed Plan. Konfigurasikan parameter GUC atau tulis ulang pernyataan SQL untuk mengaktifkan Fixed Plan. Untuk detailnya, lihat bagian Aktifkan Fixed Plan dalam topik ini.

2. Jika Fixed Plan sudah diaktifkan tetapi penggunaan CPU tetap konsisten tinggi, instans telah mencapai kapasitas sumber dayanya. Lakukan penskalaan instans Hologres untuk menambahkan lebih banyak sumber daya komputasi.

Kesenjangan data

Saat data tidak merata atau kunci distribusi diatur tidak tepat, sumber daya komputasi dalam instans Hologres menjadi tidak seimbang — beberapa shard melakukan jauh lebih banyak pekerjaan daripada yang lain. Untuk memeriksa kesenjangan data dan mengatasinya, lihat Deteksi dan tangani ketimpangan beban kerja.

Kunci segmen tidak tepat

Kunci segmen mengontrol cara Hologres mempartisi data ke dalam file penyimpanan dasar. Selama operasi tulis dan pembaruan, Hologres menggunakan kunci segmen untuk menemukan baris yang ada. Jika kunci segmen tidak ada, diatur ke bidang yang tidak relevan, atau data dalam bidang kunci segmen tidak berkorelasi dengan waktu tulis (misalnya, datang tidak berurutan), setiap operasi tulis harus memindai banyak file — mengonsumsi I/O dan CPU berat meskipun workload didominasi operasi tulis.

Gejala: metrik throughput IO di konsol menunjukkan nilai baca tinggi selama workload yang didominasi operasi tulis.

Perbaikan: Gunakan bidang timestamp atau tanggal sebagai kunci segmen. Data dalam bidang ini harus memiliki korelasi kuat dengan waktu tulis — nilai yang datang kira-kira berurutan menghasilkan kinerja terbaik.

Kunci pengelompokan tidak tepat pada tabel berorientasi baris

Untuk tabel berorientasi baris dengan primary key, Hologres menggunakan indeks primary key dan indeks clustering key untuk mencari baris yang ada selama operasi tulis atau pembaruan. Jika clustering key berbeda dari primary key, setiap operasi tulis melakukan dua pencarian indeks alih-alih satu, meningkatkan latensi.

Jaga agar clustering key dan primary key identik pada tabel berorientasi baris.

Pada tabel berorientasi kolom, clustering key memengaruhi kinerja kueri, bukan kinerja tulis. Tidak perlu perubahan untuk optimasi tulis.