Belajar Vitess - Hybrid Workloads & OLAP Integration

#Pendahuluan

Vitess dioptimalkan untuk OLTP: transaksi kecil dan sering. Tapi tim bisnis tetap butuh laporan besar — dan menjalankan query analitik berat di atas database transaksional adalah resep untuk memperlambat aplikasi. Episode 17 membahas cara memadukan dua dunia: OLTP tetap gesit di Vitess, sementara beban analitik dijalankan di tempat lain tanpa saling mengganggu.

Roadmap episode 17: memisahkan OLTP dan OLAP, read replica untuk reporting, ekspor snapshot untuk ETL, lalu integrasi dengan data warehouse.

#Memisahkan OLTP dan OLAP

Prinsip pertama: jangan jalankan query analitik berat di primary. Query seperti agregasi besar atau join lintas tabel akan menguras resource yang dipakai transaksi. Pemisahan workload adalah keputusan arsitektur, bukan sekadar kebijakan.

Model pemisahan yang umum:

OLTP di Vitess: semua transaksi aplikasi, di-shard dan direplikasi.
OLAP di tempat lain: data disalin ke warehouse atau data lake, query analitik dijalankan di sana.
Reporting ringan di Vitess: laporan kecil dan sering (dashboard operasional) diarahkan ke tablet RDONLY.

Pembagian workload

Transaksi (OLTP)   : Vitess primary + replica
Dashboard ringan   : tablet RDONLY di Vitess
Analitik besar     : data warehouse terpisah

Tabel pembagian di atas menjaga beban tetap terarah. Query analitik besar tidak pernah menyentuh jalur transaksi.

#Read Replica untuk Reporting

Untuk reporting yang butuh data hampir-real-time tapi tidak ingin membebani primary, gunakan tablet RDONLY. Tablet jenis ini dilarang dipromosikan jadi primary (episode 6), sehingga aman dipakai untuk workload berat tanpa mengganggu jalur failover.

Menambah tablet rdonly

vtctlclient InitShardMaster -force commerce/0 -master_force \
  -accept_primary_read_only=true
vtctlclient TabletExternallyReparented <tablet-alias>

Untuk membuat tablet RDONLY, konfigurasi di values.yaml:

Menambah replica rdonly

topology:
  keyspaces:
    - name: commerce
      shardTablets:
        - name: rdonly
          replicas: 2
          type: rdonly

type: rdonly membuat tablet sebagai RDONLY. Arahkan koneksi reporting aplikasi ke VTGate dengan user reporting, dan pastikan VTGate memilih tablet RDONLY untuk query tersebut.

Info

Data pada tablet RDONLY bisa tertinggal beberapa detik dari primary. Untuk dashboard yang butuh data hampir-real-time, ini biasanya cukup. Untuk laporan keuangan yang harus presisi, tunggu hingga replication lag mendekati nol sebelum menjalankan query.

#Ekspor Snapshot untuk ETL

Untuk data warehouse, Vitess menyediakan jalur ekspor data yang efisien. Pola yang umum dipakai:

Snapshot berkala: ambil snapshot konsisten dari tablet RDONLY, simpan ke object storage, lalu diproses pipeline ETL.
Streaming via VReplication: salin perubahan data secara berkelanjutan ke target eksternal — pendekatan yang cocok untuk warehouse yang butuh data fresh.

Backup Vitess (episode 6) sebenarnya sudah menghasilkan snapshot konsisten — format ini bisa dipakai sumber data warehouse. Untuk streaming, VReplication ke target non-MySQL adalah fitur yang sedang berkembang dan dipakai untuk integrasi real-time.

Backup sebagai sumber snapshot ETL

vtctlclient Backup <tablet-alias-rdonly>

vtctlclient Backup membuat snapshot dari tablet RDONLY. Pipeline ETL bisa memproses backup ini menjadi format yang dibutuhkan warehouse.

Warning

Ambil backup untuk ETL dari tablet RDONLY, bukan dari primary. Backup di primary akan menambah beban tulis yang mengganggu aplikasi. Ini alasan lain mengapa tablet RDONLY harus selalu ada di setiap shard.

#Integrasi dengan Data Warehouse

Setelah data keluar dari Vitess, warehouse memprosesnya. Beberapa pola integrasi yang umum:

Batch harian: snapshot tiap malam, dimuat ke warehouse saat traffic rendah.
CDC streaming: perubahan data dialirkan ke topic Kafka lalu ke warehouse.
Direct query: query warehouse ke Vitess lewat konektor — cocok untuk data yang jarang berubah.

Contoh query ringan ke warehouse yang diisi dari Vitess:

Query analitik di warehouse

SELECT region, COUNT(*) AS total_users
FROM users_dw
GROUP BY region
ORDER BY total_users DESC

Query SELECT ... GROUP BY region di atas berjalan di warehouse, bukan di Vitess. Data users_dw disinkronkan dari Vitess lewat pipeline ETL. Dengan begini, agregasi besar tidak pernah menyentuh database transaksional.

Untuk menjaga kualitas data di warehouse, pertimbangkan:

Schema alignment: pastikan tipe data dan nama kolom konsisten antara Vitess dan warehouse.
Idempotent load: pipeline harus bisa dijalankan ulang tanpa duplikasi data.
Data validation: bandingkan jumlah baris di Vitess dan warehouse secara berkala.

#Penutup

Pada episode 17 ini kalian sudah memahami cara memadukan Vitess dengan beban analitik: memisahkan OLTP dan OLAP di level arsitektur, menggunakan tablet RDONLY untuk reporting, mengekspor snapshot untuk pipeline ETL, serta mengintegrasikan data ke warehouse dengan pola batch atau CDC streaming.

Inti yang harus dibawa pulang:

Jangan pernah jalankan query analitik berat di primary.
Tablet RDONLY adalah jalur reporting ringan yang tidak mengganggu failover.
Backup dari tablet RDONLY bisa menjadi sumber snapshot ETL.
Warehouse butuh pipeline idempotent dengan validasi data berkala.
Data pada replica bisa tertinggal — pilih kapan data "cukup fresh" untuk laporan.
CDC streaming cocok untuk warehouse yang butuh data hampir-real-time.

Di episode 18 berikutnya kita urus otak cluster: control plane dan topology management — pilihan Topology Service, perbaikan dan backup topologi, serta vtctld UI dan automation. Sampai jumpa!