Belajar Database Administrator - AI Database & Vector DB

#Pendahuluan

Setelah episode 23 mengelola biaya, episode ini menghadapi era baru: aplikasi AI (chatbot, semantic search, rekomendasi) tidak mencari dengan kata kunci persis, melainkan dengan makna. Pertanyaan "produk apa yang cocok untuk hiking" mungkin tidak mengandung kata "hiking" di deskripsi produk — tapi database harus bisa menemukannya.

Jawabannya adalah vector database: data direpresentasikan sebagai vektor numerik (embedding) sehingga kemiripan makna menjadi kemiripan jarak. Episode ini membangun fondasi vector search di PostgreSQL dengan pgvector, memetakan pipeline RAG, dan membahas kapan managed vector DB diperlukan.

#Embedding: Mengubah Makna Menjadi Angka

Embedding adalah fungsi yang mengubah teks/gambar/audio menjadi deret angka (misal 1536 dimensi). Dua teks yang bermakna mirip menghasilkan vektor yang berdekatan secara matematis. Model seperti OpenAI text-embedding-3-small, Cohere, atau open-source seperti BGE menghasilkan embedding ini.

Kemiripan diukur dengan cosine similarity (kesamaan arah/sudut antar vektor) atau Euclidean distance (jarak). Semakin kecil jarak, semakin mirip. Di sinilah semantic search bekerja: pencarian dilakukan pada representasi makna, bukan pada karakter teks.

#pgvector: Vector Langsung di PostgreSQL

pgvector adalah extension PostgreSQL yang menambah tipe data vector dan operasi similarity search. Keunggulannya: data vektor hidup berdampingan dengan data relasional biasa — tidak perlu sistem terpisah, transactional, dan memakai backup, monitoring, serta access control yang sudah ada.

CREATE EXTENSION IF NOT EXISTS vector;
 
CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    content text,
    embedding vector(1536)
);

Untuk pencarian, siapkan index HNSW — graf hierarkis yang mempercepat pencarian tetangga terdekat tanpa men-scan semua baris:

CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops);

Query pencarian semantic:

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;

Operator <=> adalah cosine distance. Kombinasi dengan filter metadata (misal WHERE tenant_id = 5) memungkinkan search yang di-scope per pengguna — sesuatu yang sulit di managed vector DB murni.

#Pipeline RAG: Database untuk LLM

RAG (Retrieval-Augmented Generation) adalah pola dominan aplikasi AI: alih-alih melatih model, kita memberi model konteks yang relevan yang diambil dari database saat itu juga.

Alurnya: dokumen dipecah menjadi chunk, tiap chunk di-embed dan disimpan; saat ada pertanyaan, pertanyaan di-embed juga, dicari top-k chunk paling mirip, lalu chunk tersebut disisipkan ke prompt sebagai konteks. Jawaban model jadi akurat dan bisa mencantumkan sumber.

Sebagai DBA, tugas kalian bukan menulis model, tapi memastikan pipeline ini operasional: embedding pipeline yang idempotent dan bisa di-resume, kapasitas storage embedding (tiap chunk + 1536 float memakan ribuan byte), backup yang konsisten, dan observability latensi retrieval.

#Managed Vector DB: Pinecone dan Kawan-kawan

Saat volume sangat besar (ratusan juta vektor) atau kalian tidak ingin mengelola sendiri, ada managed vector DB: Pinecone, Weaviate, Qdrant, Milvus. Kelebihan: skala otomatis, index yang sudah matang, dan API simpel. Pertimbangan untuk DBA:

• Biaya: vektor butuh storage besar; tagihan managed vector DB bisa mengejutkan — hitung dengan rekayasa yang tepat.
• Data duplikasi: data biasanya tinggal di PostgreSQL, salinannya (embedding) di vector DB — sinkronisasi jadi tanggung jawab baru.
• Filter metadata: filter tenant/category di managed service sering mahal atau tidak terdukung baik — evaluasi dengan workload nyata.

Aturan praktis: mulai dengan pgvector (lebih sederhana, biaya rendah, satu sistem). Pindah ke managed hanya jika pgvector terbukti tidak cukup dari segi skala atau performa.

#AI untuk Tuning Query

Sisi menarik lainnya: AI membantu DBA itu sendiri. Tool modern menyediakan:

• AI index advisor: menganalisis workload dan menyarankan index (pganalyze/Percona Advisor dengan tambahan model).
• Natural language to SQL / query plan explainer: menjelaskan EXPLAIN dalam bahasa manusia.
• Anomaly detection: mendeteksi regresi performa sebelum user melaporkan (menggabungkan episode 7 dengan model).

Posisi DBA: AI adalah asisten, bukan pengganti. Kalian tetap harus memvalidasi saran dengan prinsip episode 6 dan 21 — AI yang menyarankan index salah justru menambah beban. Gunakan AI untuk mempercepat analisis, bukan untuk memutuskan tanpa verifikasi.

#Pitfall Produksi

1. Chunking yang sembarangan: chunk terlalu panjang membuat retrieval tidak relevan; terlalu pendek membuat konteks terpecah. Ini keputusan pipeline yang berdampak besar pada kualitas.
2. Index HNSW tanpa pengujian parameter: nilai m dan ef_construction memengaruhi kualitas vs ukuran — uji dengan data nyata.
3. Mengganti model embedding tanpa perencanaan: mengganti model mengubah makna semua vektor — seluruh dataset harus di-embed ulang.
4. Memperlakukan vektor sebagai data biasa: embedding bisa membocorkan informasi dokumen — terapkan akses dan audit seperti data lain (episode 9 dan 16).

#Penutup

Inti yang harus dibawa pulang:

• Embedding mengubah makna menjadi angka; cosine similarity mengukur kedekatan.
• pgvector memberi vector search di PostgreSQL dengan index HNSW — mulai dari sini.
• Pipeline RAG: chunk → embed → simpan → retrieve top-k → konteks untuk LLM.
• Managed vector DB (Pinecone dkk.) untuk skala besar, dengan biaya dan sinkronisasi yang harus diperhitungkan.
• AI membantu tuning query, tapi keputusan akhir tetap di tangan kalian.

Di episode 25 selanjutnya kita menggeser fokus dari transaksi ke analitik: ops untuk data warehouse — Snowflake dan BigQuery, partition dan clustering, pengelolaan metadata, hingga administrasi warehouse skala kecil. Sampai jumpa di episode 25!