Bulk CUD Operation #

Dalam sistem berskala menengah hingga besar, operasi Create, Update, Delete (CUD) jarang dilakukan satu per satu. Lebih sering, aplikasi harus memproses ratusan hingga jutaan data sekaligus — misalnya saat import Excel, sinkronisasi data eksternal, atau batch processing.

Di sinilah konsep Bulk CUD Operation muncul. Namun, meskipun terlihat sederhana, implementasi bulk CUD yang keliru dapat menghancurkan performa database, menyebabkan lock berkepanjangan, lonjakan I/O, bahkan downtime.

Artikel ini akan membahas:

• Apa itu Bulk CUD Operation
• Kenapa Bulk CUD sangat mempengaruhi performa database
• Dampaknya terhadap query planner, index, dan locking
• Best practice untuk mengoptimalkan Bulk CUD

Apa Itu Bulk CUD Operation? #

Bulk CUD Operation adalah proses melakukan operasi insert, update, atau delete terhadap banyak row dalam satu konteks eksekusi.

Contoh kasus umum:

• Import data Excel (10.000 row)
• Sinkronisasi data dari service eksternal
• Batch update status order
• Pembersihan data lama (cleanup job)

Contoh non-bulk (buruk):

INSERT INTO users (id, name) VALUES (1, 'A');
INSERT INTO users (id, name) VALUES (2, 'B');
-- diulang ribuan kali

Contoh bulk:

INSERT INTO users (id, name) VALUES
(1, 'A'),
(2, 'B'),
(3, 'C');

Atau:

UPDATE orders SET status = 'DONE'
WHERE id IN (1,2,3,4,5);

Kenapa Bulk CUD Sangat Mempengaruhi Database? #

Bulk CUD bukan sekadar “lebih banyak data” — ia mempengaruhi banyak komponen internal database secara bersamaan.

Write Amplification #

Setiap operasi CUD tidak hanya menulis ke table:

• Data page
• Index page (bisa banyak index)
• WAL / Redo Log
• MVCC version (Postgres)

Jika dilakukan satu per satu:

• Overhead commit
• Flush log berulang

Bulk CUD → amortisasi cost write.

Index Maintenance Cost #

Setiap row yang diubah:

• Semua index terkait harus di-update

Masalah muncul ketika:

• Terlalu banyak index
• Index tidak relevan untuk workload write

Contoh:

UPDATE users SET last_login = now();

Jika tabel punya 7 index, maka 7 struktur B-Tree ikut berubah.

Bulk CUD memperbesar efek ini secara eksponensial.

Locking dan Concurrency #

Bulk operation cenderung:

• Mengunci banyak row
• Dalam waktu yang lebih lama

Efek samping:

• Query lain menunggu
• Deadlock
• Throughput sistem turun

Terutama berbahaya jika:

• Bulk update berjalan bersamaan dengan query OLTP

Transaction Log & Replication Lag #

Bulk CUD menghasilkan:

• Log besar
• Replication lag (read replica tertinggal)

Ini sering terlihat sebagai:

• Primary sehat
• Read replica lambat atau timeout

ampak Bulk CUD ke Query Planner #

Bulk CUD dapat menyebabkan:

• Statistik table menjadi usang
• Planner memilih execution plan yang salah

Contoh:

• Setelah delete besar-besaran
• Table menyusut tapi statistik belum update

Akibatnya:

Query kecil → Full Table Scan

Solusi biasanya:

ANALYZE;
VACUUM;

Best Practice Bulk CUD Operation #

Gunakan Batch Size yang Masuk Akal #

❌ Jangan:

• 1 transaksi = 1 juta row

✅ Lakukan:

• Chunking / batching

Contoh:

• 1.000 – 10.000 row per batch

Keuntungan:

• Lock lebih singkat
• Lebih ramah concurrency

Minimize Index Saat Bulk Write #

Untuk operasi masif:

• Drop index non-kritis sementara
• Rebuild setelah selesai

⚠️ Hanya untuk:

• Proses offline
• Maintenance window

Gunakan INSERT … SELECT atau COPY #

Lebih efisien daripada loop aplikasi:

INSERT INTO archive_orders
SELECT * FROM orders WHERE created_at < now() - interval '1 year';

Atau (Postgres):

COPY table FROM STDIN;

Hindari Update Kolom yang Tidak Perlu #

Setiap update:

• Membuat row version baru
• Mengupdate index

❌ Jangan:

UPDATE users SET name = name;

✅ Update hanya kolom yang berubah.

Gunakan Idempotent Bulk CUD #

Untuk retry-safe:

INSERT INTO users (id, email)
VALUES (1, '[email protected]')
ON CONFLICT (id) DO NOTHING;

Penting untuk:

• Worker async
• Job retry

Jalankan Bulk CUD di Jam Sepi #

Idealnya:

• Di luar jam peak
• Dengan throttling

Bulk job ≠ OLTP workload.

Monitor dan Observability #

Pantau:

• Lock wait time
• Rows affected
• Transaction duration
• Replication lag

Bulk CUD tanpa observability = bom waktu.

Anti-Pattern yang Sering Terjadi #

❌ Loop aplikasi:

for _, row := range rows {
    db.Exec("UPDATE ...")
}

❌ Satu transaksi super besar

❌ Bulk update tanpa WHERE selektif

❌ Bulk delete tanpa archive

Kesimpulan #

Bulk CUD Operation adalah:

• Sangat powerful
• Sangat berbahaya jika salah desain

Intinya:

• Bulk CUD bukan soal SQL syntax
• Tapi soal database internals, concurrency, dan workload separation

Jika dilakukan dengan benar:

• Throughput naik
• Cost turun
• Sistem lebih stabil

Jika salah:

• Lock panjang
• Query lambat
• Insiden produksi

Bulk CUD adalah pisau tajam — efisien di tangan yang tepat, mematikan jika asal pakai.