Hei, semuanya.
Dan selamat datang kembali.
Sekarang, dalam video hari ini, kita akan membahas tentang peran antrian pesan dalam transaksi database.
Jadi, mari kita lanjutkan dan pahami hal ini dengan sebuah contoh kasus.
Jadi, mari kita asumsikan bahwa Anda memiliki database tunggal yang dihosting di RDF.
Sekarang, karena promosi penjualan yang sedang berlangsung, jumlah transaksi yang benar yang terjadi di database baru-baru
ini telah mencapai sepuluh kali lipat dari beban normal.
Jadi, Anda memiliki sejumlah besar transaksi yang benar yang terjadi sekarang karena Anda memiliki satu
database yang ada dan ada beban yang tinggi, banyak permintaan yang gagal secara teratur.
Dan ada satu lagi persyaratan penting di sini adalah bahwa promosi penjualan baru yang sedang berlangsung
karena ada 20 kali lipat dari beban normal, promosi penjualan ini dijadwalkan setiap bulan alternatif.
Jadi, ini tidak berlangsung 24 jam sehari, tujuh hari seminggu.
Hal ini terjadi setiap bulan secara bergantian.
Sekarang, berdasarkan kasus penggunaan spesifik ini, mari kita lanjutkan dan lihat solusi apa yang bisa Anda
terapkan.
Sekarang, salah satu solusi paling sederhana yang dapat diasumsikan di sini adalah Anda dapat secara
langsung meningkatkan ukuran database dan juga meningkatkan jumlah provision IOPS sehingga dapat menangani beban 20 kali lebih tinggi
yang saat ini sedang berlangsung karena promosi penjualan, meskipun hal ini dapat berhasil, tetapi ada beberapa batasan
di sini.
Keterbatasan pertama adalah bahwa akan ada waktu henti, jadi jika Anda ingin menskalakan database ini secara
vertikal, Anda harus mematikan resize dan kemudian memulai database lagi.
Jadi, ini adalah salah satu tantangan khusus.
Tantangan kedua adalah peningkatan biaya.
Sebagai contoh, katakanlah Anda sekarang telah menskalakan database yang sebelumnya memiliki RAM 2
GB, sekarang database Anda memiliki RAM 16 GB dan semuanya bekerja dengan baik.
Namun, apa yang terjadi setelah promosi penjualan selesai?
Database 16 GB Anda akan berjalan sepanjang waktu dan itu akan meningkatkan biaya Anda secara signifikan.
Baiklah.
Jadi, ini adalah salah satu arsitektur yang umumnya dihindari oleh organisasi terutama karena tantangan-tantangan
ini.
Jadi untuk mengatasi hal ini, ada pendekatan yang lebih baik di mana antrian pesan digunakan.
Jadi, dalam jenis arsitektur ini, yang terjadi adalah alih-alih pesan langsung dimasukkan ke dalam database,
pesan-pesan tersebut sekarang dimasukkan sebagai bagian dari antrean ASCS dan EC.
Dua instance akan menarik pesan dari antrian dan mereka akan memasukkannya ke dalam database tergantung
pada beban.
Jadi, katakanlah basis data sudah mengalami beban yang sangat tinggi.
Kemudian pesan dapat tetap berada dalam antrian AS selama satu atau dua menit sebagai contoh, dan ketika
beban database meningkatkan set EC, dua contoh dapat menarik pesan dan memasukkan data kembali ke database.
Dan jenis arsitektur ini akan Anda lihat di banyak organisasi.
Satu hal yang perlu diperhatikan adalah dalam arsitektur seperti ini, akan ada sedikit
jeda waktu antara pesan yang dikirim oleh klien dan pesan yang dimasukkan ke database.
Jadi, akan ada sedikit penundaan waktu.
Tetapi untuk sebagian besar kasus penggunaan kali ini, penundaan tidak terlalu penting.
Jika Anda telah mengubah nama profil Anda di forum tertentu dan jika nama profil tersebut diperbarui, katakanlah
setelah 2 hingga 3 menit, itu tidak terlalu penting dan seterusnya.
Jadi, ada banyak kasus penggunaan di mana hal ini tidak menjadi masalah.
Tetapi untuk kasus penggunaan di mana penundaan waktu tidak dapat diterima, maka jenis arsitektur ini adalah sesuatu yang dapat
Anda hindari.
Jadi sekali lagi, dalam ujian, tergantung pada kasus penggunaan yang mereka berikan, Anda dapat melanjutkan dan memilih jawaban yang
sesuai.
Jadi dengan ini akan menyimpulkan video hari ini.