Menjawab Buntut Log AI yang Meningkat

Dev.to baru-baru ini membagikan cerita tentang AI detector yang sering keliru, sehingga tim audit manual harus menelusuri log untuk setiap flag yang tampil. Akibatnya, jumlah query audit meningkat tajam dan log database membengkak, memicu kemacetan di lapisan SQL. Artikel ini langsung menjawab: bagaimana mengidentifikasi dan memperbaiki query yang lambat akibat log yang membesar, serta bagaimana menjaga pagination agar tidak menambah beban tambahan.

Fokus utama adalah: (1) mengenali query bermasalah lewat metrik dan EXPLAIN, (2) memprioritaskan indeks dan cardinality sebelum menambahkan fitur, serta (3) merancang pagination yang hemat resource di tengah data terus tumbuh.

1. Identifikasi Query Lambat dari Log Audit

Mulai dari log AI, kenali pola query yang paling sering dipanggil. Biasanya, query audit memiliki tanda: filter berdasarkan flag, join ke tabel user, dan warn log yang panjang. Penggunaan slow query log atau performance schema/pg_stat_statements membantu mengisolasi kandidat.

Langkah nyata:

  1. Aktifkan slow log (MySQL: long_query_time, PostgreSQL: log_min_duration_statement) sesuai toleransi SLA.
  2. Ambil top query dengan frekuensi tinggi dari pg_stat_statements atau slow_log.
  3. Catat metrik: avg_time, rows, calls, dan apakah ada seq scan yang berulang.

Contoh perintah untuk PostgreSQL:

SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
WHERE query LIKE '%flag_ai%'
ORDER BY total_time DESC
LIMIT 5;

Karena flag AI memicu audit manual, cari query dengan filter sama tapi tanpa indeks yang tepat.

2. Prioritaskan Indeks dan Cardinality

Setelah query bermasalah teridentifikasi, analisa plan-nya dengan EXPLAIN (ANALYZE, BUFFERS). Cari tanda berikut:

  • Seq Scan pada tabel besar, sedangkan filter terbatas.
  • Nilai cardinality yang tinggi untuk kolom filter, tapi indeks paxible tidak dipakai.
  • Beberapa JOIN berurutan menyebabkan nested loops yang tidak terindeks.

Contoh plan yang perlu diperbaiki:

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM audit_logs a
JOIN users u ON u.id = a.user_id
WHERE a.flag_status = 'AI'
AND a.created_at > NOW() - INTERVAL '1 day';

Perhatikan apakah kolom flag_status, user_id, dan created_at sudah dibantu indeks. Prioritas indeks:

  1. Composite index untuk filter yang sering digabungkan: (flag_status, created_at).
  2. Partial index jika flag AI hanya sebagian kecil: CREATE INDEX ON audit_logs (created_at) WHERE flag_status = 'AI';.
  3. Gunakan statistik cardinality untuk memastikan indeks dipertahankan. Periksa dengan SELECT relname, n_distinct FROM pg_stats WHERE tablename = 'audit_logs';.

Forum kesalahan umum: membuat indeks pada kolom yang berisi nilai unik (misalnya id) yang tidak membantu filter, atau tidak memperbarui ANALYZE setelah data besar masuk.

3. Strategi Pagination Hemat Resource

Audit log yang tumbuh membuat pagination offset-based tidak layak, karena offset besar memaksa database melewati ribuan baris setiap request. Solusi yang lebih hemat resource:

  • Keyset pagination dengan cursor berdasarkan timestamp atau ID. Tidak perlu menghitung offset, hanya kondisi tambahan seperti WHERE (created_at, id) < (last_ts, last_id).
  • Materialized view untuk snapshot jika audit log tidak berubah setelah ditulis, bisa menyusun view yang sudah diindeks untuk pagination.
  • Batasi halaman dan gunakan load more yang memanggil pagination incremental, bukan permintaan halaman arbitrer.

Contoh query keyset:

SELECT id, flag_status, created_at
FROM audit_logs
WHERE flag_status = 'AI'
AND (created_at, id) < (TIMESTAMP '2024-10-10 12:00:00', 12345)
ORDER BY created_at DESC, id DESC
LIMIT 50;

Metode ini menjaga waktu eksekusi stabil walau log terus bertambah.

4. Metrik yang Dipantau dan Debugging

Jaga pengawasan terus menerus dengan dashboard metrik:

  • Query duration per endpoint dan rata-rata per flag.
  • Buffer hit rate dan index usage.
  • Daemon pagination—berapa banyak halaman dibuka per request.
  • Log growth (baris per jam) agar bisa memprediksi kebutuhan indeks baru.

Debugging tip: ulangi query bermasalah di lingkungan staging dengan data volumetrik, lalu bandingkan plan sebelum/ sesudah indeks. Gunakan EXPLAIN ANALYZE untuk memastikan cardinality estimasi tidak menyimpang jauh dari realitas.

5. Rencana Mitigasi Saat Data Terus Tumbuh

Kalau log terus bertambah karena flag AI populer, siapkan strategi berikut:

  • Archive data yang lebih tua ke tabel history dengan struktur serupa tapi indices berbeda agar query real-time tetap ringan.
  • Penjadwalan reindex dan VACUUM/ ANALYZE berkala agar statistik tidak usang.
  • Adaptive indexing: gunakan tool monitoring untuk mendeteksi gap index usage dan otomatis menindaklanjuti dengan rekomendasi.

Dengan rencana ini, tim bisa mengelola beban audit AI tanpa menyerah pada offset pagination dan log yang membengkak.

Kesimpulan

Log AI yang mengikuti cerita dev.to bukan hanya soal false positive, tapi juga menuntut tuning serius: identifikasi query lambat via metrik, prioritaskan indeks/cardinality, dan pilih pagination yang efisien. Dengan langkah-langkah nyata, monitoring yang tepat, dan strategi mitigasi, database tetap responsif meski audit manual meningkat.