Ngobrolin Database
Ringkasan Episode
Bantu KoreksiEpisode ini membahas Database Scaling, khususnya perbedaan antara horizontal scaling dan vertical scaling. Topik ini diajukan oleh Mas Triad Moko melalui GitHub discussion sejak April tahun lalu. Narasumber tamu adalah Mas Doni yang sudah ketiga kalinya hadir di Ngobrolin WEB. Diskusi dimulai dengan cerita lucu tentang tagihan StreamYard yang membengkak hingga 13 juta per tahun setelah stream platform otomatis upgrade ke Pro ketika streaming ke 3 platform sekaligus. Kemudian masuk ke topik utama: database scaling. Host membahas bahwa tidak peduli seberapa cepat framework yang digunakan (Rust, Zig, Laravel), jika database query-nya lambat, aplikasi tetap akan lambat. Episode juga menyentuh perdebatan ORM vs Raw SQL, pentingnya memahami struktur data, tools untuk monitoring slow query, dan peran DBA di era modern.
Poin-poin Utama
- •Horizontal scaling = menambah jumlah server, Vertical scaling = menambah spesifikasi server (CPU, RAM)
- •Database sering menjadi bottleneck terlepas dari kecepatan backend framework
- •Perdebatan ORM vs Raw SQL: ORM support raw query, pilihan tergantung konteks dan kebutuhan
- •SQL memerlukan cara berpikir berbeda (set theory, joins, grouping) yang sulit bagi frontend developer
- •Role DBA (Database Administrator) semakin langka, tugasnya sering dibebankan ke DevOps/SRE
- •Tools untuk monitoring slow query: MySQL slow query log, pgAdmin untuk PostgreSQL, Prometheus + Grafana
- •EXPLAIN ANALYZE untuk melihat execution plan dan mengidentifikasi query yang lambat
- •APM (Application Performance Monitoring) seperti New Relic mahal, alternatif open source: Prometheus + Grafana
[MUSIC]
Dapatkan hanya di Domesticia
[MUSIC]
[TING TONG]
Hello, hello, hello
Selamat malam
Wah lupa disembunyain nih narasumbernya
Ada songsportnya
Mbak Eka, kok berubah?
[TING TONG]
Hello, hello semuanya
Mudah-mudahan teman-teman sehat-sehat ya
Yang ada di Youtube sama yang ada di linkin
Apa kabarnya?
Seperti biasa, selesam malam
Waktunya ngobrolinin
Ngomong-ngomong nggak jadi ada di Twitch lagi ceritanya
[TING TONG]
Tagian membengkak
Gimana cerita, gimana cerita ya Mas Ridha?
Mungkin bisa jadi cerita lucu
Jadi kan baru dapet sponsor nih, kan
Tujuan utama sponsor adalah untuk beli stream ya
Yang paket core namanya, yang tengah-tengah lah
Yang paling murah lah ya, iya kan
Terus nggak lama setelah dapet sponsor
Harganya naik
Harganya naik dulu
Tadinya bukan segitu
Harganya naik, abis itu
Lihat transkrip lengkap (2855 segmen lagi)
Begitu udah upgrade ke yang core
Nggak baca kan target streamingnya bisa hanya dibatasi 2
Bikin lah linkin
X nggak bisa, karena harus premium kan
Akhirnya Twitch
Jadi 3, langsung otomatis naik ke Pro
13 juta
Setahun
Abis itu langsung kaget kan dapet tagian
Kok segi ini, turunin lagi
Ternyata turuninnya juga nggak dapat uang kemali
Tapi dalam bentuk
Ini tarifan cerita ya, tarifan
Iya, tarifan nggak bisa dikasih credit
Jadi ya kita bertahan 2 tahun ke depan menggunakan stream ya
Itulah suka dukanya podcast
Gak melulu, suka melulu ya
Ada jebakan-jebakan
Iya, apa namanya
Uang sponsornya jadi nggak cukup
Harus cari sponsor lagi kita
Ngomongin sponsor ya
Seperti biasa malam hari ini sudah episode ke yang ke berapa ya
134
Dan episode ke 5 atau ke 6 ya sama Domensia
Jadi kita kolaborasi sama Domensia
Nah yang beda adalah kita dapat ini baru
Kita menerima apa namanya
Feedback dari teman-teman
VPS, jadi sekarang
Teman-teman kalau mau langganan atau mau nyobain VPSnya Domensia bisa
Pakai promo code ngobrolin VPS DN
Jadi bisa nyobain virtual private server ya atau VM lah ya
Buat deploy-deploy termasuk nyobain database
Database bisa di VM juga
Promo-nya ini 50%
Sekali pakai aja untuk pembelian baru
Bisa untuk Cloud VPS Turbo
Untuk semua paket
Tidak berlaku untuk Cloud VPS Eco
Kalau Eco ini berarti kayaknya ekonomis ya
Kalau Turbo itu yang paling kencang ya
Nebak-nebak doang
Terima kasih soalnya
Kita coba
Amin Mas Yudi semoga dapat sponsor lagi
Halo
Mas Arif juga dari LinkedIn
Ada Mas Doni
Ada Mas Doni dari Youtube
Ngomong-ngomong soal
Sudah habis
Jadi kita mendatangkan Nara Sumber Langganan ya
Udah berapa kali ya Mas Doni?
Udah berapa kali? Tiga kali ya
Tiga kali
Terima kasih banyak
Udah menyempatkan waktunya
Gimana sekarang?
Lagi sibuk apa Mas?
Lagi banyak speaker-speaker ya
Habis dari Pontianak tadi ceritanya
Ya tadi
Habis pulang dari Pontianak sebenernya
Subuh tadi
Oh tadi pagi
Tadi pagi
Kita ada kesempatan untuk ngisi
Mengenalkan AI ya
Di salah satu event
Adobe US
Kebetulan waktu itu
Diundangnya di Universitas Tanjung Pura Pontianak
Di sana
Jadi membantu untuk memberikan
Perspektif bagaimana
Untuk bisa menggunakan AI
Untuk social impact di sana
Gak melibir ke IKN
Sekalian
Jauh Mas
Siapa tahu
Aku tadi mikirnya sampai Pontianak
Berarti ngajarinya di IKN ini
Itu kayaknya
Kalau diundang di IKN itu
Mix feeling ya
Bisa lihat itu
Bisa lihat tugular yang ipsum loh
Tugular yang ipsum itu
Nggak tahu gimana
Tugu placeholder
Masih loading
Terus gimana
Animo
Teman-teman yang
Penonton di sana
Terhadap perkembangan AI
Mereka menggunakannya itu sudah sejauh mana sih
Legal workshop ya
Di sana
Yang ditargetkan itu sebenernya
Malah bukan yang punya background
Teknik informatika
Atau IT
Tapi yang ikut itu kayak
HI
Kemudian ilmu komunikasi
Di sana
Wokshopnya tentang apa
Wokshopnya itu tentang
Yang pertama itu adalah
Bagaimana perspektif dari penggunaan AI
Dalam kehidupan saya
Yang pertama, yang kedua itu
Pengenalan sederhana machine learning
Pake teachable machine
Oh
Oke, jadi bukan hanya penggunaan
Chat
Transfer learning maksudnya
Transfer learning, oh bukan
Teachable machine itu
Adalah produk dari Google
Yang dimana kita bisa melatih
Machine learning
Hanya menggunakan browser
Di sana
Yang tensorflow.js itu bukan kan
Yang bisa dieksport
Ke tensorflow.js
Oh iya iya
Waktu itu sempat dengar
Waktu masih main sama tensorflow.js
Udah lama sih
2018
2018
Waktu baru-baru
Baru muncul
Iya lagi height
Oke menarik menarik menarik
Ya, jadi malam ini
Kita akan bahas tentang
Scaling database, ini adalah topik
Diminta oleh Mas Triad Moko
Di github
Discussion kita
Iya, udah lama
Mintanya dari April
Tahun lalu
Tahun lalu lagi
April nya bukan April tahun ini
April nya tahun lalu
Yang minta dibahas tentang database scaling
Nah, saya ingat pas
Mas Donny sempat sharing
Cukup banyak kan ya di ex ya
Di twitter, tentang database kan
Kayak best practice
Wah ini kayaknya cocok nih, dicolek aja
Ternyata gayung bersambut
Jadi malam hari ini kita akan bahas
Apa sih bedanya
Horizontal scaling sama vertical scaling
Secara gampangnya dulu, gak usah dalam
Kalau vertical itu
Menambahkan
Spesifikasi dari
Misalkan 2 CPU ke 4 CPU
Jadi nambah
Upgrade
Upgrade device
Kalau horizontal itu menambahkan
Device
Open dengan spek yang sama
Untuk bisa membagi
Cluster
Oh replication
Replication lebih tepat
Oke
Oke
Oke kalau gitu, kita mulai
Dari mana, kalau misalkan
Apa
Nah ini pertanyaan penting
Yang pertama
Kenapa topik database ini penting
Oke
Kalau ada yang kemarin minta ya di githubnya
Itu githubnya Mas Riza ya
Githubnya ngobrolin web
Githubnya ngobrolin web
Nah kalau kita
Dari pertanyaan itu, oh minta dong
Bagaimana pembahasan replikasi dari
Radical punggung horizontal
Sebenernya kalau kita ngomong
Pentingnya dimana, itu adalah
Di back-end, di sisi back-end
Kebanyakan kita itu akan
Selalu berinteraksi dengan database
Di sana
Dan biasanya bottleneck aplikasi
Itu bukan di bahasa
Pemogramannya
Hmm, selalu database pasti ya
Puslim itu database disana
Katakanlah sederhananya
Pakai
JavaScript, Node.js
Atau pakai Rails, pakai PHP
Gitu kan
Atau pakai Rust, gitu ya
Pakai Rust, pakai Zig
Yang blazingly flash
Blazingly fast
Iya blazingly fast, gitu kan ya
Terus 100x kecepatannya
Tetapi in the end, kalau misalnya
Dia terkoneksi dengan database
Dan database itu
Pembutuhkan waktu 5 detik
Untuk memproses, mau pakai
Rust, mau pakai Laravel
Tetap aja 5 detik ya
Ya, 5 detik plus sekian
Disana
Sehingga pemahaman-pemahaman kita
Mengendal kapasitas
Dan skalabilitas dari database
Itu jadi menarik
Penting
Itu kayak never ends
Pembahasannya, dan sangat luas sekali
Ya, oke
Yang paling sering bikin
Lambat itu apa sih biasanya
Query, load
Atau IO
Apa semua
Sebenernya
Kalau kita mau
Apa sih yang membuat lambat, gitu kan
Yang membuat lambat itu
Sebenernya adalah bagaimana
Kita mengakses data ini, gitu kan
Kalau kita ketahui
Database itu adalah
Banyak struktur data yang
Digunakan untuk kita menyimpan data
Dan data itu disimpan di dalam storage
Bayangin dulu jamannya kita ya
Jamannya kita, tahun 2000an
Itu kan SST belum
Belum secepat sekarang
Belum murah sekarang, dan belum semurah sekarang
Murah dan cepat sekarang
Disana, sehingga kerasa itu
Bottle lag nya untuk menang sesetengah itu
Dan RDBMS
Data business ini adalah
Most of the time ada RDBMS
Relational Data Management System
Jadi MySQL, Postgres
Dan Oracle
Atau apapun itu yang berbayar
Itu mereka pasti akan
Ada tabel-tabel
Yang berrelasi satu dengan yang lainnya
Ketika berrelasi
Berarti kita harus menggabungkan
Menjoin tabel-tabel tersebut
Nah, ketika kita melakukan join
Itulah kalau kita tidak
Carefully mengatur
Desain dari data business itu
Maka proses pencarian datanya
Akan menjadi lambat
Disana
Jadi yang membuat lambat itu
Adalah skema nya
Dan cara kita mengambil
Datanya
Query
Plus seberapa besar data
Tersebut
Mungkin dalam tabel bisa giga-giga
An gitu ya
Terapai kalau yang udah di level
Besar sekali
Disana, itu berpengaruh
Oke
Kalau ngomongin
Query
Berarti ada pengaruh
Penggunaan ORM juga dong ya
Oh, itu yang
Kayaknya rame ya
Rame ya
Kita bahas
Di
Di forum
Dan di kalangan
Ada tim puris ya
Tim puris SKLRO
Ada yang tim apatis
Tim ORM
Tidak ada yang lebih baik
Tapi itu tergantung kondisi dan konteks
Iya
Kita juga semua ORM
Itu support
raw SKL kan ya
Harusnya iya
Jadi ORM itu sebenarnya
Gak ini ya
Bukan sesuatu yang
Sangat support gitu
Bahkan mereka itu bisa
Dan raw query
Kalau misalkan ada masalah
Kalau kita pakai ORMnya langsung
Kita mau lebih efisien itu sebenarnya
Bisa tuh
Pakai raw query
Bagi penonton yang berasal dari
Dunia front-end
Kalau database query itu
Antara
Query langsung atau ORM
Itu sama dengan main CSS
CSS vanilla
Pake tailwind
Ya itu lah
Perbandingan apple to apple nya
Iya itu
Analogi yang bisa dipahami ya
Iya
Khusus penonton nanti yang
Ini orang front-end apa ya
Kalau tailwind kayaknya masih
Agak low level ya
Kurang lebih lah begitulah ya
ORM itu object
Relational mapper
Dan
Mungkin ada
Beberapa istilah
Juga
Kalau kita mau berinteraksi
Dengan database maksudnya
Aplikasi atau kode kita mau berinteraksi
Dengan database
Maksudnya
Kalau pakai ORM kan gampang
Bisa koneksi
Terus bisa query pakai
API atau SDK nya dia
Masing-masing ya
Mau pakai drizzle atau pakai
Action
Action apa
Kalau rails lupa namanya pokoknya
Semua ORM ya
Terus
Juga sebenernya
Ada library yang
Di tengah-tengah namanya itu
Query builder
Kalau di node.js itu namanya ada
Dulu ya gak tau sekarang ya ada namanya
Next.js k-n-e-x
Nah itu dia hanya
Hanya membuat
Query aja
Jadi dia
Tidak
Tidak merelasikan antara
Object oriented ya
Object oriented programming dengan
Table atau
Di database gitu jadi dia hanya query
Builder aja
Tapi pengalaman ya
Misalnya kalau bagi kita yang bisa
Langsung SQL query
Dan
Diketemukan sama orang yang
Gak pernah menentu database
Dan taunya hanya main di front-end
Memang susah memahami
Memahami SQL
Query itu loh
Karena harus paham matematika
Dan
Paham itu kan diagram
Dan segala macam kan diagram
Oh join-join
Join-join dan grouping
Itu sebenernya
Kalau
Pada namanya konsep berpikirnya
Sangat berbeda
Untuk lakukan SQL query
Kalau dari sisi
Seberang ya bukan susah
Menjago backend tapi sisi seberang
Itu sulit loh
Karena beda konsep berpikir
Makanya adalah ORM untuk
Mempermudah hip
Tapi dulu saya waktu awal
Awal karir banget
Itu sempat
Ditandemin dengan ada role yang namanya
DBA database administrator
Memang masih ada sampai sekarang
Dia yang bikinin query kita tinggal
Minta doang
Nanti dia bikinin viewsnya kita tinggal
Tinggal select
Tinggal select dari view yang dia buat ya
Enggak select malah udah dikasih
Kayak snippet-snippetnya ini untuk select ini untuk insert
Ini untuk apa gitu
Udah disediain jadi enak banget
Merasa dimanjakan
Gitu
Karena view beda lagi
View itu bisa bikin subset dari table
Betul-betul jadi dia bikinin
Khusus misalkan oh saya mau join
Table ini sama table ini namanya table student
Mungkin subjek gitu ya
Dia bikinin itu view student subjek
Jadi kita gak perlu join
Kayaknya sekarang role nya udah gak ada ya
Atau mungkin role untuk itu
Tapi DBA masih
DBA masih
Kalau yang enterprise itu
DBA itu penting
Karena urusannya
Itu tadi scaling
Scaling
Replication
Backup
Restore disaster recovery
Semua kayaknya penting deh
Tugas DBA itu
Orang
Di dunia modern ini mulai jarang
Mencari DBA
Pada akhirnya kemampuan
Ini itu dibebankan ke temen-temen
Devops, SRI
Dulu Devops, SRI
Padahal itu kayak
Ada art
And science nya sendiri
Aku coba untuk belajar
Database internalnya tuh
Even kayak
How it works itu aku harus tahu
Tentang tree
Tree base data structure gitu
Bagaimana parser dari SKL
Dari kita ngeparser
SKL query supaya jadi execution
Disana itu kayak
Bisa satu semester sendiri
Itu membahas itu semua
Oke
Kalau gitu kita omongin
Gimana caranya
How to start
Gimana mulai untuk
Misalkan udah punya
Database nya
Untuk optimize nya itu mulai dari mana
Mungkin ini berhubungan
Ini ya introdasinya ada
Salah satu pertanyaan di youtube ya
Mas tabel saya pas SKLnya ukurannya
Kurang lebih 300 giga tuh
Mereka nyoba tambah index
Solusinya terbagi gimana
Jadi ini ada step by step
Ya untuk kita mengetahui
Dan nanti
Akan semakin kompleks
Bagaimana kita bisa
Optimize nya
Yang pertama ketika kita mengetahui adanya
Kelambatan dari aplikasi kita
Itu terkadang majoritas
Di Indonesia atau di perusahaan
Indonesia itu belum punya
Monitoring atau observability yang
Cukup oke
Untuk bisa mengetahui blockways
Bagaimana
Jadi definisi lambat itu
Harus ditentukan tidak semua
Proses lambat kan
Misalnya kalau ada select
Select data limit 5
Itu kan enggak lambat
Yang bikin lambat itu adalah query
Yang beri impact ke
Semuanya
Berarti yang harus diketahui adalah
Tahu enggak ada yang slow query
Ini digunakan
Yang namanya ada
Observability tools
Jadi kalau misalnya kamu kebetulan
Kami di siruan group itu
Expertisnya di Postgres ya
Jadi apakah yang cerita dari Postgres
Ada tabel
Kalau pakai PSPL
Aja itu ada tabel namanya
PG stat statement
PG statistic statement
Gimana kita bisa tahu query yang
Lambat
Jadi kalau misalnya
Mas data bisaya lambat
Yang mana yang bikin lambat
Jadi temukan dulu
Querynya
Yang lambat
Atau kalau misalkan
Ada yang punya Grafana
Kalau ada yang pakai
Kalau di Google ya, ada yang namanya Cloud SQL
Itu ada beberapa
Ada beberapa
Metric yang kalian bisa access
Slow query
Itu bisa disediakan
Jadi ada nggak tools
MySQL, ada MySQL slow query kan
Bisa dibuat locknya
Ada
MySQL bisa diaktifkan konfigurasi nya
Untuk lock
Slow query
Nanti query yang lebih dari
700 milliseconds
Atau 1 second itu akan di lock
Betul, disana
Dan setiap engineer itu punya channel
Bisa sendiri untuk mengetahui
Bagaimana slow query itu
Di sana
Jalan Postgres sendiri itu
Kalau kami, biasanya kami pakai
Prometheus ya, untuk irim Metrics
Ini mungkin agak sedikit detail
Ke infra, tapi intinya adalah
Gunakan tools yang mampu untuk bisa
Mengakses statistiknya
Even phm admin aku nggak tahu ya
Phm admin itu ada nggak tools
Untuk mengetahui itu
Karena gpg admin
Itu juga ada beberapa tools untuk
View, jadi tabel itu bisa
Diview di dalam GUI nya
Sehingga GUI nya tahu bahwa ini
Ada beberapa slow query
Yang muncul disana
Jadi itu dulu mas Jejen
Yang pertama gitu kan
Kita lanjutin yang kedua gitu kan
Nah ketika ada
Sudah tau nih, ada
Top 5 gitu kan, top 5 atau top 10
Kita bisa
Investigate, mulai dengan
Ada
Ada salah satu SQL namanya
Bila Explain Analyze
Ini yang mungkin
Jarang ya
Diajarin di kampus juga
Disana
Dan
Orang itu nggak ngah kalau ini tuh
Ada fiturnya, jadi
Explain Analyze
Query
Yang dimana, kalau mungkin
Mas Riza bisa bantu
Untuk mencari ya
Disana
Itu ada, bagaimana kita
Tahu bahwa query tersebut
Yang
Ada atau image ya
Untuk bisa melihat
Repersentasi maksudnya apa
Gak ada, kita cari yang
Lain
MySQL
Reading
Postgre Query Plan
MySQL juga
Punya tuh
Itu kan yang di Postgre ya
Jadi ada, mungkin yang ini aja
Stop disini aja Mas Riza, yang ada hasil
Plan
Misalkan disitu kan
Ada Explain Analyze
Ada selectnya gitu kan ya
From dari
Dari tabel mana
Ada filternya tuh disitu
Nah
Itu akan memberitahu bagaimana
Kiranya, planningnya
Eksekusi itu akan berjalan
Disana, jadi disitu ada
Beberapa
Beberapa detail
Bahwa
Di dalam query itu akan melakukan sesuatu
Di databasenya
Dan
Untuk memahami ini
Itu kita harus belajar
Bagaimana penyimpanan data
Di dalam database, kalau kita
Bisa lihat disitu yang
Yang paling gampang aja, yang paling sering terjadi
Kita nggak usah lihat
Joint condition, total-total
Harusnya ada total ini ya
Ada planning, execution time itu
Lapan, itu lapan
Lapan millisecond
Lapan ribu
Lapan millisecond
Ini koma ya
Iya itu lapan millisecond
Aku lupa bahasanya gimana
Di disana, tapi
Tapi intinya ini nanti akan
Disitu ada salah satu kunci
Namanya sequential scan
Sequential scan disitu
Berarti dia itu akan mencari
Di seluruh data yang ada
Di dalam data table tersebut
Jadi worst case scenario-nya
Berarti end ya
End of data, disana untuk
Menemukan disitu
Dan itu yang kita
Bisa lakukan adalah mengimprove bagaimana
Logika
Data itu disimpan dan ditemukan
Kembali
Jadi basicnya disini
Pemahaman, pembacaan
Explanation, planningnya
Disana
Jadi intinya sebenarnya
Yang pertama adalah
Di-measure ya
Diukur, lambat itu seberapa lambat
Cepat itu seberapa cepat
Karena itu kan relatif ya
Jadi bisa diukur pakai
Apa namanya?
PG-Stat
Terus
Habis itu bisa pakai
Slow query juga kalau di MySQL
Atau lewat APM
Juga bisa kan kelihatan kan ya
Bisa, bisa APM
Tapi biasanya mayoritas
Ini ya
Maksudnya apa kan pekerjaannya
Banyak menghandle
Legacy code dari
Legacy line
Itu jarang punya APM yang bagus
Biasanya
Jadi
Kalau nggak punya
Apalagi kalau yang melihat ini
Malah di luar gitu kan
APM itu kan tidak apa-apa
Disana
Kita bisa langsung akses database-nya
Kalau mau pakai
De-beaver gitu ya
Bisa juga
Sayang-sayang
Sayang-sayang aku udah lama nggak hands-on ya
Jadi aku nggak bisa
Nge-bisa demo-in
Di sini, tapi intinya
Kalian tuh bisa hanya menggunakan
CLI doang untuk mengetahui
Query mana yang lambat
Disana
Boleh mungkin di-spill
Sedikit ya, APM yang bagus itu
Standarnya Mas Donny apa sih?
APM yang bagus adalah
Tergantung budget
APM itu mahal ya
New Relic
Iya, New Relic
Iya, New Relic
Tapi mahal
Kalau punya budget New Relic
Data drop ya
Data drop juga mahal
Tapi kalau mau tahu
Zero One Group pakai apa
Prometheus ganti dashboardnya
Di Grafana
Tapi kami lagi main ekspor namanya
Prometheus
Back-endnya Elastic Stress
Kenapa?
Prometheus back-endnya
Prometheus itu
Stack yang berbeda
Kalau Elastic Stress itu LK
Elastic Log Test
Kibana
Elastic sama Kibana
Betul-betul
Kalau yang Grafana itu biasanya LGTM
Loki
Grafana Tempo
Mimian
Open Source Solution
Kalau misalnya ya
Enterprise, on-premise
Gak perlulah
Kamu bisa akses sendiri lah database
Query gitu
Langsung SSA
Langsung masuk ke ini ya
Atau database-nya di-dump dulu
Coba-coba di lokal gitu ya
Jadi kalau mau start gitu
Kalau mau pakai APM
Kami pakai LGTM
Dan kami lagi eksporasi Cygnos namanya
Cygnos, oke
Sentry mahal by the way
Apa mahal?
Sentry
Sentry mahal ya
Mahal untuk di-running self-host
Jadi dia butuh 4 CPU
4 CPU
6 dan 3
Oh yang self-hostednya ya
Ya, tapi untuk buat start up itu ya murah-murah aja
Tapi dia juga startnya udah yang 4 CPU juga gak murah kan ya
Kalau dihitung per bulannya lumayan ya
Oh iya, lumayan
Jadi makanya APM apa yang paling terbaik tergantung budget
Semakin mahal semakin baik
Ya maksudnya kan tadi
Menyebutin APM-nya kurang gitu kan
Ternyata memang, berarti budgetnya memang kurang
Nah ini Nur Holid ini mantep nih
Sering pakai explain analyze semenjak ada isu query
Ternyata karena order by
Kalau short order dari join gak pake indexing
Ya dia sekuensial
Jadi mungkin kasih gembaran umum ya
Sena yang tadi kan bahwa
Ketika kalian anak back-end itu
Akan sangat bermanfaat
Menginvestasikan waktunya bagi mana tetap sepekerja
Di sana
Nah proses indexing itu adalah
Sebenernya adalah membagi pencarian
Dengan melalui struktur data tree
Gitu
Jadi kita tidak perlu menge-scan semuanya
Data yang ada
Ada yang paling populer itu adalah
B-tree namanya
B-tree index
Di situ yang secara umum sering digunakan
Jadi kalau
Kalau tidak di indexing gitu kan ya
Dia akan langsung nge-scan semua
Yang tadi aku bilang di awal
Nge-scan semua row untuk mencari data
Di sana
Dan itu bisa kayak
10-100x ini
Waktunya
Even seribu
Untuk bisa nyari data
Di situ
Iya
Perlu ya apa
Harus belajar big o notation
Big o notation ya
Analytics good
Analytics good
Analytics good
Sering juga
Karena
Keburu terekspos dengan
Banyak best practice
Kalau database lambat
Tambahin aja indexnya
Index itu kan kalau analoginya
Kayak apa ya? Kayak buku gitu ya
Buku ini lah
Yellow Pages ada yang ngalamin ga sih?
Contact deh
Sebenernya kayak
Sebenernya kayak liat
Kalau kita ngomong
Kalau kita ngomong
Kamu kayaknya terlalu
Marketnya generasi
Yang lebih muda kayaknya ga pernah
Pilih-pilih baju
Daftar isi
Daftar isi tebel o konten
Nah itu
Ini
Langsung gue tunjukin nih
Ini butuh
Buku manual mobil saya
Terus kan isinya
Banyak banget ya kan
Gak mungkin saya baca satu-satu
Yang mau saya cek dimana
Tentu
Kalau index di database itu
Ya langsung saya langsung ke daftar isi
Disini, oh masalah Oli
Halaman sekian
Bukan, daftar isi di depan
Biasanya index di belakang, bener ga sih?
Kalau buku ya
Kalau buku definition indexnya beda
Ya definition indexnya beda
Kalau kayak ini aja lah
Oh ya daftar isi, daftar isi di depan
Kalau
Di belakang itu index
Index untuk kata-kata kan
Ya
Kalau yang di database itu index ini
Index begini, bukan daftar isi
Betul, jadi kayak apa ya
Contact book lah, contact book
Kalau misalkan saya mau cari
Atau Mas Donny mau cari Riza kan
Saya harus scroll dari A sampai R
Dulu kan
Jadi pencet aja huruf R
Nah baru cari Riza, deket
Kalau saya kan tinggal pake "Hi Google
Call Riza"
Woi woi woi
Ini analogi digital ya
Mau ngeluarin yellow pages
Sudah ga punya
Jadi contact book aja
Gitu lah ya
Dan kalau index
Ini di apa ya
Semuanya di index
Ya jadinya sama aja
Balik lagi kayak kita baca buku satu halaman
Satu halaman gitu
Jadi harus diperhatikan juga
Jadi tidak
Semua solusi adalah menambahkan index
Sebenernya karena sebenernya
Kalau kita lihat
Kalau kita menambahkan indexnya lebih banyak
Berarti ketika proses data itu dimasukkan
Itu juga harus memasukkan indexnya juga
Pada waktu itu
Dan itu adalah rate performance
Rate data base nya
Bayangkan
Kalau misalnya itu data
Itu sering banget diisi
Let's say tablet transaksi ya
Yang dihajar banyak
Itu jadinya bisa lebih lama banget
Jadi kita harus punya ini ya
Semua itu trade off ya
Semua itu trade off
Tidak ada solusi ini
Silver bullet
Dan kebanyakan index
Storage nya membengkak
Overhead
Karena index itu kan perlu disimpen
Dalam bentuk pointer
Bahasanya sih pointer
Menuju datanya di raw mana
Jadi kita simpen
Indexnya itu disimpen lagi
Di table pointer
Dan pointer itu memakan space
Kalau data base nya membengkak
Storage kita membengkak juga
Jadi ada
Trade off juga
Yang bakal kita bahas
Kalau sudah mandek disini
Kita next step nya
Lanjut
Jadi next step nya
Setelah katakan lagi
Udah nih kita
Udah oke nih mas
Query nya udah
Udah kita improve
Udah kita kasih index
Disana
Yang dilihat dari level coding nya lagi
Teman-teman disini pakai connection pooling apa enggak
Disana
Connection pooling itu
Ketika kita melakukan connection
Kedalam setelah database itu kan butuh
Membuka connection
Ada shake hand
Ketika sudah dipakai
Connection itu diputus
Bayangin kalau kalian pakai connection pooling itu akan jadi terus-terusan
Contoh analogi nya
Karena kita selalu membahas analogi
Analog analogi nya itu kayak
Kamu parkir sendiri
Mobil kamu
Masuk ke parkiran
Cari yang kosong gitu kan ya
Terus keluar dan super market
Nah connection pooling ini namanya pool ya
Jadi mengumpulkan connection itu kayak
Avali sebenarnya
Jadi kita enggak
Ini kita menggunakan
Satu
Meja yang sama gitu kan ya
Untuk menaruh parkiran kita sederhananya gitu
Jadi connection
Yang kita gunakan untuk membuka
Database
Itu akan direuse untuk
Request yang lain
Jadi kita buka
Connection
Itu juga ada art
Sama science nya sendiri
Karena
Gak bisa dibuka terus
Connection itu bergantung pada RAM
Bergantung pada RAM
Satu connection itu
Mungkin 25 MB
Dan berapa aplikasi
Yang kalian buka gitu kan ya
Kalau misalnya aplikasinya
Ini ya, pakai kube
Horizontal scale, berarti
Kamu harus maintain, kamu harus hitung
Berapa connection pooling yang
Bagus
Kalau misalnya pakai container kan
Container kan bisa
10 kan
Buka connection ke database
Yang sama database nya kan
Gak mungkin, gak banyak juga kan
Jadi kalau misalnya
Container nge scale, jadi dari 10
Ke 100, kalau dia pooling
Mulu, ya misalnya
Masimal tadinya cuma bisa 10 pooling
Ya yang lain bottleneck, nunggu
Tunggu yang satu dimatikan dulu
Dia baru bisa buka lagi
Jadi bottleneck di
Connection
Jadi bukan database nya yang lambat, tetapi
Jalurnya
Yang penuh
Jalurnya yang penuh, jadi tidak hanya database nya
Harus dipikirkan bagaimana kita perinteraksi
Dengan database nya
Salusinya adalah
Ada hitung-hitungan sederhananya
Sebenarnya
Kamu mau pasang
Container berapa
Kamu mau pasang
Kalau kita ngomong ini ya
Kalau kita ngomong
Efficient untuk kita
Bisa menggunakan RAM nya itu
Kita ada hitungan kasarlah
Karena
Ini pengalamanku
Mengerjakan software project di Indonesia ya
Itu tidak
Sampai ke scale nya unicorn
Yang banyak banget
Itu
Kayak
Kebanyakan database yang
For CPU 8GB
Setiap ada
Satu container
Satu container itu bisa buka berapa
Connection itu sebenarnya kita bisa hitung
Di situ, jadi bukan
Kalau misalkan ada database tau-tau
Aku pake kube supaya bisa handle banyak request
Belum tentu
Engga juga
Engga auto scaling tapi koneksinya
Di database nya
Engga cukup gitu kan ya
Anri pada akhirnya
Kayak jalan raya
Ya mobilnya banyak
Tapi jalannya sedikit atau kecil
Jadi ngantri tetap ngantri ya
Terus terakhir dari
Sepenceng apalah juga ya
Terus terakhir
Dari level code ya
Kalau tadi kita udah bahas sedikit
ORM
Kita tau misalnya
Ada LF1
Terus active record
Yang jahat
Prisma ya
Prisma drizzle
Type ORM
Terus sedikit terakhir ya
Perkara ORM ya
Dulu itu pernah maintain salah satu
Salah satu agensi
Yang trading edge ya
Di enterprise
Prisma versi 1
Prisma engine nya masih pake skala
Skala?
Dulu itu Prisma
Engine nya pake skala
Versi 1 ya
Dan itu
Ada GitHub issue dibuka
Salah satu caranya adalah migrasi ke versi 2
Dan selalu out of memory
Karena Java
Karena JVM
Jadi temen-temen yang
Aku gak bilang kalian harus jago
Ini ya SQL
Karena juga tadi bener kata mas Ivan
Frontend itu mungkin
Tidak punya banyak waktu untuk bisa
Mengerti semua yang terlihat kan
ORM itu bisa mematuh
Jadi sebenarnya ya gak ada salahnya
Juga pake ORM
Kecuali kamu di mata purist gitu kan ya
Buat apa pake ORM
Berlaku kebudakannya
Ngapain gak mau nulis
Gampang
Gak produktif ya
Gak produktif
Yang penting ini aja sih
Awareness kita tahu
Kita pake ORM
Jadi kalau terjadi kelambatan
Kita coba cek disitu dulu
Karena kita dari aplikasi
Masih ada satu layer lagi
Sebelum ke SQL
Padahal SQL itu kan sudah layer untuk
Komunikasi ke database kan
Jadi ada satu layer
Di atas SQL
Query Vanilla
Tapi ada sudut pandang yang berbeda nih
Kalau Frontend, anak Frontend kan
Sekarang udah terbiasa dengan
Deklaratif kan
Ngulis kodnya kan
Deklaratif pake React lah
Atau SwiftUI
Sql itu kan deklaratif
Jadi belajar juga harusnya lebih muda
Ya mungkin belajar syntax baru
Cuman kan
Apalagi sekarang bisa dibantu AI
Jadi mungkin cara
Belajarnya sekarang jauh lebih
Learning curve nya
Lebih rendala dibandingkan dulu
Sulit sih mas
Maksudnya
Saya bisa
Belajar Tau SQL Query itu karena kuliah
Dan saat kuliah itu
Mata kuliah database itu
Sampai kayaknya 2 semester deh
2 semester
Basis data 1 sama
Basis data 2
Dan waktu itu
Base nya Oracle
Dan memang dari awal tuh
Dari select, grouping, segala macem
Dan nanti sudah yang basis data 2
Itu lebih advanced lagi
Kayak
Stored procedure
Fuse
Itu sebenernya
Banyak yang bisa
Bisa didistribusikan
Jadi gak perlu semuanya
Di level aplikasi
Stored procedure itu bisa
Di level database kita bisa membuat
Function nya kita sendiri
Di database
Jadi kita cuma tinggal panggil function itu doang sebenernya
Itu bisa cuman
Itu gak stored procedure saya yakin
Di dunia
Kalau kita
Merujuk kepada dunia
Frontend yang pengguna
Next.js dan segala macem
Pasti stored procedure itu bukan
Sesuatu yang sering didengar
Kalau yang sampai
Yang susah juga
Maintainan di dalam stored procedure nya susah
Gak bisa masuk ke git lah
Gitu kan susah kan
Betul
Dia nyantol
Di database nya jadinya
Jadi semuanya sekarang
Semuanya di level aplikasi
Dan database nya sekedar
SQL query nya saja
Untuk ambil dan transaksi data saja
Tapi sebenernya
Database is more than that
Banyak lho
Contoh
Mungkin
Kalau
Melakukan
Select distance misalnya
Radius
Kalau misalnya kita punya
Mapping
Lokasi warehouse
Mana ya kita
Mau
Query jarak terdekat
Dari
Latitude
Longitude ini
Contohnya
Kalau pakai
Aplikasi
Itu susah
Misalnya kita harus query semua
Warehouse
Lalu pakai aplikasi untuk mencari
Jarak terdekat dari latitude longitude
Yang kita punya dari titik tengahnya kita
Anggap aja kita punya ini ya
Punya
Franchise
Dan punya banyak store
Terus mau ditampilkan di Google Map
Contohnya
Terus kita mau cari
Yang mana jarak terdekat dari
Jakarta Barat misalnya
Itu kan dia bisa
Ngecari radius
Kalau pakai aplikasi susah itu
Tapi kalau pakai Postgres
Itu tinggal select distance
Postgres ya
Postgres
Dan bisa langsung sort by distance
Gini ya
Satu query
Itu maksudnya
Banyak hal-hal yang bisa
Database itu bisa lakukan lho
Yang lebih-lebih dalam
Nah ini
Menjawab tadi ya
Rumus connection pool ya
Sebenernya banyak rumus
Spindles ini apa?
Spindles itu
Kalau misalkan
Sebentar aku lagi
Buka Google resource ya
Di sana
Jadi bisa
Ada yang ngomong
Ada yang ngitung itu dari CPU
Ada yang ngitung dari
Tadi kan aku bilang kayak satu buka connection itu
Sekitar 25 megabit
RAM di sana
Referensi ku itu
Mungkin lebih ke
Cari coba cari referensi dari database engine
Yang kalian pakai
Yang aku ngomong RAM itu tadi
Postgres
Beberapa orang ngomong bahwa
Ambil aja 25
Ambil aja 1 connection pool adalah
Di Prisma itu kayak
Ngomong connection pool itu
Dia ambilnya
Ada CPUnya juga
Di sana, hitungannya ada CPU juga
Jadi menurutku kalau menjawab pertanyaan ini
Coba cari database enginenya
Kemudian coba cari beberapa
Referensinya
Aku nggak terlalu
Ada hal yang sakit, karena aku kalau liat di Google
Banyak banget referensi
Connection poolnya
Atau start default dulu deh
Default itu jadi good starting point
Nanti lihat pakai APM
Baru nanti kita bisa lihat apakah connection poolnya itu
Biasanya di APM itu
Ada limit
Connection biasanya
Kita terlalu banyak pakai connectionnya apa nggak
Masing-masing database berbeda ya
Cara penanganannya ya
Kita lanjut aja kali ya
Kita ada beberapa tahap
Di situ
Nah setelah kita udah lihat nih dari keseluruhan
Ternyata tidak masih bisa
Mahendal, baru kita mulai untuk
Bermain infrastructure di sana
Yang paling populer
Di selain scaling gitu ya
Apakah database ini
Punya kompetensi yang berat
Alternatifnya adalah menambahkan layer
Di atas database itu
Adalah credits ya
Caching, kemudian ada
Gvalue store
Yang bisa disimpan di ram biar lebih cepat
Ada search engine
Elastic search
Melee search gitu kan ya untuk mencari data
Ada messaging queue
Jadi yang biasanya untuk
Kayak Kafka
Biasanya kalau data
Rate-nya, call rate-nya tinggi
Daripada kita harus dihajar
Di satu endpoint gitu kan
Kita kasih queue di sana supaya
Lebih terproses dengan
Berurutan
Jadi writing-nya ngantri
Ada queue-nya gitu ya
Pake Kafka
Atau Revit MQ
Itu terserah lagi ya
Terserah dengan familiaritas dengan
Apa teknologi yang digunakan
Mungkin quick lagi ya
Setelah itu
Ada technical scaling ya, itu udah deh
Paling gampang udah
Lakukan semua masih berat
Naikin CPU sama
RAM-nya
Kenapa?
Karena itu
Kita masih bisa maintain dengan
Ini tergantung seberapa besar tim infra-nya
Atau tim monitoring-nya
Paling gampang adalah naikin
Kalau pakai clock enak ya
Tapi kalau on-premise
Kalau saya
Kalau pakai on-premise
Hybrid
Kalau saya
Cek dulu, ini hard disknya
Pakai apa? Masih pakai piringan atau
Itu cek dulu tuh
Karena
Kalau mau gimana pun
Dinaikin, kalau masih piringan
Tetep aja lambat
Dan ini ada
Beberapa pembahasan ya
Salah satunya DHH itu adalah
Yang bikin Rails ya
Oh
Anumayar Hansen
Ya itu
DHH
DHH
Dengan
Kecepatan storage CPU itu
Bahkan sekarang banyak perusahaan
Besar itu masih bisa handle single note
Tetap di sana
Jadi vertical itu
Jadi solusi disitu
Ketika vertical sudah gak bisa gitu kan ya
Terlepas dari budget dan kawan-kawan
Muncul horizontal scale
Yang paling gampang horizontal itu
Bahkan read replica
Jadi
Ketika ada satu database
Kamu bisa tambahkan database kedua
Untuk hanya
Mencari budget database
Disitu
Jadi ada write
Write db
Ada read db, kalau jaman dulu
Yang bahasanya tidak
Inclusive itu
Ada master slave
Jaman gue
Jaman yang gak sudah inclusive
Jadinya harus write sama
Read
Bisa primary replica atau worker manager
Itu tergantung
Ya
Tapi horizontal
Scale juga ada masalahnya juga gitu kan ya
Horizontal scale itu
Replikasi menambahkan
Sesuatu
Latensi
Kemudian kalau misalnya kita membaca
Tapi belum di replikasi
Out of sync
Delay
Itu sudah busing
Out of sync itu
Itu adalah salah satu teori
Yang kita sebut dengan cap theorem ya
Cap theorem itu adalah
Konsistensi, availability
Ataupun partition
Kita gak bisa dapatin ini semuanya
Di sana, jadi kalau kamu mengejar
Konsistensi, berarti ada masalah
Availability, out of syncnya lebih
Lebih ini, lebih
Kerasa
Tapi kalau katakanlah
Ini apa contohnya
Financial application
Kan gak boleh itu misalnya
Ngirim apa
Ngirim uang
Tapi waktu
Orang baca lagi gitu kan ya
Di request kedua kalinya, aku masih pakai saldo yang lama
Bahaya ya
Harus konsisten di semua replica yang ada
Tapi itu berimpak
Sehingga sampai availability
Orang itu gak banyak bisa handle request
Secara concurrent
Availability yang diutamakan
Konsistensi gak perlu
Itu contohnya social media
Kan gak perlu amat kamu harus melihat
Exkut yang terbaru
Terbaru
Yang berubah
Konsisten ke semuanya
Gak harus
Dan banyak tools ya
Banyak tools yang
Di gunakan
Kalau di Postgres itu ada nama Patroni
Patroni untuk bikin
Streaming
Blaster, Postgres
Kalau di MySQL itu Vitesse
Ataupun Proxy SQL
Di sana
Vitesse bukan Vitesse JS ya
Bukan, bukan Vitesse
Bukan Vitesse pakai buat view itu ya
Bukan, bukan
Intinya adalah dia itu
Ada Proxy nya
Yang Patroni itu intinya adalah
Ada Proxy di depan database itu
Yang dia nanti ngatur
Oh ini adalah query read
Dia yang mengatur
Menatur jalannya
Query, jadi di depan itu ada
Load balancer namanya Haproxy
Haproxy
Haproxy
Terus data
Data key value store yang disimpan
Dalam cluster itu pakai etcd
Di sana
Oke
Kayaknya kalau ngomongin Load balancer
Satu topik sendiri lagi kayak Load balancer
Itu, itu
Round-robin
Ada banyak poin ya, algoritma
List connection, layer
Berapa Load balancernya
Panjang ceritanya ya
Jadi kalau
Database vertical horizontal itu kan
Harus ada Load balancernya kan
Jadi yang ngatur
Kan dari aplikasi koneksinya
Cuma tau satu, tapi dari Proxy
Yang ngatur mau ke database yang mana
Yang mungkin cara jadulnya itu adalah
Kalau misalnya tidak ada Load balancernya
Di depan itu kayak
Di dalam code nya ada dua koneksi
Oh ini, ini yang buat
Ada array, ada array
Ngecek ini write apa write
Jadi manual, itu pun bisa dilatukkan
Di sana ya
Jadi ya cuman bikin replika aja
Kamu nggak ada Load balancernya di depan
Itu masih bisa aja, tapi ya
Ribet di aplikasinya
Untuk handle itu ya
Di sana
Mungkin dua lagi tentang scaling ini
Yang selanjutnya itu adalah partisi
Jadi tabel yang gede banget misalkan
Itu bisa dipartisi
Jadi beberapa, kita memacah
Kayaknya ada data structure lagi
Ada 1TB itu kan tabel itu dibagi
250GB supaya lookupnya
Lebih gampang
Di sana, dan yang terakhir
Itu adalah sharding yang di mana
Kita bagi tabel
Semua tabel
Di berbagai macam
Notes
Di server yang berbeda
Itu lebih kompleks
Tapi ada open source yang dibuat oleh Microsoft
Untuk membantu mempermudah
Sharding di Postgres namanya
Cetus
Cetus
Gimana?
Aku nggak tahu saya ngomongnya gimana nih
Cetus, mi apa?
Nggak ada yang relate lho
Kita yang ketawa doang
Last thing
Perkara scalingnya
Kalau kamu mau nggak berepot, ada yang namanya serverless
Data base sekarang lagi rame
Ini planet scale ya?
Planet scale
Planet scale
Itu planet scale ya?
Kalau di Postgres namanya neon
Neon
Jadi dia mau memisahkan
Compute engine nya dengan storage nya
Jadi itu
Another things lagi
Jadi itulah
Sedikit ini ya, macem-macem
Gimana kita bisa nge scale data base
Iya, sempat penasaran juga
Ini serverless data base ini
Gimana kan? Sebelumnya kan kita
Aplikasi yang serverless
Ini data base juga serverless juga ya
Yang diserverless
Kan itulah secara teori
Sederhananya adalah pemisahan
Storage dengan compute nya
Di sana
Jadi
Compute nya yang di scale
Auto scale
Compute nya yang di auto scale
Compute nya yang di auto scale
Di situ
Secara dalam nya aku belum dalam lagi
Tapi itu yang bisa membuat pada akhirnya
Bisa serverless
Jadi disana
Oke
Ini buat MySQL yang tadi neon buat
Postgres ya
Siap
Mantap
Itu untuk
Serverless
Tapi
Dalam sampai tahap apa sih kita
Perlu mendata base scaling
Karena ada juga ide
Kayak apa itu
Situs besarnya masih pakai
Eskialight
Sanggup-sanggup aja gitu
Discord ya
Enggak salah eskialight ya
Bukan
Eskialight
Enggak tahu ya apa ya
Aku lupa
Eskialight itu yang sebenarnya
Unique selling point nya
Adalah dia embedded kan
Jadi yang paling banyak dipakai adalah
Ya HP Android
iOS ya
Windows, HP, Handphone ya
Itu eskialight semua kan
Ya
Tapi kalau untuk
Product web
Ini ada yang kayak aku share ke mana ya
Share ke private chat
Private chat
Docs juga boleh
Ada itu tuh
Kayak berapa terah itu eskialight
Yang mana yang mana
Oh ini private chat ya
Ada
6 terabyte
Searchcode.com
Searchcode.com
Wow
Gede loh itu
6 terabyte
Nah kalau
Eskialight itu gimana
Gimana scalingnya
Gak bisa
Satu file kan
Filebase kan
Enggak usah
Scaling nya dulu deh
Deploy nya gimana kalau deploy
Kalau pakai docker kan harus stateless kan
Gak bisa ya
Saya juga baru belajar kemarin harus pakai volumes
Kalau kita ngomong mungkin aku secara detail
Aku belum baca ini ya
Bagaimana cara dia bisa ngasih scale sebesar
Tapi kita coba untuk
Apa sih benefitnya eskialight
Daripada rdbms engine yang lain
Ya boleh
Jadi
Jadi nilai tambah dari eskialight itu
Adalah kemampuan untuk performance
Query datanya itu sendiri
Di sana
Jauh lebih cepat dari
Apapun rdbms engine yang ada
Mau mysql, mau postgres
Tetapi kurangnya dimana sih
Kurangnya itu adalah
Di dalam konkurensi
User untuk akses database
Asebut
Karena tidak digunakan untuk
Di akses dalam waktu yang bersamaan
Database nya
Di sana
Makanya ada yang namanya Tursow ya
Tursow
Ada satu eskialight
Kemudian direplikasi
Di edge
Untuk orang yang bisa
Akses banyak
Dia itu memanfaatkan
Performance yang eskialight
Kemudian cara yang nyebarnya gimana
Direplikasi ke multiple edge
Untuk bisa mematasi
Sekian concurrent user
Jadi sebenarnya benefitnya
Eskialight itu disitu
Dan banyak juga project-project
Jadi tidak segede-gede apapun
Kayak dashboard
Itu kan banyak heavy di read ya
Itu kita gunakan eskialight aja untuk
Performance query datanya
Kalau kita tidak di akses banyak orang
Contoh ada satu project CMS
Yang aku share di google docs
Itu kan namanya PocketBase ya
PocketGIS itu adalah siap
Kayak eskialight
Ya ya ya
Pernah pake ini
Pernah bahas ya
Disitu
Ini back-end nya go
Terus dia kasih back office
Kan kita bisa operasi bisa
Insert data bisa
Manipulasi bisa update bisa delete
Kan ya. Terus ada
Dia kasih rsapi nya ya
Routes nya ya
Betul disana dan itu pun
Majoritas
Mungkin orang itu cukup
Disana untuk menggunakan eskialight
Tapi jujur aku tidak pernah
Melakukan komparasi
Yang cukup komprehensif ya untuk bisa
Berani berkata bahwa
Ada sekala-sekala tertentu yang
Kayak konkurensi kali ya
Konkurensi
Konkurensi akses
Sebenernya
Kalau misalnya
Kita bikin aplikasi
Yang dipake banyak orang kalau pake eskialight
Mungkin bottleneck disaat read
File nya karena dia file base kan
Betul ya ya ya
Sedangkan kalau
Aplikasi yang personal
Contohnya ya
Misalnya mozilla thunderbird itu pake
Eskialight
Karena kan terisolate
Satu user satu data
Justru kalau pake mozilla thunderbird
Pakainya install my eskialight lagi
Ya susah ya kan
Jadi efektnya pake eskialight
Pocket base kan personal
Atau
Paling maksimal ya 4-5 orang
Dalam keluarga doang kan
Pake ini gitu
Ya kalau misalnya
Sudah di akses sama ratusan
Ribuan secara
Concurrent mungkin
Harus pake DBMS
Ada post read and read file nya itu
Read and write file nya
Yang jadi masalah
Untuk local first juga cocok
Mas Ari sih
Orang dalem orang dalem
By the way
Ada satu kasus yang membuat
Battle neck juga
Kalau saat DBMS itu
Sedang melakukan write operation
Dia akan butuh
Dia sedang ngerite ke table ya
Ya blocking, dia akan blocking
Kalau ngerite, dia akan
Locking ya, bukan blocking
Ada locking mekanisme kan
Kalau satu process sedang
Ngerite dan
Ngerite plus
Ngeindeks kan, jadi habis write dia
Ngerite index, dan process itu
Butuh waktu, nah kalau misalnya
Ada concurrent yang sedang membaca
Table itu di saat yang sama, dia akan
Lock dulu, menunggu sampai process
Write selesai, baru bisa dibaca
Baru bisa diselect ceritanya
Nah, ini
Kita cerita bukan pakai cluster
Yang ada read write
Table ya, beda
Satu database doang
Ceritanya, ya itu akan terjadi
Yang namanya locking mekanisme
Dan karena ada locking
Ya, kelihatannya
Query kita yang
Nge-select selanjutnya itu
Kelamaan, tapi sebenarnya
Kan nge-lock oleh
Process yang sebelumnya
Nah, itu bisa jadi pengalaman
Pribadi
Oh ya, itu sebenarnya kalau yang dibilangin
Mas Ivan adalah
Konsekensi dari mislifat
DBMS yang menerapkan akit
Mungkin kalau teman-teman
Yang kuliah ya
Dan aku selalu tanya
Waktu skill test nya Zero One Group
Kalau ada yang apply
Di Zero One Group, itu selalu aku akan tanyakan
Tau nggak akit itu apa
Di sana
Asem
Jadi, akit itu adalah kepanjang dari
Atomicity, konsistensi,
Integrity, dan Durability
Dan setiap engineer itu
Punya caranya sendiri untuk menghandle ini
Di dalam Postgres itu aku share
Mas Riza di private chat
Ataupun di Google Docs
Ada yang HPG locks the query
Mungkin kita lihat bareng-bareng
Jadi, untuk menjaga
Sebuah integritas dari sorto database
Itu kadang-kadang kita harus nge-lock processnya
Dan setiap query itu punya
Skala lock nya masing-masing
Di sana
Di dalam ini
Dia ngasih tau semua
Impact dari
Query kita itu apakah
Table atau Room
Di sana
Jadi kadang-kadang
Ini juga yang aku masalahin di beberapa project enterprise ya
Karena kan query nya cukup jelimit
Di sana
Di dalam top 3 SQL itu bukan
Yang bikin cool print
Tapi adalah
Impact dari locking
Locking ini
Nah itu ada
Locking sendiri
Jadi kita
Di dalam Postgres itu ada
Locking buat lock
Jadi kita harus kayak
Ini mana yang nge-lock
Di sana
Bisa di trace ya dari situ ya
Di satu
Nah locking ini lagi-lagi
Untuk kita kadang-kadang
Ada konsep namanya
Seperti kayak
Mau beli web ini, tapi di Seriwan Group kan punya live streaming juga
Namanya Astro Office ya
Itu waktu itu
Salah satu engine Seriwan Group, Mbak Amel
Itu bahas tentang ada
Yang namanya bagaimana Postgres itu
Menghandle integritas data
Jadi misalkan apa yang dibaca
Orang itu apakah data yang baru
Atau data yang lama
Dalam suatu transeksyen
Ada konsep namanya ghost read
Ghost read datanya atau gimana
Dan setiap data based engine
Itu punya caranya sendiri
Untuk handle
Bawa bawa bawa
Bawa
Sama itu
Anak BE wajib tahu ajib
Itu itu itu
Bagaimana Postgres itu
Integritasnya gimana
Sebelah mana dia menjaga integritas
Datanya supaya terjadi
Data yang konsisten
Di sana
Jangan lupa di subscribe ya
Live nya setiap
Beberapa bulan
Oh lagi libur
Coba cari format live
Oke oke
Ini tadi
C
Tadi masih
Berlanjut ngobrolin tentang
Eskelat ya
Ada ada apa
Ada beberapa yang menarik juga
Ternyata ada banyak
Yang scaling juga
Salah satunya apa
Posting ini tahun berapa ya
2022
Dia bisa sampai 200 juta
Request per bulan
Atau 4 juta
Request per sekai
Levels I/O ya
Ya levels I/O
Dia kalau gak salah pernah cerita
Eee
Lupa ya
Buka aja opsennya levels.io
Ini kan
Apalagi yang
Pinter namanya
Ya pinter levels ya pinter levels
Yang produknya banyak banget kan
Kalau gak salah dia pernah cerita
Kalau dia pake eskelat itu untuk multi tenancy
Application
Jadi satu tenant satu
Satu udah habis
Expensive
Bukan gak tau apa namanya
Yang jelas
Dia pernah cerita kayak
Ada orang yang
Berlangganan SAS nya dia
Dia bikin satu instant atau satu tenant
Itu database nya satu aja
Jadi selain aman
Nampur sama database orang lain
Yang kedua ya
Udah database nya itu doang satu
Ini beda piter
Beda piter
Beda tuh
Beda
Ya pasti kan ada kayak
Ini ya spesifik use case
Yang kita gak tau gimana cara
Set up nya ya
Tapi di websitenya eskelat.org
Went to use ya, jadi mungkin itu ada referensi utamanya
Went to use
Dari eskelat.org
Yes
Ini ada referensinya silahkan
Kalau ada kasus seperti itu
Kita ke eskelat.org
Ini juga salah satu
Project
Yang sangat menarik
Karena sebenarnya dia
Open source
Dalam artian
Codenya bisa dilihat
Tapi yang bisa commit atau yang bisa nge push
Cuma 3 orang yang punya perusahaan
Gak menerima pull request bahasa itu
Gak menerima pull request ya
Jadi read only ya
Went to use
Ada tuh went to use eskelat itu
Jadi kalau misalnya mau tanya apa harus pakai eskelat sih
Itu
Embedded device
Ini udah pasti ya kan
Udah umum
Application file format
Website
Berarti ini web scale ya
Kalau misalnya
Most of system kita
Pasal block nya Mas Riza
Gak ada masalah pakai eskelat
Nggak gak pakai database
Coba bikin block pakai database
Banyak kali ada yang mau bikin
Kalau block nya sampai
100
100 artikel per hari
Perlu Mas
Itu bukan block itu
Portal berita
Internet kerjaannya Mas Ivan
100 kata per minggu aja
Belum tentu bisa
Apalagi 100 artikel
Ini
Seru ya
Yang nomor 2 nya
Client server
Application
High volume
High concurrency
High concurrency
High concurrency ya
Yang kita bahas
Writer nya itu
Masalah
Betul-betul
Karena file base
Jadi ada
Locking mechanism yang berbeda kan
Pada saat mungkin ada yang lagi
Hanya boleh 1 orang yang boleh merubah
Hanya boleh 1 orang
Jadi gak
Kongkaren
Oke pertanyaan pertama dari saya
Sebelum kita menjawab pertanyaan penonton
Kalau scaling
Scaling yang mana dulu nih
Horizontal
Kalau memang dibutuhkan scaling
Vertikal dulu lebih mudah ya
Ya vertikal sampai mentok
Dan maksudnya vertikal itu tidak selamanya
Jadi yang biasa
Vertikal dulu temukan toolprint nya
Down
Uses nya diturun lagi
Oh bisa
Bisa ya
Jadi kalau kita pakai ini ya
Kalo kan
Apalagi ya pakai manage ya
Manage service
Itu kita harus naikin
Ada concept downtime nya
Kita harus tau downtime nya berapa lama
Setelah dinaikin gitu kan ya
Kita tau nih toolprint nya
Di mana kita work on it
Turun
Diturunin akhirnya
Jadi kayak naik itu hanya untuk sepersekian
Hari
Sepersekian hari untuk
Disana
Supaya gak down
Kapan-kapan harus
Ini tuh gak bisa naik lagi
Gitu adalah ketika memang
CPU nya naik ya
CPU nya naik tapi tidak ada
Slow query yang
Berarti gitu kan ya
Tapi lebih karau banyak request
Untuk nge handle read secara
Secara jumlah request nya
CPU nya naik tapi tidak ada slow query
Tidak ada itu berarti
Sebelah harus di replikasi
Kalau seasonal
Contohnya
Kayak 11/11
9/9, 10/10
Biasanya
Itu disediain dulu
Disediain dulu
Di pre-empt ya
Tau bahwa itu seasonal
Ready
Atau banyak teknik ya
Caching nya sebelah mana
Karena kan contoh yang bisa share ya
Jadi akan pernah terjadi
News media
Quick count
Itu kan seasonal
Iya itu seasonal
Jadi kalau misalnya
Ada satu website yang perlu di read
Caching itu adalah
Bumper utama
Semua di caching
Multi level dari GraphQL nya
Di caching, dari data
Per item nya di caching
Itu level caching nya
Itu banyak dari atas sampai bawah
Tapi kan kalau quick count di caching
Ngamuk tuh entar
Iya, kok nge-net naik ya
Tapi kan quick count
Nggak real time pak
Masa? Oh iya ya
Per 5 menit, per 10 menit update nya ya
Nggak mau level lho
Kalau kita mau real time
Itu beda cerita webshop ya
Ternyata iya kan
Sekalian aja online
Berarti bukan quick count dong namanya ya
Periodic count
Catching count
Catching count
Quick itu kan
Relatif
Iya
Kalau real time count baru
Beda, harus real time
Iya
Atau biasanya
Bulan 2, bulan 3 itu kan
Pelaporan pajak
Tahunan kan
Itu biasanya
Lambat juga
Apalagi awal tahun
Ganti ini ya
Ada versi baru ya
Awal tahun ya
Untung bisa pakai yang lama
Untung tahun ini bisa pakai yang lama
Aku masih pakai yang lama sih
Aku masih pakai yang lama sih
Karena berusaha login nggak bisa
Yaudahlah pusing
Kalau untuk
Peribadi iya yang lama
Tapi kalau untuk perusahaan nggak bisa
Karena pakai yang ber kan
Skortex iya
Luar deh
Ya ampun
Oke
Sebelum kemana-mana
Ini kita jawab-jawabin ya pertanyaannya
Saya siswa RPL kadang bosen
Belajar database, mudah-mudahan abis dengerin ini
Jangan nggak bosen ya
Banyak banget yang bisa di eksplor
Dan kebanyakan
Database itu mahal lho
Iya, kebanyakan developer
Sekarang kan fokusnya belajar aplikasi
Sedangkan database nya kan itu kayak
Second class gitu ya
Kalau kita punya kemampuan database yang
Kuat kayaknya nilai tambahnya
Lebih gede kali ya
Udah bisa bikin app, database nya
Kencang gitu ya
Saya di company saya salah satu
Engineer yang
Mengerti banyak
Mengenai Elasticsearch
Jadi secara karir saya aman
Karena masih ada beberapa klien
Banyak klien yang pakai
Elasticsearch
Jadi kalau ada apa-apa
Saya tetap masih punya pekerjaan
Database engineer
Dajinya menarik
Oh iya
Oh iya
Yang menarik adalah
Sekarang itu banyak AI startup
Bisa jauh datas UMR
Banyak AI
Database
Faktor database
Lagi banyak startup
Itu kadang-kadang
Tahu internalnya, Postgres
Itu sangat-sangat menarik sih
Tapi ya
Berat sekali untuk belajar dan musuhnya
Berat-berat juga
Berat-berat juga
Ini tadi ada yang
Ngomongin tentang
Elasticsearch itu kan bagian dari
NoSQL berarti ya
Ya itu dia
Bukan
Bukan SQL base ya
Bukan SQL base ya
Search engine ya
Search engine jatuhnya ya
Ini ada pertanyaan tentang
MongoDB
Kalau MongoDB gimana scalingnya
NoSQL
Kalau, jadi kalau
Sekarang sederhana ya
RDBM itu sangat
RDBMS itu
Dia kan ada
Asset compliant ya
Dengan posisi dan rubriknya
Most of NoSQL itu adalah
Asset compliant tapi high scalable
Karena
Ini mau read write-nya itu
Cepat banget, karena kan tidak ada skema
Yang menggunakan satu tabel dan satu tabelnya
Di sana
Dia read write-nya cepat
Di sana, tapi saya ingat
Itu MongoDB versi terbaru
Dia mencoba untuk menambahkan fitur
Aku gak tahu konsepnya gimana
Tapi itu
Jadi mungkin ada
Fitur di dalam Mongo
Jadi lebih kala-kala spektrumnya NoSQL itu
Heavy
Highly scalable
Tapi tidak
Agile compliant, RDBMS
Agile compliant tapi tidak
Gampang di scalingnya
Susah scalingnya ya
Susah scalingnya ya
Oke, ini tapi pertanyaannya
Bukan tentang MongoDB sih
Ada proses transaksi yang saat ini
Displit menjadi beberapa collection
Collection-nya, panjang banget
Ada paca ya
Ini database apa ini
Ada alasan khusus
Kenapa skema nya displit terlalu panjang
Pertanyaannya ada gak?
Baca lagi, isu saya sekarang untuk
Generated Report
Agregat data, agregat data salah satunya
Kesulitannya di NoSQL
Kalau non-relational
Untuk agregasi adalah musuhnya
Itu musuh utamanya
Tidak bisa
Kenapa pakai NoSQL?
Atau kalau mau gak mau
Cara paling gampangnya adalah
Mas bikin tron job
Buat masukin itu ke relational database
Atau bikin objeknya sendiri
Khusus untuk view
Atau bikin collection
Bikin collection yang dimana itu
Ngebungkan, jadi ada summary
Ada ITL-nya ya
Extract
Terus di load collection itu
Khusus buat report itu
Jauh lebih gampang bacanya
Jadi bukan quitcon lagi, jadi batching
Saya juga sering menemukan
Beberapa hal tentang
Biasanya terutama MongoDB
Atau NoSQL itu
Mindsetnya masih relational database
Jadi design tablenya itu
Masih relasi gitu
Masih dipisah-pisah
Jadi keunggulan si NoSQL
Jadi gak kepake gitu kan ya
Jadi harus join-join juga
PR banget itu kalau join-join
Aku juga waktu budget firestore dulu ya
Itu cara
Membuat simulasi kita kan
ID ini
Di beberapa collection itu
Itu share gitu
Jadi ketika kita punya satu ID ini
Dia langsung ambil semuanya
Dalam satu waktu bersama itu
Salah satu cara mengakali simulasi
RDPMS
Tapi aku udah agak lupa sih
Karena udah lama banget gak main
Tapi jangan segera
Mengembangkan sama SQL
Jadi RDPMS itu salah
Ya, justru
Kelebihannya justru bukan disitu
Kelebihannya adalah ya tadi
Kencang untuk
Nulis dan baca, tapi kalau untuk
Join-join mah susah, SDK-nya susah
Ada pertanyaan tentang Firebase Data Connect
Wah, gak ngerti nih saya, Mas Donny ngerti gak?
Aku pernah bikin inkos senang ini ya
Di platform lain
Intinya adalah
Data Connect itu sebenarnya pakai Cloud SQL
Cloud SQL?
Oh, oke
Ada magic happen disana
Berarti kamu hal-hal
Tahu bahwa
Ya, jadi kalau kita connect your app
To fully manage scaleable database
Using Cloud SQL for scale-scale
Cuman, Data Connect itu
Interface-nya pakai GraphQL
Itu doang sebenernya
Oh
Oke, oke
Kebayang-kebayang
Untuk saya, aku gak bakal pakai itu sih
Kenapa?
GraphQL, gara-gara GraphQL, bukan?
Karena kami custom solver
Solusinya harus jadi on-off
Oh, karena ini ya, karena kebutuhan
Jadi gak akan pakai, karena gak cocok
Kalau itu cocok buat kamu
Pakai aja nih
Kira-kira cocoknya buat aplikasi seperti apa
Atau perusahaan apa
Yang bergerak di bidang apa
Startup
Karena dia ada
VectorDB ya
Vector PG Vector
Disana, dan ada GameKit
Firebase GameKit
Pernah bikin blog di Google Cloud
Indonesia ya, jadi gampang banget
Bikin receiver sama indexer-nya
Pakai GameKit
Oke, oke
Oh, berarti dia lebih ke integrasinya ya
Kalau kita
Real-time database-nya
Itu connect gak ke
Fire, apa namanya?
Firestore ya? Firebase yang
Real-time database itu? Beda ya?
Beda
Beda ya, oke
Itu kan non-sql juga ya
Itu non-sql juga ya, berarti ya
Ya
Nah, Firebase ini juga salah satu
Database yang mungkin anak front-end
Cukup familiar ya, dengan Firebase
Atau supabase sekarang
Atau tadi pocketbase, dan base-base yang lain
Ada budi-base banyak banget
Bagaimana budi-base?
Itu budi-base
Kayaknya CMS no code ya?
Iya, budi-base itu
Yang buat budi bukan ya orang Indonesia
Itu kayak
Google Cool
Internal Tools gitu loh, Mas
Iya, buat internal tools, kayak apa ya
Ritual
Ritual, ya Ritual
Ya Ritual
Buat dashboard internal
Nah, Mas Rio
Untuk lo audit trail, better
No-sql atau rdbms?
Audit
Trail
Bukan yang pakai itu ya, tadi ya
Elasticsearch gitu ya
Kalau logging-logging
Siapa pernah, akses siapa
Pernah untuk
Nyimpan ini kan ya, lebih ke
Apakah NTT itu dirubah
Bentuk perubahannya apa, kemudian
Siapa yang merubahannya
Aku kebetulan banyak
Kasus dimana
Table audit logging itu di dalam
Database yang sama
Jadi
Menurutku secara mayoritas
Audit ini kayak akan jarang
Dikunakan ya, di akses
Dalam kondisi tertentu
Nggak harus dipisah sih
Mendingan pakai database yang sama
Dan nggak perlu ada relasi, itu cuma kayak
Dam doang
Oke, oke, ada tips nggak
Untuk pindahan data-database
Dari sql server ke
Postgre
Dengan
Iya ya, enak sekarang ya
Kalau dulu kita bikin sendiri ya
Karena
Sebenernya jadi masalah itu adalah
Sql itu share
Sql1 dengan engineer itu
Mungkin di angka 70%
Jadi kamu nggak bisa
Dengan query yang sama
Itu bakal
Mati, gitu kan
Satu-satunya cara adalah
Ya udah, gitu pakai
Demini buat
Untuk bantuan AI ya
Bikin ini disana
Atau pakai ORM
Multi-dialect ya
Data-based ya
Disini gunanya ORM juga ya
Itu juga benefitnya
ORM sih, bisa pindah-pindah
Data-based
Jadi yang mengurus ini tuh bukan kamu
Ya, abstraksi
Ngomongin ORM
Kalau project awal pakai ORM, sekarang
Quailshare aja udah terasa latensinya
Apakah perlu re-readdb atau
Pake query-builder
Ya
Latensinya
Di mana dulu, cari dulu
Cari tahu dulu
Root cause-nya
Locking mechanism
Atau
Locking, atau memang
Ada slow-query, atau ya
Mp1 Anda itu
Yang manggil-manggil
Berulang kali
Jangan-jangan aplikasinya
Atau kodenya yang
Four di dalam four
Terus panggil query langsung kan
Bisa aja, banyak ya
Jadi harus cari tahu ini dulu
Jangan asal
Re-write
Karena takutnya masalahnya bukan di situ
Kawatirnya masalahnya
Bukan di situ
Ini pertanyaan internal nih
Mas Aris
Sampai saat ini ada perdebatan pemilihan tipe data
Primary ke antara UID atau serial
Atau Big Indie MySQL
Ini nama-nama
Nanti aja di jawab internal
Buat yang nggak tahu
Kalau serial itu kan
Autoincrement kan ya
Kalau sekarang kan sudah
Disarankan untuk tidak menggunakan auto increment
Karena terlalu mudah di
Prediksi
Bisa mudah ditebak
Misalkan user/1/edit
Ini user ID 1 nih
Bisa ketahuan
Jadi lebih disarankan menggunakan UID
Itu kalau dari sisi awam ya
UID sudah versi berapa sekarang?
UID 7 ya?
V4
V7
Ada lagi yang baru ulit
Ada ulit itu sudah sendiri
Oh ada, beneran dia
Saya pikir
Bedanya V7 sama V4 itu adalah
V7 itu sudah menambahkan timestamp
Unique timestamp
Dalam generasinya
Kalau di versi 4 kan
Dia cuman random set of
Ini ya, unique
Tidak ada timestampnya, jadi tidak bisa dissolve
Secara ID
Di sana
Perdebatannya panjang
Atau UID
Di sana
Karena set of example itu
Pasti akan mengambil storage
Cukup lumayan
Karena cukup panjang untuk mencari unique ya
Unique, unique ID
Di sana
64 ya?
64 karakter ya?
Berapa banyak sih?
128 bit
128 bit
Panjang ya, panjang karakternya
Apa ulit?
48 bit unique timestamp
4 bit versi random data
Di sana
Oke
Bisa pilih salah satu ya
Kalau pindah dari auto increment ke
UID atau ulit gimana caranya?
Bikin aja
Tablebar, te kolom baru
Generate aja UID nya
Pindahin index nya
Tapi gak jadi primary key
Ya ubah aplikasinya
Dulu
Di alternya
Gak mungkin diritikkan itu kalau direplace
Mending tambah kolom baru
Mending tambah kolom baru
Jangan direplace ya
Apalagi delete
Delete kolom itu cari masalah hidup sih
Terus dari aplikasi
Dilarang
Dilarang menggunakan ID
Jangan lagi pakai kolom ID
Pelan-pelan ya, gak langsung
Semuanya ya, kecuali aplikasinya kecil
Jangan dirit kolom, itu benar kata mas Tony
Apalagi kalau sudah deplikasi
Sekali dirit kolom gede
Itu syncronasi lama
Bisa out of sync
Kalau udah out of sync sakit kepala
Saya kalau sudah out of sync
Mending saya matiin to server
Generate ulang, replikasi aja
Karena sudah susah
Kalau udah out of sync
Aku pernah delete database production
Waktu magang baru 3 hari
Serius
Saya
Saya belum pernah
Delete database, tapi saya pernah
Delete query, tapi lupa where
Begitu liat seribu sekian
Roll affected
Oh oh, kalau itu pernah
Benarnya itu jadi test dari
Perusahaan itu sih, apakah dia punya
Mekanisme dimana kalau ada mistake
Dari sesuatu, bisa direcover dengan
Udah
Di sana, jadi itu experience
Yang tidak akan terlupakan sih
Kalau misalnya, by the way itu
Pernah disini, anaknya Zero One
Untung ada backup
Jadi beneran literalnya, delete
Ada para di backupnya jadi aman
Oh, kalau Mezo
Katanya, tadi
Pernah delete database, tapi nggak kehapus
Gak beneran kehapus, soft delete atau gimana
Nggak tahu deh
Keringet dingin
Oh, di test kali, emang sengaja kali
Di test, emang harus mengalami itu
Dan itu juga bagian test dari perusahaan
Apakah siap kalau terjadi kesalahan-kesalahan
Itu kan kesalahan umum ya
Kalau sesuatu yang
Kamu kerja pernah
Waktu kerja, pernah mengisi form
Untuk bersedia, bekerja di bawah tekanan
Itu paling di bawah tekanan itu kayak gitu
Itu bekerja di bawah tekanan
Itu
Job description yang paling tidak
Tidak bisa dijelaskan
Tekanan apa dulu
Oh iya, itu juga ya
Makanya jangan sekali-kali
Mengesekusi
Sql, yang Mas Oddy itu
Mengesekusi Sql
Di production itu harus dilihat dua kali ya
Kadang-kadang lupa, aware itu
Hapus-hapus semua itu
Betul-betul, saya juga pernah mengalami
Ini kalau aware-nya lupa
Bahkan bukan hanya delete, update
Update juga bahaya kan, aware-nya lupa
Oh iya, nggak pakai aware itu
Makanya harus
Mekanisme
Production, staging
Testing itu harus
Ini dulu ya, harus clear dulu
Kalau di lokal kapus ya
Udah
Harus jangan sendirian ya
Kalau mau mengupdate sesuatu
Di production jangan sendirian, harus lebih dari satu
Orang
Ada kuncennya
Pak Imre kayaknya sekarang rolnya itu ya
Kuncen, udah habis dia ya
Kuncen
Harus udah kuncennya, nggak boleh sendiri
Apalagi anak magang
Wah, ini ada sesuatu yang aneh
Kalau anak magang bisa akses database production langsung ya
Jadi ya gitulah
Kalau saya pernah
Arcing, delete
Tetapi lupa supply
Pathreal-nya
Terus, kehapus dong
Ya kehapus lah
Production
Harusnya path-nya itu A, B, C, D, E, E
A, B, C, D
Tetapi
Waktu di concat itu C dan D-nya
String kosong
Jadinya A, B aja
Jadi semua yang di belakang A, B itu
Ke delete
Aduh kan diwasa
Tapi itu jalannya di GitHub Action
Dan saat deploy
Loh, kok ilang semua
Hati-hati yang kalau pakai
Siapa yang ngerubah kondisional ini
Wah, dilihat
Ya
Tapi bisa recover
Berhasil recover atau
Tidak
Pertanyaannya, saya nggak tahu file apa yang kehapus
Jadi, yang penting-penting
Berhasil recover
Tetap ada backup-nya
Backup file-nya itu kebetulan nggak ada
Jadinya ada yang hilang sih, tapi ya
Ya sudahlah
Ya sudahlah ya
Lesson learned
Pendewasaan ini ya
Tapi bukan saya
Saya bukan, bukan saya penyebabnya
Saya yang dipanggil untuk
Nge-recover
Di investigasi
Recover
Nggak, langsung kayak
Kalau bahas di rumah sakit, code blue
Kayak langsung
Kebakaran
Emergenci, dan saya yang ditugaskan
Untuk merecover itu semua
Secepat mungkin
6 jam saya, sampai jam 12 malam
Baru bisa recover
Berapa situs ya
16 situs
Banyak ya
Itu pendewasan diri ya
Kalau mau jadi senior engineer
Harus melewati fase itu ya
Harus pernah horror story
Besok paginya
Nulis RCA
Postmortem
Postmortem
Sudoh RMRS
Sudoh ya
Ya bukan sudoh, arcing, arcing delet
Itu juga masalahnya
Bahaya, sama bahaya
Sama RMRF
Sama
Menghilangkan sesuatu
Dengan cara yang berbeda
Kalau database
Nggak sih
Kalau database, rusaknya karena itu tadi
Ya saya lakukan delet
Tapi kebanyakan, tapi lupa
Aplikasinya, replikasinya
Yang lain, akhirnya terjadi
Out of sync, database nya
Loking, segala macam
Ya
Sakit kepala disitulah
Membantu situs
Plug Merah
Dia juga
bottleneck nya
Di web server, di hujung nih
Banyak traffic, tapi database nya
Satu, dan nggak ada caching
Itu juga masalahnya
Banyaklah
Pertanyaan terakhir
Ini tentang trigger
Ini mirip juga, kayak tadi kita udah bahas
Store procedure ya, trigger juga sama
Susah maintenance trigger
Betul
Preferensi ku adalah
Mendingan di aplikasi
Karena tidak semua orang
Aware tentang store procedure
Tidak semua orang mengerti
Bagaimana membaca itu
Kalau aplikasi kan sudah fair sama semua ya
Mengerti tahu bahwa itu ada
Cron job, atau ada
Triggering suatu disitu
Paling mentok
Yang aku pakai di post way itu
Adalah auto
Out of sync
Listen change
Jadi ketika ada
Kita kayak, web server itu ya
Kalau misalnya ada suatu
Table, kita bisa listen
Ketika ada perubahan, dia
Otomatis juga menghasilkan
Data yang paling baru
Disana, jadi ada itu di post way
Dan digunakan sama
Beberapa anak siruan
Sebatas itu
Kayak custom
Bikin
SPG
SPG, PGL sendiri
Itu terlalu
Terlalu ini
Terlalu susah untuk
Dipahami
Terlalu susah untuk dipahami, iya
Jadi, sebar-sebar ya bisnis logicnya ya
Lo masih live
Mereka, lo masih live ya
Banyak yang curhat soalnya
Banyak yang curhat
Ini baru mau udahan
Udah pertanyaan terakhir
Gimana, kita cukupkan?
Cukup
Kita cukupkan sampai disini, berarti kesimpulannya adalah
Kalau mau scaling data bis
Pertama yang dilakukan vertical scaling
Dulu ya, sampai mentok
Sampe mentok budgetnya
Ya, sampai mentok
Bukan, sebelum melakukan scaling
Cari tahu justifikasi
Kenapa butuh scaling
Oh iya, ini dulu
Measure dulu
Lambat itu seberapa lambat
Jadi sebelum di optimize
Di measure dulu, oh
Waktu sekarang ini 3 detik
Jangan sampai
Begitu di optimize, malah jadi
6 detik, gitu ya
[tertawa]
Monitoring itu penting
Monitoring itu penting, karena kita bisa tahu
Betul
Sukses apa
Term of suksesnya apa
Kalau optimize, harusnya kan harus lebih cepat
Kalau kita nggak tahu
Berapa lama database
Query-nya dijalankan
Ya, kita nggak bisa measure
Nggak bisa ngitung ini
Jadi lebih baik atau lebih buruk, gitu
Jadi harus measure dulu
Habis itu kalau mau scaling ya
Di check, di check ini dulu ya
Di check query-nya satu-satu
Indexing-nya
Connection pool-nya
Terus ORM-nya
Kalau pakai ORM, di optimize
Query-nya, kalau bisa pakai
Query kalau udah
Lumayan kompleks
Terus habis itu baru
Menuju ke infra
Infra-nya tadi kita nggak bahas ya
Kasing-nya dulu
Kasing-nya dulu
Betul
Kalau misalkan kayak Postgre
Atau MySQL itu kan banyak ya servisnya ya
Ada Cloud SQL
Ada
Aurora
RDS, macam-macam gitu ya
Atau kita bisa sendiri
Menyalahin VM
Install Postgre
Jadi gitu kan bisa juga
Tapi kalau pakai yang servis kan lebih gampang ya
Lebih sederhana
Ada monitoring-nya juga
Terus kalau
Berasa masih lambat
Vertical scaling sampai mentok ya
Mentok, entah itu mentok mesinnya
Atau mentok duitnya, budgetnya
Karena
Semakin ke atas itu
Semakin mahal ya, jaraknya semakin tinggi ya
Harganya
Dan nggak linear ya
Harga Cloud itu nggak linear
Nggak linear
Eksponensial mereka itu
Eksponensial, betul
Kalau setelah vertical scaling
Udah mentok, baru larinya ke
Horizontal ya
Jadi horizontal itu adalah mesinnya dibanyakin
Kalau vertical itu mesinnya
Di upgrade
Abis itu bisa dipecah
Mau dipecah pakai
Replika, partitioning
Sharding
Dan lain-lain
Kalau SQLite beda lagi karena dia satu file
Dan servisnya
Kalau di Cloud-Cloud besar nggak ada ya
Harus bikin sendiri ya, atau pakai
Pocket base tadi
Oke, mungkin cukup
Ada lagi yang mau disampaikan
Sebelum kita udah, cukup
Terima kasih buat teman-teman
Diskusinya seru
Beberapa pertanyaan yang belum terjawab
Mohon maaf belum bisa dijawab
Nanti larinya ke
Github aja
Atau ke Eks
Ke Github
Discussion atau ke Eksnya, Mas Donny
Eksnya apa?
Baru aku liat
Ternyata juga ada bagu hantam
Sedikit informasi aja, di Eks
Sudah ada bagu hantam tentang ORM dan
Rockwell, aku baru liat
Oh iya?
Oh iya?
Apa pas banget kita lagi ngomongin gitu
Tiba-tiba ada bagu hantam
Iya, bagu hantam ini
Ya udah deh
Mas Donny ini yang punya
Manjalah Gatra bukan sih?
Apa?
Bukan!
Sebenernya
Sebenernya, mana ininya
Ini
Terima kasih
Bukan
Iya, Mas Donny harus mampir lagi
Harus
Harus sering-sering mampir ya, jangan sampai
Ya
Oke
Mungkin sekian dulu
Terima kasih buat semuanya, terima kasih juga
Buat Mas Donny yang udah menyempatkan hadir
Terima kasih Mas Donny
Kita ketemu di
Ayo Eks ya
Ayo Eks
Atau di manapun kita ketemu ya
Sampai ketemu
Buat Ivan
Dan Eka, sampai ketemu minggu depan
Bye-bye
Bye-bye
[MUSIK]
Buat eksplorasi, kita akan mencoba.
Deskripsi asli dari YouTube
🗣️🕸️ Selasa malam waktunya #NgobrolinWEB! Malam ini kita akan membedah berbagai cara scaling database. Masih bersama panelis tetap kita Ivan dan Eka. Dan turut mengundang narasumber ahli. 🏷 Gunakan kode NGOBROLINWEBDN dan dapatkan DISKON 10% Untuk Pembelian Web Hosting DomaiNesia: Beli Web Hosting DomaiNesia disini: https://my.domainesia.com/ref.php?u=25754 🎁 DISKON 50% Cloud VPS Turbo dengan Kode Promo: NGOBROLINVPSDN Beli Web Hosting DomaiNesia disin: https://www.domainesia.com/cloud-v Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Jul 2024
Ngobrolin Elixir
Episode ini membahas tentang Elixir, bahasa pemrograman fungsional yang berjalan di BEAM (Erlang Virtual Machine), bersa...
24 Des 2024
Ngobrolin WEB edisi Offline Surabaya
Episode ini adalah sesi tanya jawab Ngobrolin Web versi offline yang diadakan di Surabaya. Pembahasan mencakup berbagai ...
31 Jul 2024
Ngobrolin Big-O
Episode ini membahas tentang Big O Notation, sebuah konsep fundamental dalam ilmu komputer yang digunakan untuk mengukur...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .