Ngobrolin Database - Ngobrolin WEB

0:00[MUSIC]

0:11Dapatkan hanya di Domesticia

0:13[MUSIC]

0:19[TING TONG]

0:22Hello, hello, hello

0:26Selamat malam

0:28Wah lupa disembunyain nih narasumbernya

0:30Ada songsportnya

0:31Mbak Eka, kok berubah?

0:34[TING TONG]

0:38Hello, hello semuanya

0:40Mudah-mudahan teman-teman sehat-sehat ya

0:43Yang ada di Youtube sama yang ada di linkin

0:45Apa kabarnya?

0:46Seperti biasa, selesam malam

0:48Waktunya ngobrolinin

0:51Ngomong-ngomong nggak jadi ada di Twitch lagi ceritanya

0:56[TING TONG]

0:59Tagian membengkak

1:01Gimana cerita, gimana cerita ya Mas Ridha?

1:04Mungkin bisa jadi cerita lucu

1:07Jadi kan baru dapet sponsor nih, kan

1:10Tujuan utama sponsor adalah untuk beli stream ya

1:13Yang paket core namanya, yang tengah-tengah lah

1:18Yang paling murah lah ya, iya kan

1:21Terus nggak lama setelah dapet sponsor

1:25Harganya naik

1:27Harganya naik dulu

1:28Tadinya bukan segitu

1:30Harganya naik, abis itu

1:32Begitu udah upgrade ke yang core

1:35Nggak baca kan target streamingnya bisa hanya dibatasi 2

1:42Bikin lah linkin

1:45X nggak bisa, karena harus premium kan

1:47Akhirnya Twitch

1:48Jadi 3, langsung otomatis naik ke Pro

1:5313 juta

1:55Setahun

1:57Abis itu langsung kaget kan dapet tagian

2:01Kok segi ini, turunin lagi

2:04Ternyata turuninnya juga nggak dapat uang kemali

2:07Tapi dalam bentuk

2:09Ini tarifan cerita ya, tarifan

2:11Iya, tarifan nggak bisa dikasih credit

2:14Jadi ya kita bertahan 2 tahun ke depan menggunakan stream ya

2:18Itulah suka dukanya podcast

2:23Gak melulu, suka melulu ya

2:26Ada jebakan-jebakan

2:28Iya, apa namanya

2:30Uang sponsornya jadi nggak cukup

2:32Harus cari sponsor lagi kita

2:34Ngomongin sponsor ya

2:38Seperti biasa malam hari ini sudah episode ke yang ke berapa ya

2:41134

2:43Dan episode ke 5 atau ke 6 ya sama Domensia

2:48Jadi kita kolaborasi sama Domensia

2:51Nah yang beda adalah kita dapat ini baru

2:55Kita menerima apa namanya

2:59Feedback dari teman-teman

3:02VPS, jadi sekarang

3:06Teman-teman kalau mau langganan atau mau nyobain VPSnya Domensia bisa

3:10Pakai promo code ngobrolin VPS DN

3:16Jadi bisa nyobain virtual private server ya atau VM lah ya

3:22Buat deploy-deploy termasuk nyobain database

3:26Database bisa di VM juga

3:28Promo-nya ini 50%

3:31Sekali pakai aja untuk pembelian baru

3:34Bisa untuk Cloud VPS Turbo

3:38Untuk semua paket

3:40Tidak berlaku untuk Cloud VPS Eco

3:44Kalau Eco ini berarti kayaknya ekonomis ya

3:46Kalau Turbo itu yang paling kencang ya

3:48Nebak-nebak doang

3:50Terima kasih soalnya

3:52Kita coba

3:54Amin Mas Yudi semoga dapat sponsor lagi

3:56Halo

3:58Mas Arif juga dari LinkedIn

4:02Ada Mas Doni

4:04Ada Mas Doni dari Youtube

4:08Ngomong-ngomong soal

4:10Sudah habis

4:12Jadi kita mendatangkan Nara Sumber Langganan ya

4:14Udah berapa kali ya Mas Doni?

4:16Udah berapa kali? Tiga kali ya

4:18Tiga kali

4:20Terima kasih banyak

4:22Udah menyempatkan waktunya

4:26Gimana sekarang?

4:30Lagi sibuk apa Mas?

4:32Lagi banyak speaker-speaker ya

4:34Habis dari Pontianak tadi ceritanya

4:38Ya tadi

4:40Habis pulang dari Pontianak sebenernya

4:42Subuh tadi

4:44Oh tadi pagi

4:46Tadi pagi

4:48Kita ada kesempatan untuk ngisi

4:50Mengenalkan AI ya

4:52Di salah satu event

4:54Adobe US

4:56Kebetulan waktu itu

4:58Diundangnya di Universitas Tanjung Pura Pontianak

5:00Di sana

5:02Jadi membantu untuk memberikan

5:04Perspektif bagaimana

5:06Untuk bisa menggunakan AI

5:08Untuk social impact di sana

5:10Gak melibir ke IKN

5:12Sekalian

5:14Jauh Mas

5:16Siapa tahu

5:20Aku tadi mikirnya sampai Pontianak

5:22Berarti ngajarinya di IKN ini

5:24Itu kayaknya

5:26Kalau diundang di IKN itu

5:28Mix feeling ya

5:30Bisa lihat itu

5:32Bisa lihat tugular yang ipsum loh

5:34Tugular yang ipsum itu

5:36Nggak tahu gimana

5:38Tugu placeholder

5:40Masih loading

5:42Terus gimana

5:46Animo

5:48Teman-teman yang

5:50Penonton di sana

5:52Terhadap perkembangan AI

5:54Mereka menggunakannya itu sudah sejauh mana sih

5:56Legal workshop ya

5:58Di sana

6:00Yang ditargetkan itu sebenernya

6:02Malah bukan yang punya background

6:04Teknik informatika

6:06Atau IT

6:08Tapi yang ikut itu kayak

6:10HI

6:12Kemudian ilmu komunikasi

6:14Di sana

6:16Wokshopnya tentang apa

6:18Wokshopnya itu tentang

6:20Yang pertama itu adalah

6:22Bagaimana perspektif dari penggunaan AI

6:24Dalam kehidupan saya

6:26Yang pertama, yang kedua itu

6:28Pengenalan sederhana machine learning

6:30Pake teachable machine

6:32Oh

6:34Oke, jadi bukan hanya penggunaan

6:36Chat

6:38Transfer learning maksudnya

6:40Transfer learning, oh bukan

6:42Teachable machine itu

6:44Adalah produk dari Google

6:46Yang dimana kita bisa melatih

6:48Machine learning

6:50Hanya menggunakan browser

6:52Di sana

6:54Yang tensorflow.js itu bukan kan

6:56Yang bisa dieksport

6:58Ke tensorflow.js

7:00Oh iya iya

7:02Waktu itu sempat dengar

7:04Waktu masih main sama tensorflow.js

7:06Udah lama sih

7:082018

7:102018

7:12Waktu baru-baru

7:14Baru muncul

7:16Iya lagi height

7:18Oke menarik menarik menarik

7:20Ya, jadi malam ini

7:22Kita akan bahas tentang

7:24Scaling database, ini adalah topik

7:26Diminta oleh Mas Triad Moko

7:28Di github

7:30Discussion kita

7:32Iya, udah lama

7:34Mintanya dari April

7:36Tahun lalu

7:38Tahun lalu lagi

7:40April nya bukan April tahun ini

7:42April nya tahun lalu

7:44Yang minta dibahas tentang database scaling

7:46Nah, saya ingat pas

7:48Mas Donny sempat sharing

7:50Cukup banyak kan ya di ex ya

7:52Di twitter, tentang database kan

7:54Kayak best practice

7:56Wah ini kayaknya cocok nih, dicolek aja

7:58Ternyata gayung bersambut

8:00Jadi malam hari ini kita akan bahas

8:02Apa sih bedanya

8:04Horizontal scaling sama vertical scaling

8:06Secara gampangnya dulu, gak usah dalam

8:08Kalau vertical itu

8:10Menambahkan

8:12Spesifikasi dari

8:14Misalkan 2 CPU ke 4 CPU

8:16Jadi nambah

8:18Upgrade

8:20Upgrade device

8:22Kalau horizontal itu menambahkan

8:24Device

8:26Open dengan spek yang sama

8:28Untuk bisa membagi

8:30Cluster

8:32Oh replication

8:34Replication lebih tepat

8:36Oke

8:38Oke

8:42Oke kalau gitu, kita mulai

8:44Dari mana, kalau misalkan

8:46Apa

8:48Nah ini pertanyaan penting

8:50Yang pertama

8:52Kenapa topik database ini penting

8:54Oke

8:58Kalau ada yang kemarin minta ya di githubnya

9:00Itu githubnya Mas Riza ya

9:02Githubnya ngobrolin web

9:04Githubnya ngobrolin web

9:06Nah kalau kita

9:08Dari pertanyaan itu, oh minta dong

9:10Bagaimana pembahasan replikasi dari

9:12Radical punggung horizontal

9:14Sebenernya kalau kita ngomong

9:16Pentingnya dimana, itu adalah

9:18Di back-end, di sisi back-end

9:20Kebanyakan kita itu akan

9:22Selalu berinteraksi dengan database

9:24Di sana

9:26Dan biasanya bottleneck aplikasi

9:28Itu bukan di bahasa

9:30Pemogramannya

9:32Hmm, selalu database pasti ya

9:34Puslim itu database disana

9:36Katakanlah sederhananya

9:38Pakai

9:40JavaScript, Node.js

9:42Atau pakai Rails, pakai PHP

9:44Gitu kan

9:46Atau pakai Rust, gitu ya

9:48Pakai Rust, pakai Zig

9:50Yang blazingly flash

9:52Blazingly fast

9:54Iya blazingly fast, gitu kan ya

9:56Terus 100x kecepatannya

9:58Tetapi in the end, kalau misalnya

10:00Dia terkoneksi dengan database

10:02Dan database itu

10:04Pembutuhkan waktu 5 detik

10:06Untuk memproses, mau pakai

10:08Rust, mau pakai Laravel

10:10Tetap aja 5 detik ya

10:12Ya, 5 detik plus sekian

10:14Disana

10:16Sehingga pemahaman-pemahaman kita

10:18Mengendal kapasitas

10:20Dan skalabilitas dari database

10:22Itu jadi menarik

10:24Penting

10:26Itu kayak never ends

10:28Pembahasannya, dan sangat luas sekali

10:30Ya, oke

10:34Yang paling sering bikin

10:36Lambat itu apa sih biasanya

10:38Query, load

10:40Atau IO

10:42Apa semua

10:44Sebenernya

10:46Kalau kita mau

10:48Apa sih yang membuat lambat, gitu kan

10:50Yang membuat lambat itu

10:52Sebenernya adalah bagaimana

10:54Kita mengakses data ini, gitu kan

10:56Kalau kita ketahui

10:58Database itu adalah

11:00Banyak struktur data yang

11:02Digunakan untuk kita menyimpan data

11:04Dan data itu disimpan di dalam storage

11:06Bayangin dulu jamannya kita ya

11:08Jamannya kita, tahun 2000an

11:10Itu kan SST belum

11:12Belum secepat sekarang

11:14Belum murah sekarang, dan belum semurah sekarang

11:16Murah dan cepat sekarang

11:18Disana, sehingga kerasa itu

11:20Bottle lag nya untuk menang sesetengah itu

11:22Dan RDBMS

11:24Data business ini adalah

11:26Most of the time ada RDBMS

11:28Relational Data Management System

11:30Jadi MySQL, Postgres

11:32Dan Oracle

11:34Atau apapun itu yang berbayar

11:36Itu mereka pasti akan

11:38Ada tabel-tabel

11:40Yang berrelasi satu dengan yang lainnya

11:42Ketika berrelasi

11:44Berarti kita harus menggabungkan

11:46Menjoin tabel-tabel tersebut

11:48Nah, ketika kita melakukan join

11:50Itulah kalau kita tidak

11:52Carefully mengatur

11:54Desain dari data business itu

11:56Maka proses pencarian datanya

11:58Akan menjadi lambat

12:00Disana

12:02Jadi yang membuat lambat itu

12:04Adalah skema nya

12:06Dan cara kita mengambil

12:08Datanya

12:10Query

12:12Plus seberapa besar data

12:14Tersebut

12:16Mungkin dalam tabel bisa giga-giga

12:18An gitu ya

12:20Terapai kalau yang udah di level

12:22Besar sekali

12:24Disana, itu berpengaruh

12:26Oke

12:28Kalau ngomongin

12:30Query

12:32Berarti ada pengaruh

12:34Penggunaan ORM juga dong ya

12:36Oh, itu yang

12:38Kayaknya rame ya

12:40Rame ya

12:42Kita bahas

12:44Di

12:46Di forum

12:48Dan di kalangan

12:50Ada tim puris ya

12:52Tim puris SKLRO

12:54Ada yang tim apatis

12:56Tim ORM

12:58Tidak ada yang lebih baik

13:00Tapi itu tergantung kondisi dan konteks

13:02Iya

13:04Kita juga semua ORM

13:06Itu support

13:08raw SKL kan ya

13:10Harusnya iya

13:12Jadi ORM itu sebenarnya

13:14Gak ini ya

13:16Bukan sesuatu yang

13:18Sangat support gitu

13:20Bahkan mereka itu bisa

13:22Dan raw query

13:24Kalau misalkan ada masalah

13:26Kalau kita pakai ORMnya langsung

13:28Kita mau lebih efisien itu sebenarnya

13:30Bisa tuh

13:32Pakai raw query

13:34Bagi penonton yang berasal dari

13:36Dunia front-end

13:38Kalau database query itu

13:40Antara

13:42Query langsung atau ORM

13:44Itu sama dengan main CSS

13:46CSS vanilla

13:48Pake tailwind

13:50Ya itu lah

13:52Perbandingan apple to apple nya

13:54Iya itu

13:56Analogi yang bisa dipahami ya

13:58Iya

14:00Khusus penonton nanti yang

14:02Ini orang front-end apa ya

14:04Kalau tailwind kayaknya masih

14:08Agak low level ya

14:10Kurang lebih lah begitulah ya

14:12ORM itu object

14:14Relational mapper

14:16Dan

14:18Mungkin ada

14:20Beberapa istilah

14:22Juga

14:24Kalau kita mau berinteraksi

14:26Dengan database maksudnya

14:28Aplikasi atau kode kita mau berinteraksi

14:30Dengan database

14:32Maksudnya

14:34Kalau pakai ORM kan gampang

14:36Bisa koneksi

14:38Terus bisa query pakai

14:40API atau SDK nya dia

14:42Masing-masing ya

14:44Mau pakai drizzle atau pakai

14:46Action

14:48Action apa

14:50Kalau rails lupa namanya pokoknya

14:52Semua ORM ya

14:54Terus

14:56Juga sebenernya

14:58Ada library yang

15:00Di tengah-tengah namanya itu

15:02Query builder

15:04Kalau di node.js itu namanya ada

15:06Dulu ya gak tau sekarang ya ada namanya

15:08Next.js k-n-e-x

15:10Nah itu dia hanya

15:12Hanya membuat

15:14Query aja

15:16Jadi dia

15:18Tidak

15:20Tidak merelasikan antara

15:22Object oriented ya

15:24Object oriented programming dengan

15:26Table atau

15:28Di database gitu jadi dia hanya query

15:30Builder aja

15:32Tapi pengalaman ya

15:34Misalnya kalau bagi kita yang bisa

15:36Langsung SQL query

15:38Dan

15:40Diketemukan sama orang yang

15:42Gak pernah menentu database

15:44Dan taunya hanya main di front-end

15:46Memang susah memahami

15:48Memahami SQL

15:50Query itu loh

15:52Karena harus paham matematika

15:54Dan

15:56Paham itu kan diagram

15:58Dan segala macam kan diagram

16:00Oh join-join

16:02Join-join dan grouping

16:04Itu sebenernya

16:06Kalau

16:08Pada namanya konsep berpikirnya

16:10Sangat berbeda

16:12Untuk lakukan SQL query

16:14Kalau dari sisi

16:16Seberang ya bukan susah

16:18Menjago backend tapi sisi seberang

16:20Itu sulit loh

16:22Karena beda konsep berpikir

16:24Makanya adalah ORM untuk

16:28Mempermudah hip

16:30Tapi dulu saya waktu awal

16:32Awal karir banget

16:34Itu sempat

16:36Ditandemin dengan ada role yang namanya

16:38DBA database administrator

16:40Memang masih ada sampai sekarang

16:42Dia yang bikinin query kita tinggal

16:44Minta doang

16:46Nanti dia bikinin viewsnya kita tinggal

16:48Tinggal select

16:50Tinggal select dari view yang dia buat ya

16:52Enggak select malah udah dikasih

16:54Kayak snippet-snippetnya ini untuk select ini untuk insert

16:56Ini untuk apa gitu

16:58Udah disediain jadi enak banget

17:00Merasa dimanjakan

17:02Gitu

17:04Karena view beda lagi

17:06View itu bisa bikin subset dari table

17:08Betul-betul jadi dia bikinin

17:10Khusus misalkan oh saya mau join

17:12Table ini sama table ini namanya table student

17:14Mungkin subjek gitu ya

17:16Dia bikinin itu view student subjek

17:18Jadi kita gak perlu join

17:20Kayaknya sekarang role nya udah gak ada ya

17:24Atau mungkin role untuk itu

17:26Tapi DBA masih

17:28DBA masih

17:30Kalau yang enterprise itu

17:32DBA itu penting

17:34Karena urusannya

17:36Itu tadi scaling

17:38Scaling

17:40Replication

17:42Backup

17:44Restore disaster recovery

17:46Semua kayaknya penting deh

17:48Tugas DBA itu

17:50Orang

17:52Di dunia modern ini mulai jarang

17:54Mencari DBA

17:56Pada akhirnya kemampuan

17:58Ini itu dibebankan ke temen-temen

18:00Devops, SRI

18:02Dulu Devops, SRI

18:06Padahal itu kayak

18:10Ada art

18:12And science nya sendiri

18:14Aku coba untuk belajar

18:16Database internalnya tuh

18:18Even kayak

18:20How it works itu aku harus tahu

18:22Tentang tree

18:24Tree base data structure gitu

18:26Bagaimana parser dari SKL

18:28Dari kita ngeparser

18:30SKL query supaya jadi execution

18:32Disana itu kayak

18:34Bisa satu semester sendiri

18:36Itu membahas itu semua

18:38Oke

18:40Kalau gitu kita omongin

18:42Gimana caranya

18:44How to start

18:46Gimana mulai untuk

18:48Misalkan udah punya

18:50Database nya

18:52Untuk optimize nya itu mulai dari mana

18:54Mungkin ini berhubungan

18:56Ini ya introdasinya ada

18:58Salah satu pertanyaan di youtube ya

19:00Mas tabel saya pas SKLnya ukurannya

19:02Kurang lebih 300 giga tuh

19:06Mereka nyoba tambah index

19:08Solusinya terbagi gimana

19:12Jadi ini ada step by step

19:14Ya untuk kita mengetahui

19:16Dan nanti

19:18Akan semakin kompleks

19:20Bagaimana kita bisa

19:22Optimize nya

19:24Yang pertama ketika kita mengetahui adanya

19:26Kelambatan dari aplikasi kita

19:28Itu terkadang majoritas

19:30Di Indonesia atau di perusahaan

19:32Indonesia itu belum punya

19:34Monitoring atau observability yang

19:36Cukup oke

19:38Untuk bisa mengetahui blockways

19:40Bagaimana

19:42Jadi definisi lambat itu

19:44Harus ditentukan tidak semua

19:46Proses lambat kan

19:48Misalnya kalau ada select

19:50Select data limit 5

19:52Itu kan enggak lambat

19:54Yang bikin lambat itu adalah query

19:56Yang beri impact ke

19:58Semuanya

20:00Berarti yang harus diketahui adalah

20:02Tahu enggak ada yang slow query

20:04Ini digunakan

20:06Yang namanya ada

20:08Observability tools

20:10Jadi kalau misalnya kamu kebetulan

20:12Kami di siruan group itu

20:14Expertisnya di Postgres ya

20:16Jadi apakah yang cerita dari Postgres

20:18Ada tabel

20:20Kalau pakai PSPL

20:22Aja itu ada tabel namanya

20:24PG stat statement

20:26PG statistic statement

20:28Gimana kita bisa tahu query yang

20:30Lambat

20:32Jadi kalau misalnya

20:34Mas data bisaya lambat

20:36Yang mana yang bikin lambat

20:38Jadi temukan dulu

20:40Querynya

20:42Yang lambat

20:44Atau kalau misalkan

20:46Ada yang punya Grafana

20:48Kalau ada yang pakai

20:50Kalau di Google ya, ada yang namanya Cloud SQL

20:52Itu ada beberapa

20:54Ada beberapa

20:56Metric yang kalian bisa access

20:58Slow query

21:00Itu bisa disediakan

21:02Jadi ada nggak tools

21:04MySQL, ada MySQL slow query kan

21:06Bisa dibuat locknya

21:08Ada

21:10MySQL bisa diaktifkan konfigurasi nya

21:12Untuk lock

21:14Slow query

21:16Nanti query yang lebih dari

21:18700 milliseconds

21:20Atau 1 second itu akan di lock

21:22Betul, disana

21:24Dan setiap engineer itu punya channel

21:26Bisa sendiri untuk mengetahui

21:28Bagaimana slow query itu

21:30Di sana

21:32Jalan Postgres sendiri itu

21:34Kalau kami, biasanya kami pakai

21:36Prometheus ya, untuk irim Metrics

21:38Ini mungkin agak sedikit detail

21:40Ke infra, tapi intinya adalah

21:42Gunakan tools yang mampu untuk bisa

21:44Mengakses statistiknya

21:46Even phm admin aku nggak tahu ya

21:48Phm admin itu ada nggak tools

21:50Untuk mengetahui itu

21:52Karena gpg admin

21:54Itu juga ada beberapa tools untuk

21:56View, jadi tabel itu bisa

21:58Diview di dalam GUI nya

22:00Sehingga GUI nya tahu bahwa ini

22:02Ada beberapa slow query

22:04Yang muncul disana

22:06Jadi itu dulu mas Jejen

22:08Yang pertama gitu kan

22:10Kita lanjutin yang kedua gitu kan

22:12Nah ketika ada

22:14Sudah tau nih, ada

22:16Top 5 gitu kan, top 5 atau top 10

22:18Kita bisa

22:20Investigate, mulai dengan

22:22Ada

22:24Ada salah satu SQL namanya

22:26Bila Explain Analyze

22:28Ini yang mungkin

22:30Jarang ya

22:32Diajarin di kampus juga

22:34Disana

22:36Dan

22:38Orang itu nggak ngah kalau ini tuh

22:40Ada fiturnya, jadi

22:42Explain Analyze

22:44Query

22:46Yang dimana, kalau mungkin

22:48Mas Riza bisa bantu

22:50Untuk mencari ya

22:52Disana

22:54Itu ada, bagaimana kita

22:56Tahu bahwa query tersebut

22:58Yang

23:00Ada atau image ya

23:02Untuk bisa melihat

23:04Repersentasi maksudnya apa

23:06Gak ada, kita cari yang

23:08Lain

23:10MySQL

23:12Reading

23:14Postgre Query Plan

23:16MySQL juga

23:18Punya tuh

23:20Itu kan yang di Postgre ya

23:22Jadi ada, mungkin yang ini aja

23:24Stop disini aja Mas Riza, yang ada hasil

23:26Plan

23:28Misalkan disitu kan

23:30Ada Explain Analyze

23:32Ada selectnya gitu kan ya

23:34From dari

23:36Dari tabel mana

23:38Ada filternya tuh disitu

23:40Nah

23:42Itu akan memberitahu bagaimana

23:44Kiranya, planningnya

23:46Eksekusi itu akan berjalan

23:48Disana, jadi disitu ada

23:50Beberapa

23:52Beberapa detail

23:54Bahwa

23:56Di dalam query itu akan melakukan sesuatu

23:58Di databasenya

24:00Dan

24:02Untuk memahami ini

24:04Itu kita harus belajar

24:06Bagaimana penyimpanan data

24:08Di dalam database, kalau kita

24:10Bisa lihat disitu yang

24:12Yang paling gampang aja, yang paling sering terjadi

24:14Kita nggak usah lihat

24:16Joint condition, total-total

24:18Harusnya ada total ini ya

24:20Ada planning, execution time itu

24:22Lapan, itu lapan

24:24Lapan millisecond

24:26Lapan ribu

24:28Lapan millisecond

24:30Ini koma ya

24:32Iya itu lapan millisecond

24:34Aku lupa bahasanya gimana

24:36Di disana, tapi

24:38Tapi intinya ini nanti akan

24:40Disitu ada salah satu kunci

24:42Namanya sequential scan

24:44Sequential scan disitu

24:48Berarti dia itu akan mencari

24:50Di seluruh data yang ada

24:52Di dalam data table tersebut

24:54Jadi worst case scenario-nya

24:56Berarti end ya

24:58End of data, disana untuk

25:00Menemukan disitu

25:02Dan itu yang kita

25:04Bisa lakukan adalah mengimprove bagaimana

25:06Logika

25:08Data itu disimpan dan ditemukan

25:10Kembali

25:12Jadi basicnya disini

25:14Pemahaman, pembacaan

25:16Explanation, planningnya

25:18Disana

25:20Jadi intinya sebenarnya

25:26Yang pertama adalah

25:28Di-measure ya

25:30Diukur, lambat itu seberapa lambat

25:32Cepat itu seberapa cepat

25:34Karena itu kan relatif ya

25:36Jadi bisa diukur pakai

25:38Apa namanya?

25:40PG-Stat

25:42Terus

25:46Habis itu bisa pakai

25:48Slow query juga kalau di MySQL

25:50Atau lewat APM

25:52Juga bisa kan kelihatan kan ya

25:54Bisa, bisa APM

25:56Tapi biasanya mayoritas

25:58Ini ya

26:00Maksudnya apa kan pekerjaannya

26:02Banyak menghandle

26:04Legacy code dari

26:06Legacy line

26:08Itu jarang punya APM yang bagus

26:10Biasanya

26:12Jadi

26:14Kalau nggak punya

26:16Apalagi kalau yang melihat ini

26:18Malah di luar gitu kan

26:20APM itu kan tidak apa-apa

26:22Disana

26:24Kita bisa langsung akses database-nya

26:26Kalau mau pakai

26:28De-beaver gitu ya

26:30Bisa juga

26:32Sayang-sayang

26:34Sayang-sayang aku udah lama nggak hands-on ya

26:36Jadi aku nggak bisa

26:38Nge-bisa demo-in

26:40Di sini, tapi intinya

26:42Kalian tuh bisa hanya menggunakan

26:44CLI doang untuk mengetahui

26:46Query mana yang lambat

26:48Disana

26:50Boleh mungkin di-spill

26:52Sedikit ya, APM yang bagus itu

26:54Standarnya Mas Donny apa sih?

26:56APM yang bagus adalah

27:00Tergantung budget

27:02APM itu mahal ya

27:04New Relic

27:06Iya, New Relic

27:08Iya, New Relic

27:10Tapi mahal

27:12Kalau punya budget New Relic

27:14Data drop ya

27:16Data drop juga mahal

27:18Tapi kalau mau tahu

27:20Zero One Group pakai apa

27:22Prometheus ganti dashboardnya

27:24Di Grafana

27:26Tapi kami lagi main ekspor namanya

27:28Prometheus

27:30Back-endnya Elastic Stress

27:32Kenapa?

27:34Prometheus back-endnya

27:36Prometheus itu

27:38Stack yang berbeda

27:40Kalau Elastic Stress itu LK

27:42Elastic Log Test

27:44Kibana

27:46Elastic sama Kibana

27:48Betul-betul

27:50Kalau yang Grafana itu biasanya LGTM

27:52Loki

27:54Grafana Tempo

27:56Mimian

27:58Open Source Solution

28:00Kalau misalnya ya

28:06Enterprise, on-premise

28:08Gak perlulah

28:10Kamu bisa akses sendiri lah database

28:12Query gitu

28:16Langsung SSA

28:20Langsung masuk ke ini ya

28:22Atau database-nya di-dump dulu

28:24Coba-coba di lokal gitu ya

28:26Jadi kalau mau start gitu

28:28Kalau mau pakai APM

28:30Kami pakai LGTM

28:32Dan kami lagi eksporasi Cygnos namanya

28:34Cygnos, oke

28:36Sentry mahal by the way

28:38Apa mahal?

28:40Sentry

28:42Sentry mahal ya

28:44Mahal untuk di-running self-host

28:46Jadi dia butuh 4 CPU

28:484 CPU

28:506 dan 3

28:52Oh yang self-hostednya ya

28:54Ya, tapi untuk buat start up itu ya murah-murah aja

28:58Tapi dia juga startnya udah yang 4 CPU juga gak murah kan ya

29:05Kalau dihitung per bulannya lumayan ya

29:07Oh iya, lumayan

29:09Jadi makanya APM apa yang paling terbaik tergantung budget

29:12Semakin mahal semakin baik

29:16Ya maksudnya kan tadi

29:18Menyebutin APM-nya kurang gitu kan

29:21Ternyata memang, berarti budgetnya memang kurang

29:25Nah ini Nur Holid ini mantep nih

29:29Sering pakai explain analyze semenjak ada isu query

29:31Ternyata karena order by

29:33Kalau short order dari join gak pake indexing

29:37Ya dia sekuensial

29:39Jadi mungkin kasih gembaran umum ya

29:42Sena yang tadi kan bahwa

29:44Ketika kalian anak back-end itu

29:46Akan sangat bermanfaat

29:48Menginvestasikan waktunya bagi mana tetap sepekerja

29:50Di sana

29:52Nah proses indexing itu adalah

29:54Sebenernya adalah membagi pencarian

29:56Dengan melalui struktur data tree

29:58Gitu

30:00Jadi kita tidak perlu menge-scan semuanya

30:02Data yang ada

30:04Ada yang paling populer itu adalah

30:06B-tree namanya

30:08B-tree index

30:10Di situ yang secara umum sering digunakan

30:12Jadi kalau

30:14Kalau tidak di indexing gitu kan ya

30:16Dia akan langsung nge-scan semua

30:18Yang tadi aku bilang di awal

30:20Nge-scan semua row untuk mencari data

30:22Di sana

30:24Dan itu bisa kayak

30:2610-100x ini

30:28Waktunya

30:30Even seribu

30:32Untuk bisa nyari data

30:34Di situ

30:36Iya

30:40Perlu ya apa

30:42Harus belajar big o notation

30:44Big o notation ya

30:46Analytics good

30:48Analytics good

30:50Analytics good

30:52Sering juga

30:54Karena

30:56Keburu terekspos dengan

30:58Banyak best practice

31:00Kalau database lambat

31:02Tambahin aja indexnya

31:04Index itu kan kalau analoginya

31:06Kayak apa ya? Kayak buku gitu ya

31:08Buku ini lah

31:10Yellow Pages ada yang ngalamin ga sih?

31:12Contact deh

31:14Sebenernya kayak

31:16Sebenernya kayak liat

31:18Kalau kita ngomong

31:20Kalau kita ngomong

31:22Kamu kayaknya terlalu

31:24Marketnya generasi

31:26Yang lebih muda kayaknya ga pernah

31:28Pilih-pilih baju

31:30Daftar isi

31:34Daftar isi tebel o konten

31:36Nah itu

31:38Ini

31:40Langsung gue tunjukin nih

31:42Ini butuh

31:44Buku manual mobil saya

31:46Terus kan isinya

31:48Banyak banget ya kan

31:50Gak mungkin saya baca satu-satu

31:52Yang mau saya cek dimana

31:54Tentu

31:56Kalau index di database itu

31:58Ya langsung saya langsung ke daftar isi

32:00Disini, oh masalah Oli

32:02Halaman sekian

32:04Bukan, daftar isi di depan

32:06Biasanya index di belakang, bener ga sih?

32:08Kalau buku ya

32:10Kalau buku definition indexnya beda

32:12Ya definition indexnya beda

32:14Kalau kayak ini aja lah

32:16Oh ya daftar isi, daftar isi di depan

32:18Kalau

32:20Di belakang itu index

32:22Index untuk kata-kata kan

32:24Ya

32:26Kalau yang di database itu index ini

32:28Index begini, bukan daftar isi

32:30Betul, jadi kayak apa ya

32:32Contact book lah, contact book

32:34Kalau misalkan saya mau cari

32:36Atau Mas Donny mau cari Riza kan

32:38Saya harus scroll dari A sampai R

32:40Dulu kan

32:42Jadi pencet aja huruf R

32:44Nah baru cari Riza, deket

32:46Kalau saya kan tinggal pake "Hi Google

32:48Call Riza"

32:50Woi woi woi

32:52Ini analogi digital ya

32:54Mau ngeluarin yellow pages

32:58Sudah ga punya

33:00Jadi contact book aja

33:02Gitu lah ya

33:04Dan kalau index

33:06Ini di apa ya

33:08Semuanya di index

33:10Ya jadinya sama aja

33:12Balik lagi kayak kita baca buku satu halaman

33:14Satu halaman gitu

33:16Jadi harus diperhatikan juga

33:18Jadi tidak

33:20Semua solusi adalah menambahkan index

33:22Sebenernya karena sebenernya

33:24Kalau kita lihat

33:26Kalau kita menambahkan indexnya lebih banyak

33:28Berarti ketika proses data itu dimasukkan

33:30Itu juga harus memasukkan indexnya juga

33:32Pada waktu itu

33:34Dan itu adalah rate performance

33:36Rate data base nya

33:38Bayangkan

33:40Kalau misalnya itu data

33:42Itu sering banget diisi

33:44Let's say tablet transaksi ya

33:46Yang dihajar banyak

33:48Itu jadinya bisa lebih lama banget

33:50Jadi kita harus punya ini ya

33:52Semua itu trade off ya

33:54Semua itu trade off

33:56Tidak ada solusi ini

33:58Silver bullet

34:00Dan kebanyakan index

34:02Storage nya membengkak

34:04Overhead

34:06Karena index itu kan perlu disimpen

34:08Dalam bentuk pointer

34:10Bahasanya sih pointer

34:12Menuju datanya di raw mana

34:14Jadi kita simpen

34:16Indexnya itu disimpen lagi

34:18Di table pointer

34:20Dan pointer itu memakan space

34:22Kalau data base nya membengkak

34:24Storage kita membengkak juga

34:26Jadi ada

34:28Trade off juga

34:30Yang bakal kita bahas

34:32Kalau sudah mandek disini

34:34Kita next step nya

34:36Lanjut

34:38Jadi next step nya

34:40Setelah katakan lagi

34:42Udah nih kita

34:44Udah oke nih mas

34:46Query nya udah

34:48Udah kita improve

34:50Udah kita kasih index

34:52Disana

34:54Yang dilihat dari level coding nya lagi

34:56Teman-teman disini pakai connection pooling apa enggak

34:58Disana

35:00Connection pooling itu

35:02Ketika kita melakukan connection

35:04Kedalam setelah database itu kan butuh

35:06Membuka connection

35:08Ada shake hand

35:10Ketika sudah dipakai

35:12Connection itu diputus

35:14Bayangin kalau kalian pakai connection pooling itu akan jadi terus-terusan

35:16Contoh analogi nya

35:18Karena kita selalu membahas analogi

35:20Analog analogi nya itu kayak

35:22Kamu parkir sendiri

35:24Mobil kamu

35:26Masuk ke parkiran

35:28Cari yang kosong gitu kan ya

35:30Terus keluar dan super market

35:32Nah connection pooling ini namanya pool ya

35:34Jadi mengumpulkan connection itu kayak

35:36Avali sebenarnya

35:38Jadi kita enggak

35:40Ini kita menggunakan

35:42Satu

35:44Meja yang sama gitu kan ya

35:46Untuk menaruh parkiran kita sederhananya gitu

35:48Jadi connection

35:50Yang kita gunakan untuk membuka

35:52Database

35:54Itu akan direuse untuk

35:56Request yang lain

35:58Jadi kita buka

36:00Connection

36:02Itu juga ada art

36:04Sama science nya sendiri

36:06Karena

36:08Gak bisa dibuka terus

36:10Connection itu bergantung pada RAM

36:12Bergantung pada RAM

36:14Satu connection itu

36:16Mungkin 25 MB

36:18Dan berapa aplikasi

36:20Yang kalian buka gitu kan ya

36:22Kalau misalnya aplikasinya

36:24Ini ya, pakai kube

36:26Horizontal scale, berarti

36:28Kamu harus maintain, kamu harus hitung

36:30Berapa connection pooling yang

36:32Bagus

36:34Kalau misalnya pakai container kan

36:36Container kan bisa

36:3810 kan

36:40Buka connection ke database

36:42Yang sama database nya kan

36:44Gak mungkin, gak banyak juga kan

36:46Jadi kalau misalnya

36:48Container nge scale, jadi dari 10

36:50Ke 100, kalau dia pooling

36:52Mulu, ya misalnya

36:54Masimal tadinya cuma bisa 10 pooling

36:56Ya yang lain bottleneck, nunggu

36:58Tunggu yang satu dimatikan dulu

37:00Dia baru bisa buka lagi

37:02Jadi bottleneck di

37:04Connection

37:06Jadi bukan database nya yang lambat, tetapi

37:08Jalurnya

37:10Yang penuh

37:12Jalurnya yang penuh, jadi tidak hanya database nya

37:14Harus dipikirkan bagaimana kita perinteraksi

37:16Dengan database nya

37:18Salusinya adalah

37:20Ada hitung-hitungan sederhananya

37:22Sebenarnya

37:24Kamu mau pasang

37:26Container berapa

37:28Kamu mau pasang

37:30Kalau kita ngomong ini ya

37:32Kalau kita ngomong

37:34Efficient untuk kita

37:36Bisa menggunakan RAM nya itu

37:38Kita ada hitungan kasarlah

37:40Karena

37:42Ini pengalamanku

37:44Mengerjakan software project di Indonesia ya

37:46Itu tidak

37:48Sampai ke scale nya unicorn

37:50Yang banyak banget

37:52Itu

37:54Kayak

37:56Kebanyakan database yang

37:58For CPU 8GB

38:00Setiap ada

38:02Satu container

38:04Satu container itu bisa buka berapa

38:06Connection itu sebenarnya kita bisa hitung

38:08Di situ, jadi bukan

38:10Kalau misalkan ada database tau-tau

38:12Aku pake kube supaya bisa handle banyak request

38:14Belum tentu

38:16Engga juga

38:18Engga auto scaling tapi koneksinya

38:20Di database nya

38:22Engga cukup gitu kan ya

38:24Anri pada akhirnya

38:26Kayak jalan raya

38:28Ya mobilnya banyak

38:30Tapi jalannya sedikit atau kecil

38:32Jadi ngantri tetap ngantri ya

38:34Terus terakhir dari

38:36Sepenceng apalah juga ya

38:38Terus terakhir

38:40Dari level code ya

38:42Kalau tadi kita udah bahas sedikit

38:44ORM

38:46Kita tau misalnya

38:48Ada LF1

38:50Terus active record

38:52Yang jahat

38:54Prisma ya

38:56Prisma drizzle

38:58Type ORM

39:00Terus sedikit terakhir ya

39:02Perkara ORM ya

39:04Dulu itu pernah maintain salah satu

39:06Salah satu agensi

39:08Yang trading edge ya

39:10Di enterprise

39:12Prisma versi 1

39:16Prisma engine nya masih pake skala

39:18Skala?

39:20Dulu itu Prisma

39:22Engine nya pake skala

39:24Versi 1 ya

39:26Dan itu

39:28Ada GitHub issue dibuka

39:30Salah satu caranya adalah migrasi ke versi 2

39:32Dan selalu out of memory

39:34Karena Java

39:38Karena JVM

39:40Jadi temen-temen yang

39:42Aku gak bilang kalian harus jago

39:44Ini ya SQL

39:46Karena juga tadi bener kata mas Ivan

39:48Frontend itu mungkin

39:50Tidak punya banyak waktu untuk bisa

39:52Mengerti semua yang terlihat kan

39:54ORM itu bisa mematuh

39:56Jadi sebenarnya ya gak ada salahnya

39:58Juga pake ORM

40:00Kecuali kamu di mata purist gitu kan ya

40:02Buat apa pake ORM

40:06Berlaku kebudakannya

40:08Ngapain gak mau nulis

40:10Gampang

40:14Gak produktif ya

40:16Gak produktif

40:18Yang penting ini aja sih

40:22Awareness kita tahu

40:24Kita pake ORM

40:26Jadi kalau terjadi kelambatan

40:28Kita coba cek disitu dulu

40:30Karena kita dari aplikasi

40:32Masih ada satu layer lagi

40:34Sebelum ke SQL

40:36Padahal SQL itu kan sudah layer untuk

40:38Komunikasi ke database kan

40:40Jadi ada satu layer

40:42Di atas SQL

40:44Query Vanilla

40:46Tapi ada sudut pandang yang berbeda nih

40:50Kalau Frontend, anak Frontend kan

40:52Sekarang udah terbiasa dengan

40:54Deklaratif kan

40:56Ngulis kodnya kan

40:58Deklaratif pake React lah

41:00Atau SwiftUI

41:02Sql itu kan deklaratif

41:04Jadi belajar juga harusnya lebih muda

41:06Ya mungkin belajar syntax baru

41:10Cuman kan

41:12Apalagi sekarang bisa dibantu AI

41:14Jadi mungkin cara

41:16Belajarnya sekarang jauh lebih

41:18Learning curve nya

41:20Lebih rendala dibandingkan dulu

41:22Sulit sih mas

41:26Maksudnya

41:28Saya bisa

41:30Belajar Tau SQL Query itu karena kuliah

41:32Dan saat kuliah itu

41:34Mata kuliah database itu

41:36Sampai kayaknya 2 semester deh

41:382 semester

41:40Basis data 1 sama

41:42Basis data 2

41:44Dan waktu itu

41:46Base nya Oracle

41:48Dan memang dari awal tuh

41:50Dari select, grouping, segala macem

41:52Dan nanti sudah yang basis data 2

41:54Itu lebih advanced lagi

41:56Kayak

41:58Stored procedure

42:00Fuse

42:02Itu sebenernya

42:04Banyak yang bisa

42:06Bisa didistribusikan

42:08Jadi gak perlu semuanya

42:10Di level aplikasi

42:12Stored procedure itu bisa

42:14Di level database kita bisa membuat

42:16Function nya kita sendiri

42:18Di database

42:20Jadi kita cuma tinggal panggil function itu doang sebenernya

42:22Itu bisa cuman

42:24Itu gak stored procedure saya yakin

42:26Di dunia

42:28Kalau kita

42:30Merujuk kepada dunia

42:32Frontend yang pengguna

42:34Next.js dan segala macem

42:36Pasti stored procedure itu bukan

42:38Sesuatu yang sering didengar

42:40Kalau yang sampai

42:42Yang susah juga

42:44Maintainan di dalam stored procedure nya susah

42:46Gak bisa masuk ke git lah

42:48Gitu kan susah kan

42:50Betul

42:52Dia nyantol

42:54Di database nya jadinya

42:56Jadi semuanya sekarang

42:58Semuanya di level aplikasi

43:00Dan database nya sekedar

43:02SQL query nya saja

43:04Untuk ambil dan transaksi data saja

43:06Tapi sebenernya

43:08Database is more than that

43:10Banyak lho

43:12Contoh

43:14Mungkin

43:16Kalau

43:18Melakukan

43:20Select distance misalnya

43:22Radius

43:24Kalau misalnya kita punya

43:26Mapping

43:28Lokasi warehouse

43:30Mana ya kita

43:32Mau

43:34Query jarak terdekat

43:36Dari

43:38Latitude

43:40Longitude ini

43:42Contohnya

43:44Kalau pakai

43:46Aplikasi

43:48Itu susah

43:50Misalnya kita harus query semua

43:52Warehouse

43:54Lalu pakai aplikasi untuk mencari

43:56Jarak terdekat dari latitude longitude

43:58Yang kita punya dari titik tengahnya kita

44:00Anggap aja kita punya ini ya

44:02Punya

44:04Franchise

44:06Dan punya banyak store

44:08Terus mau ditampilkan di Google Map

44:10Contohnya

44:12Terus kita mau cari

44:14Yang mana jarak terdekat dari

44:16Jakarta Barat misalnya

44:18Itu kan dia bisa

44:20Ngecari radius

44:22Kalau pakai aplikasi susah itu

44:24Tapi kalau pakai Postgres

44:26Itu tinggal select distance

44:28Postgres ya

44:30Postgres

44:32Dan bisa langsung sort by distance

44:34Gini ya

44:36Satu query

44:38Itu maksudnya

44:40Banyak hal-hal yang bisa

44:42Database itu bisa lakukan lho

44:46Yang lebih-lebih dalam

44:48Nah ini

44:52Menjawab tadi ya

44:54Rumus connection pool ya

44:56Sebenernya banyak rumus

44:58Spindles ini apa?

45:04Spindles itu

45:06Kalau misalkan

45:08Sebentar aku lagi

45:10Buka Google resource ya

45:12Di sana

45:14Jadi bisa

45:16Ada yang ngomong

45:18Ada yang ngitung itu dari CPU

45:20Ada yang ngitung dari

45:22Tadi kan aku bilang kayak satu buka connection itu

45:24Sekitar 25 megabit

45:26RAM di sana

45:28Referensi ku itu

45:30Mungkin lebih ke

45:32Cari coba cari referensi dari database engine

45:34Yang kalian pakai

45:36Yang aku ngomong RAM itu tadi

45:38Postgres

45:40Beberapa orang ngomong bahwa

45:42Ambil aja 25

45:44Ambil aja 1 connection pool adalah

45:46Di Prisma itu kayak

45:48Ngomong connection pool itu

45:50Dia ambilnya

45:52Ada CPUnya juga

45:54Di sana, hitungannya ada CPU juga

45:56Jadi menurutku kalau menjawab pertanyaan ini

45:58Coba cari database enginenya

46:00Kemudian coba cari beberapa

46:02Referensinya

46:04Aku nggak terlalu

46:06Ada hal yang sakit, karena aku kalau liat di Google

46:08Banyak banget referensi

46:10Connection poolnya

46:12Atau start default dulu deh

46:14Default itu jadi good starting point

46:18Nanti lihat pakai APM

46:20Baru nanti kita bisa lihat apakah connection poolnya itu

46:22Biasanya di APM itu

46:24Ada limit

46:26Connection biasanya

46:28Kita terlalu banyak pakai connectionnya apa nggak

46:30Masing-masing database berbeda ya

46:34Cara penanganannya ya

46:36Kita lanjut aja kali ya

46:38Kita ada beberapa tahap

46:40Di situ

46:42Nah setelah kita udah lihat nih dari keseluruhan

46:44Ternyata tidak masih bisa

46:46Mahendal, baru kita mulai untuk

46:48Bermain infrastructure di sana

46:50Yang paling populer

46:54Di selain scaling gitu ya

46:56Apakah database ini

46:58Punya kompetensi yang berat

47:00Alternatifnya adalah menambahkan layer

47:02Di atas database itu

47:06Adalah credits ya

47:08Caching, kemudian ada

47:10Gvalue store

47:12Yang bisa disimpan di ram biar lebih cepat

47:14Ada search engine

47:16Elastic search

47:18Melee search gitu kan ya untuk mencari data

47:20Ada messaging queue

47:22Jadi yang biasanya untuk

47:24Kayak Kafka

47:26Biasanya kalau data

47:28Rate-nya, call rate-nya tinggi

47:30Daripada kita harus dihajar

47:32Di satu endpoint gitu kan

47:34Kita kasih queue di sana supaya

47:36Lebih terproses dengan

47:38Berurutan

47:40Jadi writing-nya ngantri

47:42Ada queue-nya gitu ya

47:44Pake Kafka

47:46Atau Revit MQ

47:48Itu terserah lagi ya

47:50Terserah dengan familiaritas dengan

47:52Apa teknologi yang digunakan

47:54Mungkin quick lagi ya

47:56Setelah itu

47:58Ada technical scaling ya, itu udah deh

48:00Paling gampang udah

48:02Lakukan semua masih berat

48:04Naikin CPU sama

48:06RAM-nya

48:08Kenapa?

48:10Karena itu

48:12Kita masih bisa maintain dengan

48:14Ini tergantung seberapa besar tim infra-nya

48:16Atau tim monitoring-nya

48:18Paling gampang adalah naikin

48:20Kalau pakai clock enak ya

48:22Tapi kalau on-premise

48:24Kalau saya

48:26Kalau pakai on-premise

48:28Hybrid

48:30Kalau saya

48:32Cek dulu, ini hard disknya

48:34Pakai apa? Masih pakai piringan atau

48:36Itu cek dulu tuh

48:38Karena

48:40Kalau mau gimana pun

48:42Dinaikin, kalau masih piringan

48:44Tetep aja lambat

48:46Dan ini ada

48:48Beberapa pembahasan ya

48:50Salah satunya DHH itu adalah

48:52Yang bikin Rails ya

48:54Oh

48:56Anumayar Hansen

48:58Ya itu

49:00DHH

49:02DHH

49:04Dengan

49:06Kecepatan storage CPU itu

49:08Bahkan sekarang banyak perusahaan

49:10Besar itu masih bisa handle single note

49:12Tetap di sana

49:14Jadi vertical itu

49:16Jadi solusi disitu

49:18Ketika vertical sudah gak bisa gitu kan ya

49:20Terlepas dari budget dan kawan-kawan

49:22Muncul horizontal scale

49:24Yang paling gampang horizontal itu

49:26Bahkan read replica

49:28Jadi

49:30Ketika ada satu database

49:32Kamu bisa tambahkan database kedua

49:34Untuk hanya

49:36Mencari budget database

49:38Disitu

49:40Jadi ada write

49:42Write db

49:44Ada read db, kalau jaman dulu

49:46Yang bahasanya tidak

49:48Inclusive itu

49:50Ada master slave

49:52Jaman gue

49:54Jaman yang gak sudah inclusive

49:56Jadinya harus write sama

49:58Read

50:00Bisa primary replica atau worker manager

50:02Itu tergantung

50:04Ya

50:06Tapi horizontal

50:08Scale juga ada masalahnya juga gitu kan ya

50:10Horizontal scale itu

50:12Replikasi menambahkan

50:14Sesuatu

50:16Latensi

50:18Kemudian kalau misalnya kita membaca

50:20Tapi belum di replikasi

50:22Out of sync

50:24Delay

50:26Itu sudah busing

50:28Out of sync itu

50:30Itu adalah salah satu teori

50:32Yang kita sebut dengan cap theorem ya

50:34Cap theorem itu adalah

50:36Konsistensi, availability

50:38Ataupun partition

50:40Kita gak bisa dapatin ini semuanya

50:42Di sana, jadi kalau kamu mengejar

50:44Konsistensi, berarti ada masalah

50:46Availability, out of syncnya lebih

50:48Lebih ini, lebih

50:50Kerasa

50:52Tapi kalau katakanlah

50:54Ini apa contohnya

50:56Financial application

50:58Kan gak boleh itu misalnya

51:00Ngirim apa

51:02Ngirim uang

51:04Tapi waktu

51:06Orang baca lagi gitu kan ya

51:08Di request kedua kalinya, aku masih pakai saldo yang lama

51:10Bahaya ya

51:14Harus konsisten di semua replica yang ada

51:16Tapi itu berimpak

51:18Sehingga sampai availability

51:20Orang itu gak banyak bisa handle request

51:22Secara concurrent

51:24Availability yang diutamakan

51:26Konsistensi gak perlu

51:28Itu contohnya social media

51:30Kan gak perlu amat kamu harus melihat

51:32Exkut yang terbaru

51:34Terbaru

51:36Yang berubah

51:38Konsisten ke semuanya

51:40Gak harus

51:42Dan banyak tools ya

51:44Banyak tools yang

51:46Di gunakan

51:48Kalau di Postgres itu ada nama Patroni

51:50Patroni untuk bikin

51:54Streaming

51:56Blaster, Postgres

51:58Kalau di MySQL itu Vitesse

52:00Ataupun Proxy SQL

52:02Di sana

52:04Vitesse bukan Vitesse JS ya

52:06Bukan, bukan Vitesse

52:08Bukan Vitesse pakai buat view itu ya

52:10Bukan, bukan

52:12Intinya adalah dia itu

52:14Ada Proxy nya

52:16Yang Patroni itu intinya adalah

52:18Ada Proxy di depan database itu

52:20Yang dia nanti ngatur

52:22Oh ini adalah query read

52:24Dia yang mengatur

52:26Menatur jalannya

52:28Query, jadi di depan itu ada

52:30Load balancer namanya Haproxy

52:32Haproxy

52:34Haproxy

52:36Terus data

52:38Data key value store yang disimpan

52:40Dalam cluster itu pakai etcd

52:42Di sana

52:44Oke

52:46Kayaknya kalau ngomongin Load balancer

52:48Satu topik sendiri lagi kayak Load balancer

52:50Itu, itu

52:52Round-robin

52:54Ada banyak poin ya, algoritma

52:58List connection, layer

53:00Berapa Load balancernya

53:02Panjang ceritanya ya

53:06Jadi kalau

53:08Database vertical horizontal itu kan

53:10Harus ada Load balancernya kan

53:12Jadi yang ngatur

53:14Kan dari aplikasi koneksinya

53:16Cuma tau satu, tapi dari Proxy

53:18Yang ngatur mau ke database yang mana

53:20Yang mungkin cara jadulnya itu adalah

53:24Kalau misalnya tidak ada Load balancernya

53:26Di depan itu kayak

53:28Di dalam code nya ada dua koneksi

53:30Oh ini, ini yang buat

53:32Ada array, ada array

53:34Ngecek ini write apa write

53:36Jadi manual, itu pun bisa dilatukkan

53:38Di sana ya

53:40Jadi ya cuman bikin replika aja

53:42Kamu nggak ada Load balancernya di depan

53:44Itu masih bisa aja, tapi ya

53:46Ribet di aplikasinya

53:48Untuk handle itu ya

53:50Di sana

53:52Mungkin dua lagi tentang scaling ini

53:54Yang selanjutnya itu adalah partisi

53:56Jadi tabel yang gede banget misalkan

53:58Itu bisa dipartisi

54:00Jadi beberapa, kita memacah

54:02Kayaknya ada data structure lagi

54:06Ada 1TB itu kan tabel itu dibagi

54:08250GB supaya lookupnya

54:10Lebih gampang

54:12Di sana, dan yang terakhir

54:14Itu adalah sharding yang di mana

54:16Kita bagi tabel

54:18Semua tabel

54:20Di berbagai macam

54:22Notes

54:24Di server yang berbeda

54:26Itu lebih kompleks

54:28Tapi ada open source yang dibuat oleh Microsoft

54:30Untuk membantu mempermudah

54:32Sharding di Postgres namanya

54:34Cetus

54:36Cetus

54:38Gimana?

54:40Aku nggak tahu saya ngomongnya gimana nih

54:42Cetus, mi apa?

54:44Nggak ada yang relate lho

54:50Kita yang ketawa doang

54:52Last thing

54:56Perkara scalingnya

54:58Kalau kamu mau nggak berepot, ada yang namanya serverless

55:00Data base sekarang lagi rame

55:02Ini planet scale ya?

55:04Planet scale

55:06Planet scale

55:08Itu planet scale ya?

55:10Kalau di Postgres namanya neon

55:12Neon

55:14Jadi dia mau memisahkan

55:16Compute engine nya dengan storage nya

55:18Jadi itu

55:20Another things lagi

55:22Jadi itulah

55:24Sedikit ini ya, macem-macem

55:26Gimana kita bisa nge scale data base

55:28Iya, sempat penasaran juga

55:30Ini serverless data base ini

55:32Gimana kan? Sebelumnya kan kita

55:34Aplikasi yang serverless

55:36Ini data base juga serverless juga ya

55:38Yang diserverless

55:40Kan itulah secara teori

55:42Sederhananya adalah pemisahan

55:44Storage dengan compute nya

55:46Di sana

55:48Jadi

55:50Compute nya yang di scale

55:52Auto scale

55:54Compute nya yang di auto scale

55:56Compute nya yang di auto scale

55:58Di situ

56:00Secara dalam nya aku belum dalam lagi

56:02Tapi itu yang bisa membuat pada akhirnya

56:04Bisa serverless

56:06Jadi disana

56:08Oke

56:10Ini buat MySQL yang tadi neon buat

56:12Postgres ya

56:14Siap

56:16Mantap

56:18Itu untuk

56:20Serverless

56:22Tapi

56:24Dalam sampai tahap apa sih kita

56:26Perlu mendata base scaling

56:28Karena ada juga ide

56:30Kayak apa itu

56:32Situs besarnya masih pakai

56:34Eskialight

56:36Sanggup-sanggup aja gitu

56:38Discord ya

56:40Enggak salah eskialight ya

56:42Bukan

56:44Eskialight

56:46Enggak tahu ya apa ya

56:50Aku lupa

56:52Eskialight itu yang sebenarnya

56:54Unique selling point nya

56:56Adalah dia embedded kan

56:58Jadi yang paling banyak dipakai adalah

57:00Ya HP Android

57:02iOS ya

57:04Windows, HP, Handphone ya

57:06Itu eskialight semua kan

57:08Ya

57:10Tapi kalau untuk

57:12Product web

57:14Ini ada yang kayak aku share ke mana ya

57:16Share ke private chat

57:20Private chat

57:22Docs juga boleh

57:24Ada itu tuh

57:26Kayak berapa terah itu eskialight

57:28Yang mana yang mana

57:30Oh ini private chat ya

57:32Ada

57:386 terabyte

57:42Searchcode.com

57:44Searchcode.com

57:46Wow

57:48Gede loh itu

57:506 terabyte

57:52Nah kalau

57:54Eskialight itu gimana

57:56Gimana scalingnya

57:58Gak bisa

58:00Satu file kan

58:02Filebase kan

58:04Enggak usah

58:06Scaling nya dulu deh

58:08Deploy nya gimana kalau deploy

58:10Kalau pakai docker kan harus stateless kan

58:12Gak bisa ya

58:14Saya juga baru belajar kemarin harus pakai volumes

58:16Kalau kita ngomong mungkin aku secara detail

58:20Aku belum baca ini ya

58:22Bagaimana cara dia bisa ngasih scale sebesar

58:24Tapi kita coba untuk

58:26Apa sih benefitnya eskialight

58:28Daripada rdbms engine yang lain

58:30Ya boleh

58:32Jadi

58:34Jadi nilai tambah dari eskialight itu

58:38Adalah kemampuan untuk performance

58:40Query datanya itu sendiri

58:42Di sana

58:44Jauh lebih cepat dari

58:46Apapun rdbms engine yang ada

58:48Mau mysql, mau postgres

58:50Tetapi kurangnya dimana sih

58:52Kurangnya itu adalah

58:54Di dalam konkurensi

58:56User untuk akses database

58:58Asebut

59:00Karena tidak digunakan untuk

59:02Di akses dalam waktu yang bersamaan

59:04Database nya

59:06Di sana

59:08Makanya ada yang namanya Tursow ya

59:10Tursow

59:12Ada satu eskialight

59:14Kemudian direplikasi

59:16Di edge

59:18Untuk orang yang bisa

59:20Akses banyak

59:22Dia itu memanfaatkan

59:24Performance yang eskialight

59:26Kemudian cara yang nyebarnya gimana

59:28Direplikasi ke multiple edge

59:30Untuk bisa mematasi

59:32Sekian concurrent user

59:34Jadi sebenarnya benefitnya

59:36Eskialight itu disitu

59:38Dan banyak juga project-project

59:40Jadi tidak segede-gede apapun

59:42Kayak dashboard

59:44Itu kan banyak heavy di read ya

59:46Itu kita gunakan eskialight aja untuk

59:48Performance query datanya

59:50Kalau kita tidak di akses banyak orang

59:52Contoh ada satu project CMS

59:54Yang aku share di google docs

59:56Itu kan namanya PocketBase ya

59:58PocketGIS itu adalah siap

1:00:00Kayak eskialight

1:00:02Ya ya ya

1:00:04Pernah pake ini

1:00:06Pernah bahas ya

1:00:08Disitu

1:00:10Ini back-end nya go

1:00:12Terus dia kasih back office

1:00:14Kan kita bisa operasi bisa

1:00:16Insert data bisa

1:00:18Manipulasi bisa update bisa delete

1:00:20Kan ya. Terus ada

1:00:22Dia kasih rsapi nya ya

1:00:24Routes nya ya

1:00:26Betul disana dan itu pun

1:00:28Majoritas

1:00:30Mungkin orang itu cukup

1:00:32Disana untuk menggunakan eskialight

1:00:34Tapi jujur aku tidak pernah

1:00:36Melakukan komparasi

1:00:38Yang cukup komprehensif ya untuk bisa

1:00:40Berani berkata bahwa

1:00:42Ada sekala-sekala tertentu yang

1:00:44Kayak konkurensi kali ya

1:00:46Konkurensi

1:00:48Konkurensi akses

1:00:50Sebenernya

1:00:52Kalau misalnya

1:00:54Kita bikin aplikasi

1:00:56Yang dipake banyak orang kalau pake eskialight

1:00:58Mungkin bottleneck disaat read

1:01:00File nya karena dia file base kan

1:01:02Betul ya ya ya

1:01:04Sedangkan kalau

1:01:06Aplikasi yang personal

1:01:08Contohnya ya

1:01:10Misalnya mozilla thunderbird itu pake

1:01:12Eskialight

1:01:14Karena kan terisolate

1:01:16Satu user satu data

1:01:18Justru kalau pake mozilla thunderbird

1:01:20Pakainya install my eskialight lagi

1:01:22Ya susah ya kan

1:01:24Jadi efektnya pake eskialight

1:01:26Pocket base kan personal

1:01:28Atau

1:01:30Paling maksimal ya 4-5 orang

1:01:32Dalam keluarga doang kan

1:01:34Pake ini gitu

1:01:36Ya kalau misalnya

1:01:38Sudah di akses sama ratusan

1:01:40Ribuan secara

1:01:42Concurrent mungkin

1:01:44Harus pake DBMS

1:01:46Ada post read and read file nya itu

1:01:48Read and write file nya

1:01:50Yang jadi masalah

1:01:52Untuk local first juga cocok

1:01:54Mas Ari sih

1:01:56Orang dalem orang dalem

1:01:58By the way

1:02:00Ada satu kasus yang membuat

1:02:02Battle neck juga

1:02:04Kalau saat DBMS itu

1:02:06Sedang melakukan write operation

1:02:08Dia akan butuh

1:02:10Dia sedang ngerite ke table ya

1:02:12Ya blocking, dia akan blocking

1:02:14Kalau ngerite, dia akan

1:02:16Locking ya, bukan blocking

1:02:18Ada locking mekanisme kan

1:02:20Kalau satu process sedang

1:02:22Ngerite dan

1:02:24Ngerite plus

1:02:26Ngeindeks kan, jadi habis write dia

1:02:28Ngerite index, dan process itu

1:02:30Butuh waktu, nah kalau misalnya

1:02:32Ada concurrent yang sedang membaca

1:02:34Table itu di saat yang sama, dia akan

1:02:36Lock dulu, menunggu sampai process

1:02:38Write selesai, baru bisa dibaca

1:02:40Baru bisa diselect ceritanya

1:02:42Nah, ini

1:02:44Kita cerita bukan pakai cluster

1:02:46Yang ada read write

1:02:48Table ya, beda

1:02:50Satu database doang

1:02:52Ceritanya, ya itu akan terjadi

1:02:54Yang namanya locking mekanisme

1:02:56Dan karena ada locking

1:02:58Ya, kelihatannya

1:03:00Query kita yang

1:03:02Nge-select selanjutnya itu

1:03:04Kelamaan, tapi sebenarnya

1:03:06Kan nge-lock oleh

1:03:08Process yang sebelumnya

1:03:10Nah, itu bisa jadi pengalaman

1:03:12Pribadi

1:03:14Oh ya, itu sebenarnya kalau yang dibilangin

1:03:16Mas Ivan adalah

1:03:18Konsekensi dari mislifat

1:03:20DBMS yang menerapkan akit

1:03:22Mungkin kalau teman-teman

1:03:24Yang kuliah ya

1:03:26Dan aku selalu tanya

1:03:28Waktu skill test nya Zero One Group

1:03:30Kalau ada yang apply

1:03:34Di Zero One Group, itu selalu aku akan tanyakan

1:03:36Tau nggak akit itu apa

1:03:38Di sana

1:03:40Asem

1:03:42Jadi, akit itu adalah kepanjang dari

1:03:48Atomicity, konsistensi,

1:03:50Integrity, dan Durability

1:03:52Dan setiap engineer itu

1:03:54Punya caranya sendiri untuk menghandle ini

1:03:56Di dalam Postgres itu aku share

1:04:00Mas Riza di private chat

1:04:02Ataupun di Google Docs

1:04:04Ada yang HPG locks the query

1:04:06Mungkin kita lihat bareng-bareng

1:04:08Jadi, untuk menjaga

1:04:10Sebuah integritas dari sorto database

1:04:12Itu kadang-kadang kita harus nge-lock processnya

1:04:14Dan setiap query itu punya

1:04:16Skala lock nya masing-masing

1:04:18Di sana

1:04:20Di dalam ini

1:04:22Dia ngasih tau semua

1:04:24Impact dari

1:04:26Query kita itu apakah

1:04:28Table atau Room

1:04:30Di sana

1:04:32Jadi kadang-kadang

1:04:34Ini juga yang aku masalahin di beberapa project enterprise ya

1:04:36Karena kan query nya cukup jelimit

1:04:38Di sana

1:04:40Di dalam top 3 SQL itu bukan

1:04:42Yang bikin cool print

1:04:44Tapi adalah

1:04:46Impact dari locking

1:04:48Locking ini

1:04:50Nah itu ada

1:04:52Locking sendiri

1:04:54Jadi kita

1:04:56Di dalam Postgres itu ada

1:04:58Locking buat lock

1:05:00Jadi kita harus kayak

1:05:02Ini mana yang nge-lock

1:05:04Di sana

1:05:06Bisa di trace ya dari situ ya

1:05:08Di satu

1:05:10Nah locking ini lagi-lagi

1:05:12Untuk kita kadang-kadang

1:05:14Ada konsep namanya

1:05:16Seperti kayak

1:05:18Mau beli web ini, tapi di Seriwan Group kan punya live streaming juga

1:05:20Namanya Astro Office ya

1:05:22Itu waktu itu

1:05:24Salah satu engine Seriwan Group, Mbak Amel

1:05:26Itu bahas tentang ada

1:05:28Yang namanya bagaimana Postgres itu

1:05:30Menghandle integritas data

1:05:32Jadi misalkan apa yang dibaca

1:05:34Orang itu apakah data yang baru

1:05:36Atau data yang lama

1:05:38Dalam suatu transeksyen

1:05:40Ada konsep namanya ghost read

1:05:42Ghost read datanya atau gimana

1:05:44Dan setiap data based engine

1:05:46Itu punya caranya sendiri

1:05:48Untuk handle

1:05:50Bawa bawa bawa

1:05:52Bawa

1:05:54Sama itu

1:05:56Anak BE wajib tahu ajib

1:05:58Itu itu itu

1:06:00Bagaimana Postgres itu

1:06:02Integritasnya gimana

1:06:04Sebelah mana dia menjaga integritas

1:06:06Datanya supaya terjadi

1:06:08Data yang konsisten

1:06:10Di sana

1:06:12Jangan lupa di subscribe ya

1:06:14Live nya setiap

1:06:16Beberapa bulan

1:06:18Oh lagi libur

1:06:20Coba cari format live

1:06:22Oke oke

1:06:24Ini tadi

1:06:26C

1:06:28Tadi masih

1:06:30Berlanjut ngobrolin tentang

1:06:32Eskelat ya

1:06:34Ada ada apa

1:06:36Ada beberapa yang menarik juga

1:06:38Ternyata ada banyak

1:06:40Yang scaling juga

1:06:42Salah satunya apa

1:06:44Posting ini tahun berapa ya

1:06:462022

1:06:48Dia bisa sampai 200 juta

1:06:50Request per bulan

1:06:52Atau 4 juta

1:06:54Request per sekai

1:06:56Levels I/O ya

1:06:58Ya levels I/O

1:07:00Dia kalau gak salah pernah cerita

1:07:02Eee

1:07:04Lupa ya

1:07:06Buka aja opsennya levels.io

1:07:08Ini kan

1:07:10Apalagi yang

1:07:12Pinter namanya

1:07:14Ya pinter levels ya pinter levels

1:07:16Yang produknya banyak banget kan

1:07:18Kalau gak salah dia pernah cerita

1:07:20Kalau dia pake eskelat itu untuk multi tenancy

1:07:22Application

1:07:24Jadi satu tenant satu

1:07:26Satu udah habis

1:07:28Expensive

1:07:30Bukan gak tau apa namanya

1:07:32Yang jelas

1:07:34Dia pernah cerita kayak

1:07:36Ada orang yang

1:07:38Berlangganan SAS nya dia

1:07:40Dia bikin satu instant atau satu tenant

1:07:42Itu database nya satu aja

1:07:44Jadi selain aman

1:07:46Nampur sama database orang lain

1:07:48Yang kedua ya

1:07:50Udah database nya itu doang satu

1:07:52Ini beda piter

1:07:56Beda piter

1:07:58Beda tuh

1:08:00Beda

1:08:04Ya pasti kan ada kayak

1:08:06Ini ya spesifik use case

1:08:08Yang kita gak tau gimana cara

1:08:10Set up nya ya

1:08:12Tapi di websitenya eskelat.org

1:08:14Went to use ya, jadi mungkin itu ada referensi utamanya

1:08:16Went to use

1:08:18Dari eskelat.org

1:08:20Yes

1:08:22Ini ada referensinya silahkan

1:08:24Kalau ada kasus seperti itu

1:08:26Kita ke eskelat.org

1:08:30Ini juga salah satu

1:08:32Project

1:08:34Yang sangat menarik

1:08:36Karena sebenarnya dia

1:08:38Open source

1:08:40Dalam artian

1:08:42Codenya bisa dilihat

1:08:44Tapi yang bisa commit atau yang bisa nge push

1:08:46Cuma 3 orang yang punya perusahaan

1:08:48Gak menerima pull request bahasa itu

1:08:50Gak menerima pull request ya

1:08:52Jadi read only ya

1:08:54Went to use

1:08:56Ada tuh went to use eskelat itu

1:08:58Jadi kalau misalnya mau tanya apa harus pakai eskelat sih

1:09:00Itu

1:09:02Embedded device

1:09:04Ini udah pasti ya kan

1:09:06Udah umum

1:09:08Application file format

1:09:10Website

1:09:12Berarti ini web scale ya

1:09:16Kalau misalnya

1:09:18Most of system kita

1:09:20Pasal block nya Mas Riza

1:09:22Gak ada masalah pakai eskelat

1:09:24Nggak gak pakai database

1:09:28Coba bikin block pakai database

1:09:30Banyak kali ada yang mau bikin

1:09:32Kalau block nya sampai

1:09:34100

1:09:36100 artikel per hari

1:09:38Perlu Mas

1:09:40Itu bukan block itu

1:09:42Portal berita

1:09:44Internet kerjaannya Mas Ivan

1:09:48100 kata per minggu aja

1:09:52Belum tentu bisa

1:09:54Apalagi 100 artikel

1:09:58Ini

1:10:00Seru ya

1:10:02Yang nomor 2 nya

1:10:06Client server

1:10:08Application

1:10:10High volume

1:10:12High concurrency

1:10:14High concurrency

1:10:16High concurrency ya

1:10:18Yang kita bahas

1:10:20Writer nya itu

1:10:24Masalah

1:10:26Betul-betul

1:10:28Karena file base

1:10:30Jadi ada

1:10:32Locking mechanism yang berbeda kan

1:10:34Pada saat mungkin ada yang lagi

1:10:36Hanya boleh 1 orang yang boleh merubah

1:10:38Hanya boleh 1 orang

1:10:40Jadi gak

1:10:42Kongkaren

1:10:44Oke pertanyaan pertama dari saya

1:10:46Sebelum kita menjawab pertanyaan penonton

1:10:48Kalau scaling

1:10:52Scaling yang mana dulu nih

1:10:54Horizontal

1:10:56Kalau memang dibutuhkan scaling

1:10:58Vertikal dulu lebih mudah ya

1:11:02Ya vertikal sampai mentok

1:11:04Dan maksudnya vertikal itu tidak selamanya

1:11:08Jadi yang biasa

1:11:10Vertikal dulu temukan toolprint nya

1:11:12Down

1:11:14Uses nya diturun lagi

1:11:16Oh bisa

1:11:18Bisa ya

1:11:20Jadi kalau kita pakai ini ya

1:11:22Kalo kan

1:11:24Apalagi ya pakai manage ya

1:11:26Manage service

1:11:28Itu kita harus naikin

1:11:30Ada concept downtime nya

1:11:32Kita harus tau downtime nya berapa lama

1:11:34Setelah dinaikin gitu kan ya

1:11:36Kita tau nih toolprint nya

1:11:38Di mana kita work on it

1:11:40Turun

1:11:42Diturunin akhirnya

1:11:44Jadi kayak naik itu hanya untuk sepersekian

1:11:46Hari

1:11:48Sepersekian hari untuk

1:11:50Disana

1:11:52Supaya gak down

1:11:54Kapan-kapan harus

1:11:56Ini tuh gak bisa naik lagi

1:11:58Gitu adalah ketika memang

1:12:00CPU nya naik ya

1:12:02CPU nya naik tapi tidak ada

1:12:04Slow query yang

1:12:06Berarti gitu kan ya

1:12:08Tapi lebih karau banyak request

1:12:10Untuk nge handle read secara

1:12:12Secara jumlah request nya

1:12:14CPU nya naik tapi tidak ada slow query

1:12:16Tidak ada itu berarti

1:12:18Sebelah harus di replikasi

1:12:20Kalau seasonal

1:12:22Contohnya

1:12:24Kayak 11/11

1:12:269/9, 10/10

1:12:28Biasanya

1:12:30Itu disediain dulu

1:12:32Disediain dulu

1:12:34Di pre-empt ya

1:12:36Tau bahwa itu seasonal

1:12:38Ready

1:12:40Atau banyak teknik ya

1:12:42Caching nya sebelah mana

1:12:44Karena kan contoh yang bisa share ya

1:12:46Jadi akan pernah terjadi

1:12:48News media

1:12:50Quick count

1:12:52Itu kan seasonal

1:12:54Iya itu seasonal

1:12:56Jadi kalau misalnya

1:12:58Ada satu website yang perlu di read

1:13:00Caching itu adalah

1:13:02Bumper utama

1:13:04Semua di caching

1:13:06Multi level dari GraphQL nya

1:13:08Di caching, dari data

1:13:10Per item nya di caching

1:13:12Itu level caching nya

1:13:14Itu banyak dari atas sampai bawah

1:13:16Tapi kan kalau quick count di caching

1:13:18Ngamuk tuh entar

1:13:20Iya, kok nge-net naik ya

1:13:22Tapi kan quick count

1:13:24Nggak real time pak

1:13:26Masa? Oh iya ya

1:13:28Per 5 menit, per 10 menit update nya ya

1:13:30Nggak mau level lho

1:13:32Kalau kita mau real time

1:13:34Itu beda cerita webshop ya

1:13:36Ternyata iya kan

1:13:38Sekalian aja online

1:13:40Berarti bukan quick count dong namanya ya

1:13:44Periodic count

1:13:46Catching count

1:13:48Catching count

1:13:50Quick itu kan

1:13:52Relatif

1:13:54Iya

1:13:56Kalau real time count baru

1:13:58Beda, harus real time

1:14:00Iya

1:14:02Atau biasanya

1:14:04Bulan 2, bulan 3 itu kan

1:14:06Pelaporan pajak

1:14:08Tahunan kan

1:14:10Itu biasanya

1:14:12Lambat juga

1:14:14Apalagi awal tahun

1:14:16Ganti ini ya

1:14:18Ada versi baru ya

1:14:20Awal tahun ya

1:14:22Untung bisa pakai yang lama

1:14:24Untung tahun ini bisa pakai yang lama

1:14:26Aku masih pakai yang lama sih

1:14:28Aku masih pakai yang lama sih

1:14:30Karena berusaha login nggak bisa

1:14:32Yaudahlah pusing

1:14:34Kalau untuk

1:14:36Peribadi iya yang lama

1:14:38Tapi kalau untuk perusahaan nggak bisa

1:14:40Karena pakai yang ber kan

1:14:42Skortex iya

1:14:44Luar deh

1:14:46Ya ampun

1:14:48Oke

1:14:50Sebelum kemana-mana

1:14:52Ini kita jawab-jawabin ya pertanyaannya

1:14:54Saya siswa RPL kadang bosen

1:14:56Belajar database, mudah-mudahan abis dengerin ini

1:14:58Jangan nggak bosen ya

1:15:00Banyak banget yang bisa di eksplor

1:15:02Dan kebanyakan

1:15:04Database itu mahal lho

1:15:06Iya, kebanyakan developer

1:15:08Sekarang kan fokusnya belajar aplikasi

1:15:10Sedangkan database nya kan itu kayak

1:15:12Second class gitu ya

1:15:14Kalau kita punya kemampuan database yang

1:15:16Kuat kayaknya nilai tambahnya

1:15:18Lebih gede kali ya

1:15:20Udah bisa bikin app, database nya

1:15:22Kencang gitu ya

1:15:24Saya di company saya salah satu

1:15:26Engineer yang

1:15:28Mengerti banyak

1:15:30Mengenai Elasticsearch

1:15:32Jadi secara karir saya aman

1:15:34Karena masih ada beberapa klien

1:15:36Banyak klien yang pakai

1:15:38Elasticsearch

1:15:40Jadi kalau ada apa-apa

1:15:42Saya tetap masih punya pekerjaan

1:15:44Database engineer

1:15:48Dajinya menarik

1:15:50Oh iya

1:15:52Oh iya

1:15:54Yang menarik adalah

1:15:56Sekarang itu banyak AI startup

1:15:58Bisa jauh datas UMR

1:16:02Banyak AI

1:16:04Database

1:16:06Faktor database

1:16:08Lagi banyak startup

1:16:10Itu kadang-kadang

1:16:12Tahu internalnya, Postgres

1:16:14Itu sangat-sangat menarik sih

1:16:16Tapi ya

1:16:18Berat sekali untuk belajar dan musuhnya

1:16:20Berat-berat juga

1:16:22Berat-berat juga

1:16:24Ini tadi ada yang

1:16:26Ngomongin tentang

1:16:28Elasticsearch itu kan bagian dari

1:16:30NoSQL berarti ya

1:16:32Ya itu dia

1:16:34Bukan

1:16:36Bukan SQL base ya

1:16:38Bukan SQL base ya

1:16:40Search engine ya

1:16:42Search engine jatuhnya ya

1:16:44Ini ada pertanyaan tentang

1:16:46MongoDB

1:16:48Kalau MongoDB gimana scalingnya

1:16:50NoSQL

1:16:52Kalau, jadi kalau

1:16:54Sekarang sederhana ya

1:16:56RDBM itu sangat

1:16:58RDBMS itu

1:17:00Dia kan ada

1:17:02Asset compliant ya

1:17:04Dengan posisi dan rubriknya

1:17:06Most of NoSQL itu adalah

1:17:08Asset compliant tapi high scalable

1:17:10Karena

1:17:12Ini mau read write-nya itu

1:17:14Cepat banget, karena kan tidak ada skema

1:17:16Yang menggunakan satu tabel dan satu tabelnya

1:17:18Di sana

1:17:20Dia read write-nya cepat

1:17:22Di sana, tapi saya ingat

1:17:24Itu MongoDB versi terbaru

1:17:26Dia mencoba untuk menambahkan fitur

1:17:28Aku gak tahu konsepnya gimana

1:17:30Tapi itu

1:17:32Jadi mungkin ada

1:17:34Fitur di dalam Mongo

1:17:36Jadi lebih kala-kala spektrumnya NoSQL itu

1:17:38Heavy

1:17:40Highly scalable

1:17:42Tapi tidak

1:17:44Agile compliant, RDBMS

1:17:46Agile compliant tapi tidak

1:17:48Gampang di scalingnya

1:17:50Susah scalingnya ya

1:17:52Susah scalingnya ya

1:17:54Oke, ini tapi pertanyaannya

1:17:56Bukan tentang MongoDB sih

1:17:58Ada proses transaksi yang saat ini

1:18:00Displit menjadi beberapa collection

1:18:02Collection-nya, panjang banget

1:18:04Ada paca ya

1:18:06Ini database apa ini

1:18:10Ada alasan khusus

1:18:12Kenapa skema nya displit terlalu panjang

1:18:14Pertanyaannya ada gak?

1:18:16Baca lagi, isu saya sekarang untuk

1:18:20Generated Report

1:18:22Agregat data, agregat data salah satunya

1:18:24Kesulitannya di NoSQL

1:18:26Kalau non-relational

1:18:28Untuk agregasi adalah musuhnya

1:18:30Itu musuh utamanya

1:18:32Tidak bisa

1:18:34Kenapa pakai NoSQL?

1:18:36Atau kalau mau gak mau

1:18:40Cara paling gampangnya adalah

1:18:42Mas bikin tron job

1:18:44Buat masukin itu ke relational database

1:18:46Atau bikin objeknya sendiri

1:18:50Khusus untuk view

1:18:52Atau bikin collection

1:18:54Bikin collection yang dimana itu

1:18:56Ngebungkan, jadi ada summary

1:18:58Ada ITL-nya ya

1:19:00Extract

1:19:02Terus di load collection itu

1:19:04Khusus buat report itu

1:19:06Jauh lebih gampang bacanya

1:19:08Jadi bukan quitcon lagi, jadi batching

1:19:12Saya juga sering menemukan

1:19:16Beberapa hal tentang

1:19:18Biasanya terutama MongoDB

1:19:20Atau NoSQL itu

1:19:22Mindsetnya masih relational database

1:19:24Jadi design tablenya itu

1:19:28Masih relasi gitu

1:19:30Masih dipisah-pisah

1:19:32Jadi keunggulan si NoSQL

1:19:34Jadi gak kepake gitu kan ya

1:19:36Jadi harus join-join juga

1:19:38PR banget itu kalau join-join

1:19:40Aku juga waktu budget firestore dulu ya

1:19:44Itu cara

1:19:46Membuat simulasi kita kan

1:19:48ID ini

1:19:50Di beberapa collection itu

1:19:52Itu share gitu

1:19:54Jadi ketika kita punya satu ID ini

1:19:56Dia langsung ambil semuanya

1:19:58Dalam satu waktu bersama itu

1:20:00Salah satu cara mengakali simulasi

1:20:02RDPMS

1:20:04Tapi aku udah agak lupa sih

1:20:06Karena udah lama banget gak main

1:20:08Tapi jangan segera

1:20:10Mengembangkan sama SQL

1:20:12Jadi RDPMS itu salah

1:20:14Ya, justru

1:20:16Kelebihannya justru bukan disitu

1:20:18Kelebihannya adalah ya tadi

1:20:20Kencang untuk

1:20:22Nulis dan baca, tapi kalau untuk

1:20:24Join-join mah susah, SDK-nya susah

1:20:26Ada pertanyaan tentang Firebase Data Connect

1:20:30Wah, gak ngerti nih saya, Mas Donny ngerti gak?

1:20:32Aku pernah bikin inkos senang ini ya

1:20:36Di platform lain

1:20:38Intinya adalah

1:20:40Data Connect itu sebenarnya pakai Cloud SQL

1:20:42Cloud SQL?

1:20:44Oh, oke

1:20:46Ada magic happen disana

1:20:48Berarti kamu hal-hal

1:20:50Tahu bahwa

1:20:52Ya, jadi kalau kita connect your app

1:20:54To fully manage scaleable database

1:20:56Using Cloud SQL for scale-scale

1:20:58Cuman, Data Connect itu

1:21:00Interface-nya pakai GraphQL

1:21:02Itu doang sebenernya

1:21:04Oh

1:21:06Oke, oke

1:21:08Kebayang-kebayang

1:21:10Untuk saya, aku gak bakal pakai itu sih

1:21:12Kenapa?

1:21:16GraphQL, gara-gara GraphQL, bukan?

1:21:18Karena kami custom solver

1:21:20Solusinya harus jadi on-off

1:21:22Oh, karena ini ya, karena kebutuhan

1:21:24Jadi gak akan pakai, karena gak cocok

1:21:26Kalau itu cocok buat kamu

1:21:28Pakai aja nih

1:21:30Kira-kira cocoknya buat aplikasi seperti apa

1:21:32Atau perusahaan apa

1:21:34Yang bergerak di bidang apa

1:21:36Startup

1:21:38Karena dia ada

1:21:40VectorDB ya

1:21:42Vector PG Vector

1:21:44Disana, dan ada GameKit

1:21:46Firebase GameKit

1:21:48Pernah bikin blog di Google Cloud

1:21:52Indonesia ya, jadi gampang banget

1:21:54Bikin receiver sama indexer-nya

1:21:56Pakai GameKit

1:21:58Oke, oke

1:22:00Oh, berarti dia lebih ke integrasinya ya

1:22:02Kalau kita

1:22:04Real-time database-nya

1:22:06Itu connect gak ke

1:22:08Fire, apa namanya?

1:22:10Firestore ya? Firebase yang

1:22:12Real-time database itu? Beda ya?

1:22:14Beda

1:22:16Beda ya, oke

1:22:18Itu kan non-sql juga ya

1:22:20Itu non-sql juga ya, berarti ya

1:22:22Ya

1:22:24Nah, Firebase ini juga salah satu

1:22:26Database yang mungkin anak front-end

1:22:28Cukup familiar ya, dengan Firebase

1:22:30Atau supabase sekarang

1:22:32Atau tadi pocketbase, dan base-base yang lain

1:22:34Ada budi-base banyak banget

1:22:36Bagaimana budi-base?

1:22:38Itu budi-base

1:22:40Kayaknya CMS no code ya?

1:22:42Iya, budi-base itu

1:22:44Yang buat budi bukan ya orang Indonesia

1:22:46Itu kayak

1:22:48Google Cool

1:22:50Internal Tools gitu loh, Mas

1:22:52Iya, buat internal tools, kayak apa ya

1:22:54Ritual

1:22:56Ritual, ya Ritual

1:22:58Ya Ritual

1:23:00Buat dashboard internal

1:23:02Nah, Mas Rio

1:23:04Untuk lo audit trail, better

1:23:06No-sql atau rdbms?

1:23:08Audit

1:23:10Trail

1:23:12Bukan yang pakai itu ya, tadi ya

1:23:16Elasticsearch gitu ya

1:23:18Kalau logging-logging

1:23:20Siapa pernah, akses siapa

1:23:22Pernah untuk

1:23:24Nyimpan ini kan ya, lebih ke

1:23:26Apakah NTT itu dirubah

1:23:28Bentuk perubahannya apa, kemudian

1:23:30Siapa yang merubahannya

1:23:32Aku kebetulan banyak

1:23:34Kasus dimana

1:23:36Table audit logging itu di dalam

1:23:38Database yang sama

1:23:40Jadi

1:23:42Menurutku secara mayoritas

1:23:44Audit ini kayak akan jarang

1:23:46Dikunakan ya, di akses

1:23:48Dalam kondisi tertentu

1:23:50Nggak harus dipisah sih

1:23:52Mendingan pakai database yang sama

1:23:54Dan nggak perlu ada relasi, itu cuma kayak

1:23:58Dam doang

1:24:00Oke, oke, ada tips nggak

1:24:06Untuk pindahan data-database

1:24:08Dari sql server ke

1:24:10Postgre

1:24:12Dengan

1:24:14Iya ya, enak sekarang ya

1:24:18Kalau dulu kita bikin sendiri ya

1:24:20Karena

1:24:22Sebenernya jadi masalah itu adalah

1:24:24Sql itu share

1:24:26Sql1 dengan engineer itu

1:24:28Mungkin di angka 70%

1:24:30Jadi kamu nggak bisa

1:24:32Dengan query yang sama

1:24:34Itu bakal

1:24:36Mati, gitu kan

1:24:38Satu-satunya cara adalah

1:24:40Ya udah, gitu pakai

1:24:42Demini buat

1:24:44Untuk bantuan AI ya

1:24:46Bikin ini disana

1:24:50Atau pakai ORM

1:24:52Multi-dialect ya

1:24:54Data-based ya

1:24:56Disini gunanya ORM juga ya

1:24:58Itu juga benefitnya

1:25:00ORM sih, bisa pindah-pindah

1:25:02Data-based

1:25:04Jadi yang mengurus ini tuh bukan kamu

1:25:06Ya, abstraksi

1:25:08Ngomongin ORM

1:25:14Kalau project awal pakai ORM, sekarang

1:25:16Quailshare aja udah terasa latensinya

1:25:18Apakah perlu re-readdb atau

1:25:20Pake query-builder

1:25:22Ya

1:25:24Latensinya

1:25:26Di mana dulu, cari dulu

1:25:28Cari tahu dulu

1:25:30Root cause-nya

1:25:32Locking mechanism

1:25:34Atau

1:25:36Locking, atau memang

1:25:38Ada slow-query, atau ya

1:25:40Mp1 Anda itu

1:25:42Yang manggil-manggil

1:25:44Berulang kali

1:25:46Jangan-jangan aplikasinya

1:25:48Atau kodenya yang

1:25:50Four di dalam four

1:25:52Terus panggil query langsung kan

1:25:54Bisa aja, banyak ya

1:25:56Jadi harus cari tahu ini dulu

1:25:58Jangan asal

1:26:00Re-write

1:26:02Karena takutnya masalahnya bukan di situ

1:26:04Kawatirnya masalahnya

1:26:06Bukan di situ

1:26:08Ini pertanyaan internal nih

1:26:14Mas Aris

1:26:16Sampai saat ini ada perdebatan pemilihan tipe data

1:26:18Primary ke antara UID atau serial

1:26:20Atau Big Indie MySQL

1:26:22Ini nama-nama

1:26:24Nanti aja di jawab internal

1:26:28Buat yang nggak tahu

1:26:32Kalau serial itu kan

1:26:34Autoincrement kan ya

1:26:36Kalau sekarang kan sudah

1:26:40Disarankan untuk tidak menggunakan auto increment

1:26:42Karena terlalu mudah di

1:26:44Prediksi

1:26:46Bisa mudah ditebak

1:26:48Misalkan user/1/edit

1:26:50Ini user ID 1 nih

1:26:52Bisa ketahuan

1:26:54Jadi lebih disarankan menggunakan UID

1:26:56Itu kalau dari sisi awam ya

1:26:58UID sudah versi berapa sekarang?

1:27:00UID 7 ya?

1:27:04V4

1:27:06V7

1:27:08Ada lagi yang baru ulit

1:27:12Ada ulit itu sudah sendiri

1:27:14Oh ada, beneran dia

1:27:16Saya pikir

1:27:18Bedanya V7 sama V4 itu adalah

1:27:20V7 itu sudah menambahkan timestamp

1:27:22Unique timestamp

1:27:26Dalam generasinya

1:27:28Kalau di versi 4 kan

1:27:30Dia cuman random set of

1:27:32Ini ya, unique

1:27:34Tidak ada timestampnya, jadi tidak bisa dissolve

1:27:36Secara ID

1:27:38Di sana

1:27:40Perdebatannya panjang

1:27:42Atau UID

1:27:44Di sana

1:27:46Karena set of example itu

1:27:48Pasti akan mengambil storage

1:27:50Cukup lumayan

1:27:52Karena cukup panjang untuk mencari unique ya

1:27:54Unique, unique ID

1:27:56Di sana

1:27:5864 ya?

1:28:0064 karakter ya?

1:28:02Berapa banyak sih?

1:28:04128 bit

1:28:06128 bit

1:28:08Panjang ya, panjang karakternya

1:28:12Apa ulit?

1:28:1448 bit unique timestamp

1:28:204 bit versi random data

1:28:22Di sana

1:28:24Oke

1:28:30Bisa pilih salah satu ya

1:28:32Kalau pindah dari auto increment ke

1:28:34UID atau ulit gimana caranya?

1:28:36Bikin aja

1:28:38Tablebar, te kolom baru

1:28:40Generate aja UID nya

1:28:42Pindahin index nya

1:28:44Tapi gak jadi primary key

1:28:46Ya ubah aplikasinya

1:28:48Dulu

1:28:50Di alternya

1:28:52Gak mungkin diritikkan itu kalau direplace

1:28:54Mending tambah kolom baru

1:28:56Mending tambah kolom baru

1:28:58Jangan direplace ya

1:29:00Apalagi delete

1:29:02Delete kolom itu cari masalah hidup sih

1:29:08Terus dari aplikasi

1:29:10Dilarang

1:29:12Dilarang menggunakan ID

1:29:14Jangan lagi pakai kolom ID

1:29:16Pelan-pelan ya, gak langsung

1:29:20Semuanya ya, kecuali aplikasinya kecil

1:29:22Jangan dirit kolom, itu benar kata mas Tony

1:29:26Apalagi kalau sudah deplikasi

1:29:28Sekali dirit kolom gede

1:29:30Itu syncronasi lama

1:29:32Bisa out of sync

1:29:34Kalau udah out of sync sakit kepala

1:29:36Saya kalau sudah out of sync

1:29:38Mending saya matiin to server

1:29:40Generate ulang, replikasi aja

1:29:42Karena sudah susah

1:29:44Kalau udah out of sync

1:29:46Aku pernah delete database production

1:29:50Waktu magang baru 3 hari

1:29:52Serius

1:29:54Saya

1:29:56Saya belum pernah

1:29:58Delete database, tapi saya pernah

1:30:00Delete query, tapi lupa where

1:30:02Begitu liat seribu sekian

1:30:04Roll affected

1:30:06Oh oh, kalau itu pernah

1:30:08Benarnya itu jadi test dari

1:30:10Perusahaan itu sih, apakah dia punya

1:30:12Mekanisme dimana kalau ada mistake

1:30:14Dari sesuatu, bisa direcover dengan

1:30:16Udah

1:30:18Di sana, jadi itu experience

1:30:20Yang tidak akan terlupakan sih

1:30:22Kalau misalnya, by the way itu

1:30:24Pernah disini, anaknya Zero One

1:30:26Untung ada backup

1:30:28Jadi beneran literalnya, delete

1:30:32Ada para di backupnya jadi aman

1:30:34Oh, kalau Mezo

1:30:36Katanya, tadi

1:30:38Pernah delete database, tapi nggak kehapus

1:30:40Gak beneran kehapus, soft delete atau gimana

1:30:42Nggak tahu deh

1:30:46Keringet dingin

1:30:48Oh, di test kali, emang sengaja kali

1:30:50Di test, emang harus mengalami itu

1:30:52Dan itu juga bagian test dari perusahaan

1:30:56Apakah siap kalau terjadi kesalahan-kesalahan

1:30:58Itu kan kesalahan umum ya

1:31:00Kalau sesuatu yang

1:31:02Kamu kerja pernah

1:31:04Waktu kerja, pernah mengisi form

1:31:08Untuk bersedia, bekerja di bawah tekanan

1:31:10Itu paling di bawah tekanan itu kayak gitu

1:31:12Itu bekerja di bawah tekanan

1:31:16Itu

1:31:18Job description yang paling tidak

1:31:20Tidak bisa dijelaskan

1:31:22Tekanan apa dulu

1:31:24Oh iya, itu juga ya

1:31:26Makanya jangan sekali-kali

1:31:28Mengesekusi

1:31:30Sql, yang Mas Oddy itu

1:31:32Mengesekusi Sql

1:31:34Di production itu harus dilihat dua kali ya

1:31:36Kadang-kadang lupa, aware itu

1:31:38Hapus-hapus semua itu

1:31:40Betul-betul, saya juga pernah mengalami

1:31:42Ini kalau aware-nya lupa

1:31:44Bahkan bukan hanya delete, update

1:31:48Update juga bahaya kan, aware-nya lupa

1:31:50Oh iya, nggak pakai aware itu

1:31:52Makanya harus

1:31:56Mekanisme

1:31:58Production, staging

1:32:00Testing itu harus

1:32:02Ini dulu ya, harus clear dulu

1:32:04Kalau di lokal kapus ya

1:32:06Udah

1:32:08Harus jangan sendirian ya

1:32:10Kalau mau mengupdate sesuatu

1:32:12Di production jangan sendirian, harus lebih dari satu

1:32:14Orang

1:32:16Ada kuncennya

1:32:18Pak Imre kayaknya sekarang rolnya itu ya

1:32:20Kuncen, udah habis dia ya

1:32:22Kuncen

1:32:24Harus udah kuncennya, nggak boleh sendiri

1:32:26Apalagi anak magang

1:32:28Wah, ini ada sesuatu yang aneh

1:32:30Kalau anak magang bisa akses database production langsung ya

1:32:34Jadi ya gitulah

1:32:36Kalau saya pernah

1:32:40Arcing, delete

1:32:42Tetapi lupa supply

1:32:44Pathreal-nya

1:32:46Terus, kehapus dong

1:32:52Ya kehapus lah

1:32:54Production

1:32:58Harusnya path-nya itu A, B, C, D, E, E

1:33:00A, B, C, D

1:33:02Tetapi

1:33:04Waktu di concat itu C dan D-nya

1:33:06String kosong

1:33:08Jadinya A, B aja

1:33:10Jadi semua yang di belakang A, B itu

1:33:12Ke delete

1:33:14Aduh kan diwasa

1:33:16Tapi itu jalannya di GitHub Action

1:33:22Dan saat deploy

1:33:24Loh, kok ilang semua

1:33:26Hati-hati yang kalau pakai

1:33:30Siapa yang ngerubah kondisional ini

1:33:32Wah, dilihat

1:33:34Ya

1:33:38Tapi bisa recover

1:33:40Berhasil recover atau

1:33:42Tidak

1:33:44Pertanyaannya, saya nggak tahu file apa yang kehapus

1:33:48Jadi, yang penting-penting

1:33:50Berhasil recover

1:33:52Tetap ada backup-nya

1:33:56Backup file-nya itu kebetulan nggak ada

1:34:00Jadinya ada yang hilang sih, tapi ya

1:34:02Ya sudahlah

1:34:04Ya sudahlah ya

1:34:06Lesson learned

1:34:08Pendewasaan ini ya

1:34:10Tapi bukan saya

1:34:12Saya bukan, bukan saya penyebabnya

1:34:14Saya yang dipanggil untuk

1:34:16Nge-recover

1:34:18Di investigasi

1:34:20Recover

1:34:22Nggak, langsung kayak

1:34:24Kalau bahas di rumah sakit, code blue

1:34:26Kayak langsung

1:34:28Kebakaran

1:34:30Emergenci, dan saya yang ditugaskan

1:34:32Untuk merecover itu semua

1:34:34Secepat mungkin

1:34:366 jam saya, sampai jam 12 malam

1:34:38Baru bisa recover

1:34:42Berapa situs ya

1:34:4416 situs

1:34:46Banyak ya

1:34:48Itu pendewasan diri ya

1:34:50Kalau mau jadi senior engineer

1:34:52Harus melewati fase itu ya

1:34:54Harus pernah horror story

1:34:56Besok paginya

1:34:58Nulis RCA

1:35:00Postmortem

1:35:04Postmortem

1:35:06Sudoh RMRS

1:35:08Sudoh ya

1:35:10Ya bukan sudoh, arcing, arcing delet

1:35:12Itu juga masalahnya

1:35:14Bahaya, sama bahaya

1:35:16Sama RMRF

1:35:18Sama

1:35:20Menghilangkan sesuatu

1:35:22Dengan cara yang berbeda

1:35:24Kalau database

1:35:26Nggak sih

1:35:28Kalau database, rusaknya karena itu tadi

1:35:30Ya saya lakukan delet

1:35:32Tapi kebanyakan, tapi lupa

1:35:34Aplikasinya, replikasinya

1:35:36Yang lain, akhirnya terjadi

1:35:38Out of sync, database nya

1:35:40Loking, segala macam

1:35:42Ya

1:35:44Sakit kepala disitulah

1:35:46Membantu situs

1:36:00Plug Merah

1:36:02Dia juga

1:36:04bottleneck nya

1:36:06Di web server, di hujung nih

1:36:08Banyak traffic, tapi database nya

1:36:10Satu, dan nggak ada caching

1:36:12Itu juga masalahnya

1:36:14Banyaklah

1:36:16Pertanyaan terakhir

1:36:18Ini tentang trigger

1:36:20Ini mirip juga, kayak tadi kita udah bahas

1:36:22Store procedure ya, trigger juga sama

1:36:24Susah maintenance trigger

1:36:26Betul

1:36:28Preferensi ku adalah

1:36:30Mendingan di aplikasi

1:36:34Karena tidak semua orang

1:36:36Aware tentang store procedure

1:36:38Tidak semua orang mengerti

1:36:40Bagaimana membaca itu

1:36:42Kalau aplikasi kan sudah fair sama semua ya

1:36:44Mengerti tahu bahwa itu ada

1:36:46Cron job, atau ada

1:36:48Triggering suatu disitu

1:36:50Paling mentok

1:36:52Yang aku pakai di post way itu

1:36:54Adalah auto

1:36:56Out of sync

1:37:00Listen change

1:37:02Jadi ketika ada

1:37:04Kita kayak, web server itu ya

1:37:06Kalau misalnya ada suatu

1:37:08Table, kita bisa listen

1:37:10Ketika ada perubahan, dia

1:37:12Otomatis juga menghasilkan

1:37:14Data yang paling baru

1:37:16Disana, jadi ada itu di post way

1:37:18Dan digunakan sama

1:37:20Beberapa anak siruan

1:37:22Sebatas itu

1:37:24Kayak custom

1:37:26Bikin

1:37:28SPG

1:37:30SPG, PGL sendiri

1:37:32Itu terlalu

1:37:34Terlalu ini

1:37:36Terlalu susah untuk

1:37:38Dipahami

1:37:40Terlalu susah untuk dipahami, iya

1:37:42Jadi, sebar-sebar ya bisnis logicnya ya

1:37:44Lo masih live

1:37:46Mereka, lo masih live ya

1:37:48Banyak yang curhat soalnya

1:37:50Banyak yang curhat

1:37:52Ini baru mau udahan

1:37:54Udah pertanyaan terakhir

1:37:56Gimana, kita cukupkan?

1:37:58Cukup

1:38:00Kita cukupkan sampai disini, berarti kesimpulannya adalah

1:38:02Kalau mau scaling data bis

1:38:04Pertama yang dilakukan vertical scaling

1:38:06Dulu ya, sampai mentok

1:38:08Sampe mentok budgetnya

1:38:10Ya, sampai mentok

1:38:12Bukan, sebelum melakukan scaling

1:38:14Cari tahu justifikasi

1:38:16Kenapa butuh scaling

1:38:18Oh iya, ini dulu

1:38:20Measure dulu

1:38:22Lambat itu seberapa lambat

1:38:24Jadi sebelum di optimize

1:38:26Di measure dulu, oh

1:38:28Waktu sekarang ini 3 detik

1:38:30Jangan sampai

1:38:32Begitu di optimize, malah jadi

1:38:346 detik, gitu ya

1:38:36[tertawa]

1:38:38Monitoring itu penting

1:38:40Monitoring itu penting, karena kita bisa tahu

1:38:42Betul

1:38:44Sukses apa

1:38:46Term of suksesnya apa

1:38:48Kalau optimize, harusnya kan harus lebih cepat

1:38:50Kalau kita nggak tahu

1:38:52Berapa lama database

1:38:54Query-nya dijalankan

1:38:56Ya, kita nggak bisa measure

1:38:58Nggak bisa ngitung ini

1:39:00Jadi lebih baik atau lebih buruk, gitu

1:39:02Jadi harus measure dulu

1:39:04Habis itu kalau mau scaling ya

1:39:06Di check, di check ini dulu ya

1:39:08Di check query-nya satu-satu

1:39:10Indexing-nya

1:39:12Connection pool-nya

1:39:14Terus ORM-nya

1:39:16Kalau pakai ORM, di optimize

1:39:18Query-nya, kalau bisa pakai

1:39:20Query kalau udah

1:39:22Lumayan kompleks

1:39:24Terus habis itu baru

1:39:26Menuju ke infra

1:39:28Infra-nya tadi kita nggak bahas ya

1:39:30Kasing-nya dulu

1:39:32Kasing-nya dulu

1:39:34Betul

1:39:36Kalau misalkan kayak Postgre

1:39:38Atau MySQL itu kan banyak ya servisnya ya

1:39:40Ada Cloud SQL

1:39:42Ada

1:39:44Aurora

1:39:46RDS, macam-macam gitu ya

1:39:48Atau kita bisa sendiri

1:39:50Menyalahin VM

1:39:52Install Postgre

1:39:54Jadi gitu kan bisa juga

1:39:56Tapi kalau pakai yang servis kan lebih gampang ya

1:39:58Lebih sederhana

1:40:00Ada monitoring-nya juga

1:40:02Terus kalau

1:40:04Berasa masih lambat

1:40:06Vertical scaling sampai mentok ya

1:40:08Mentok, entah itu mentok mesinnya

1:40:10Atau mentok duitnya, budgetnya

1:40:12Karena

1:40:14Semakin ke atas itu

1:40:16Semakin mahal ya, jaraknya semakin tinggi ya

1:40:18Harganya

1:40:22Dan nggak linear ya

1:40:24Harga Cloud itu nggak linear

1:40:26Nggak linear

1:40:28Eksponensial mereka itu

1:40:30Eksponensial, betul

1:40:32Kalau setelah vertical scaling

1:40:34Udah mentok, baru larinya ke

1:40:36Horizontal ya

1:40:38Jadi horizontal itu adalah mesinnya dibanyakin

1:40:40Kalau vertical itu mesinnya

1:40:42Di upgrade

1:40:44Abis itu bisa dipecah

1:40:48Mau dipecah pakai

1:40:50Replika, partitioning

1:40:52Sharding

1:40:54Dan lain-lain

1:40:56Kalau SQLite beda lagi karena dia satu file

1:40:58Dan servisnya

1:41:00Kalau di Cloud-Cloud besar nggak ada ya

1:41:02Harus bikin sendiri ya, atau pakai

1:41:04Pocket base tadi

1:41:06Oke, mungkin cukup

1:41:10Ada lagi yang mau disampaikan

1:41:12Sebelum kita udah, cukup

1:41:14Terima kasih buat teman-teman

1:41:18Diskusinya seru

1:41:20Beberapa pertanyaan yang belum terjawab

1:41:22Mohon maaf belum bisa dijawab

1:41:24Nanti larinya ke

1:41:26Github aja

1:41:28Atau ke Eks

1:41:30Ke Github

1:41:32Discussion atau ke Eksnya, Mas Donny

1:41:34Eksnya apa?

1:41:36Baru aku liat

1:41:38Ternyata juga ada bagu hantam

1:41:40Sedikit informasi aja, di Eks

1:41:42Sudah ada bagu hantam tentang ORM dan

1:41:44Rockwell, aku baru liat

1:41:46Oh iya?

1:41:48Oh iya?

1:41:50Apa pas banget kita lagi ngomongin gitu

1:41:52Tiba-tiba ada bagu hantam

1:41:54Iya, bagu hantam ini

1:41:56Ya udah deh

1:41:58Mas Donny ini yang punya

1:42:00Manjalah Gatra bukan sih?

1:42:02Apa?

1:42:04Bukan!

1:42:06Sebenernya

1:42:08Sebenernya, mana ininya

1:42:10Ini

1:42:12Terima kasih

1:42:16Bukan

1:42:18Iya, Mas Donny harus mampir lagi

1:42:20Harus

1:42:22Harus sering-sering mampir ya, jangan sampai

1:42:24Ya

1:42:26Oke

1:42:28Mungkin sekian dulu

1:42:30Terima kasih buat semuanya, terima kasih juga

1:42:32Buat Mas Donny yang udah menyempatkan hadir

1:42:34Terima kasih Mas Donny

1:42:36Kita ketemu di

1:42:38Ayo Eks ya

1:42:40Ayo Eks

1:42:42Atau di manapun kita ketemu ya

1:42:46Sampai ketemu

1:42:48Buat Ivan

1:42:50Dan Eka, sampai ketemu minggu depan

1:42:52Bye-bye

1:42:54Bye-bye

1:43:16[MUSIK]

1:43:46Buat eksplorasi, kita akan mencoba.