Prinsip Pareto yang juga dikenal sebagai Aturan 80/20 menyatakan bahwa untuk banyak kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya. Prinsip ini diajukkan oleh pemikir manajemen bisnis Joseph M. Wikipedia
saya kerja sbg devops disalah satu company yg manage infra client, ketika ada issue mostly hampir 90% lebih, masalah / bottleneck terjadi di sisi database, entah querynya lama, connectionnya penuh dll pasti selalu terjadi dan impactnya ke infra. sepengalaman sy sbg ex webdev yg pernah nyoba ngebuat design system utk handling case demikian menurut sy ini sangat penting dan tidak bisa disepelekan, video ini sangat bagus dan memberikan gambaran dan pencerahan untuk para developer yg mungkin masih menyepelekan perihal decision system design & mechanism query ke database salah satunya. pernah dengar juga dari teman saya "if it works, don't touch it" tapi ya ga gitu juga bang 🥲
Setujuu, saya orang infra.. pernah kejadian akhir bulan closing sistem muter2 aja, saya yg ngurusin server babak belur sampe begadang2.. udah tuning web server sedemikian rupa , ga pengaruh , ternyata query nya ada loop 😢 giliran udah ketemu issue nya di query cuma ketawa ketiwi aja orang dev.. nasib kerja sistem lempar bola, bukan team yg solid.. nikmatin aja , maap curcol 😊
pak eko bahas tentang seputar best practice menghadirkan fitur public user (user hadir ke aplikasi karna register, login dan log out) di toko online kayak seputar struktur database, keamanan data pengguna, dll :D
Kang mau tanya, kalau misalkan querynya komplex dari aplikasi cuma panggil 1x, tp dalam 1 proses query tersebut terdapat tahapan pengecekan ketersediaan masukannya dengan melakukan query terhadap data lain sebelum query utamanya di jalankan semisal proses tersebut dibungkus kedalam sebuah Stored Procedure. Nah kira-kira tahapan seperti itu salah atau tidak? Terima kasih jika berkenan menjawab. 🤧
Bagian terakhir bang, kapan sebaiknya redis invalidated? Karena misal kita set 1 jam cachednya, ternyata lets say 30 menit sudah ada data yg berubah di database, harusnya kan redis invalidated. cmiiw. Apakah dibuat trigger jga buat ini?
agak kecewa sama postingan nya si orang itu di linkedin, kirain bakal diceritain lebih detail dia optimize apa: - mungkin dikasi context service nya ngapain, yang lambat awalnya dimana dsb - awalnya dia find bottleneck ngeliat apa, proses deduction nya gimana - contoh query nya kayamana yang dia optimize - strategi caching nya kayamana yang dipakai buat solve issue dia, kenapa pilih itu dsb - cara dia ngetest bisa dapet angka 15x lebih cepet tuh gimana Ini mah cuman kasi template gitu doang, bohong juga ga ada yg tau hehehe
implementasi redis nya gmn, ada expired data, atau update jika data beda. itu yg saya masih penasaran. saya simpan nya di aplikasi nya biasa nya. semisal nodejs. memory jadi banyak. tapi itu juga salah. jadi saya buat variable itu di simpan terus.
data yg sering diakses aja yg disimpan di reddis. terus gunakan pendekatan event driven buat update cachenya agar selalu up to date dgn data yg asli. terus handle case misal pas lagi proses update cache eh ada request yg masuk buat minta data di cachenya, misal buat requestnya nunggu sampai cachenya selesai di update atau alihkan ke database langsung, test mana yang lebih performant
si service report mungkin ga akan tau kalo data dari service product ada yang berubah, jadi kurang bagus ga sih kalo dicache? kayanya pernah dibahas di salah satu video di channel ini
menurut saya masih lebih baik menggunakan function atau procedure untuk satu proses yang banyak call ke tabel, hanya kirim 1 x koneksi ke DB dengan parameter yang diiinginkan tiggal di proses smua di DB , kadang kasian jg RDBMS uda buat function, trigger procedure ga dipake :D
Coba itu di terapin dengan client user yang banyak pasti banyak yang ke lock itu nanti querynya dan apalagi di cluster malah kagak worth it itu db cluster
berhubung tadi nyinggung response time, idealnya kalo misal udah ada standard terkait max response time (misal 3 detik), itu biasanya based on apa ya (local / staging / prod)? karena biasanya tiap environtment itu beda resource 🙏
Pertama, gunakan asymptotic concept di sini dulu Bg, Kedua sesuaikan Resourcenya sesuai dengan kebutuhan melalui vertical scaling atau horizontal scaling (untuk membagi beban/muatan ke sistemnya)
kalo case nya create or update gimana mas ? dalam 1 array ada 100 object, lalu di looping cek ref_code, kalo ada update kalo gk create. lebih baik metode nya seperti apa ya mas ?
Prinsip Pareto yang juga dikenal sebagai Aturan 80/20 menyatakan bahwa untuk banyak kejadian, sekitar 80% daripada efeknya disebabkan oleh 20% dari penyebabnya. Prinsip ini diajukkan oleh pemikir manajemen bisnis Joseph M. Wikipedia
Yes betul, biasanya ini digunakan juga di Quality Improvement seperti six sigma dll sebagai salah satu cara untuk mencari hal yg perlu di improve
saya kerja sbg devops disalah satu company yg manage infra client, ketika ada issue mostly hampir 90% lebih, masalah / bottleneck terjadi di sisi database, entah querynya lama, connectionnya penuh dll pasti selalu terjadi dan impactnya ke infra. sepengalaman sy sbg ex webdev yg pernah nyoba ngebuat design system utk handling case demikian menurut sy ini sangat penting dan tidak bisa disepelekan, video ini sangat bagus dan memberikan gambaran dan pencerahan untuk para developer yg mungkin masih menyepelekan perihal decision system design & mechanism query ke database salah satunya. pernah dengar juga dari teman saya "if it works, don't touch it" tapi ya ga gitu juga bang 🥲
"if it works, don't touch it" mntap wkwk
@teguhkurniawan878kalo boleh tau, tim infra itu apa ya bg? 🙏🏻
@@houhinkyouma6153 infrastructure engineer
@@houhinkyouma6153 kalo di permesinan ada mekanik, kalo di per-it-an ada infra. kurang lebih seperti itu om
Setujuu, saya orang infra.. pernah kejadian akhir bulan closing sistem muter2 aja, saya yg ngurusin server babak belur sampe begadang2.. udah tuning web server sedemikian rupa , ga pengaruh , ternyata query nya ada loop 😢 giliran udah ketemu issue nya di query cuma ketawa ketiwi aja orang dev.. nasib kerja sistem lempar bola, bukan team yg solid.. nikmatin aja , maap curcol 😊
Lebih ke istilah bisnis sih, contoh pareto customer. 20% customer yang menyumbang 80% order/income/laba
80/20 -> hukum Pareto. Menyatakan bahwa 80 % permasalahan disebabkan oleh 20% masalah. Fixing 20% masalah akan mengatasi 80% permasalahan tadi
terimakasih pak
pak eko bahas tentang seputar best practice menghadirkan fitur public user (user hadir ke aplikasi karna register, login dan log out) di toko online kayak seputar struktur database, keamanan data pengguna, dll :D
Kayanya butuh dark mode deh pak Eko. Pusing lihatnya kalau lagi di dalam ruangan yg gelap✌️✌️
80/20 Pareto diagram pak,,, di Teknik Industri dipelajari
mantap pak, terima kasih ilmunya. jadi makin solid
makasih pak eko pas bgt ada issue seperti ini...
Manteb nih buat merapikan kode aplikasi
amazing, thank you pak eko
Pareto principle 80:20
daging semua ini pas bgt lagi mikirin ini eh muncul
tracing monitoring ini tools atau maksudnya kita cek sendiri satu2 functionnya ya?
contohnya pake grafana buat monitoring
coba jngn kerja disini bang
berarti misal bang.
saya punya halamn beranda . perubahaan nya jarang.
apakah bisa sy simpan di redis?
bang tolong buat tutorial android udah 1 tahun nggak di lanjutin🙏
kerenn, terima kasih mas eko
Mantap pak eko videonya, the prime time tapi versi bahasa indonesia
Kang mau tanya, kalau misalkan querynya komplex dari aplikasi cuma panggil 1x, tp dalam 1 proses query tersebut terdapat tahapan pengecekan ketersediaan masukannya dengan melakukan query terhadap data lain sebelum query utamanya di jalankan semisal proses tersebut dibungkus kedalam sebuah Stored Procedure. Nah kira-kira tahapan seperti itu salah atau tidak? Terima kasih jika berkenan menjawab. 🤧
Salah 1 fungsi SP memang buat itu, sangat tidak bijaksana mengirimkan 1000 baris query over the network belum lagi skema database bisa terekspos
Bagian terakhir bang, kapan sebaiknya redis invalidated? Karena misal kita set 1 jam cachednya, ternyata lets say 30 menit sudah ada data yg berubah di database, harusnya kan redis invalidated. cmiiw. Apakah dibuat trigger jga buat ini?
klw data2 dinamis bgt kaya crud gak pake redis. tp kalau report2 bisa pake redis
Pas ada data berubah, bikin mekanisme buat delete key-value yang udah ga relevan.
pake metode Change Data Capture (CDC) bang, udah dijelasin juga disalah satu videonya kang eko
agak kecewa sama postingan nya si orang itu di linkedin, kirain bakal diceritain lebih detail dia optimize apa:
- mungkin dikasi context service nya ngapain, yang lambat awalnya dimana dsb
- awalnya dia find bottleneck ngeliat apa, proses deduction nya gimana
- contoh query nya kayamana yang dia optimize
- strategi caching nya kayamana yang dipakai buat solve issue dia, kenapa pilih itu dsb
- cara dia ngetest bisa dapet angka 15x lebih cepet tuh gimana
Ini mah cuman kasi template gitu doang, bohong juga ga ada yg tau hehehe
pak itu extention apa yg bisa suggest funcctin gtu
github copilot kah?
pak eko gak mau buat tutorial .Net kah? atau C++ or C#?
karena penerapan S.O.L.I.D principles, biasanya mengorbankan kinerja backend
Dotnet di indo masih kurang populer di startup ya
begitulah
80 20 itu konsep pareto effect
Milan Jovanovic dari pemain bola jadi programmer wkwk
cache ini agak tricky sih kayaknya
implementasi redis nya gmn, ada expired data, atau update jika data beda. itu yg saya masih penasaran. saya simpan nya di aplikasi nya biasa nya. semisal nodejs. memory jadi banyak. tapi itu juga salah. jadi saya buat variable itu di simpan terus.
mungkin bisa pake LRU buat cachingnya
data yg sering diakses aja yg disimpan di reddis. terus gunakan pendekatan event driven buat update cachenya agar selalu up to date dgn data yg asli. terus handle case misal pas lagi proses update cache eh ada request yg masuk buat minta data di cachenya, misal buat requestnya nunggu sampai cachenya selesai di update atau alihkan ke database langsung, test mana yang lebih performant
Mau tanya pak itu kalo semua di taro redis engga meledak ?
yg ditaruh itu data yg sering diakses bang
paling enak handle concurency pakai rxjs sih :v
Tutor C# kapan pak?😂
si service report mungkin ga akan tau kalo data dari service product ada yang berubah, jadi kurang bagus ga sih kalo dicache? kayanya pernah dibahas di salah satu video di channel ini
makanya perlu ada expire time nya
mahal sih materinya🔥
20/80 = paretto
menurut saya masih lebih baik menggunakan function atau procedure untuk satu proses yang banyak call ke tabel, hanya kirim 1 x koneksi ke DB dengan parameter yang diiinginkan tiggal di proses smua di DB , kadang kasian jg RDBMS uda buat function, trigger procedure ga dipake :D
Coba itu di terapin dengan client user yang banyak pasti banyak yang ke lock itu nanti querynya dan apalagi di cluster malah kagak worth it itu db cluster
berhubung tadi nyinggung response time, idealnya kalo misal udah ada standard terkait max response time (misal 3 detik), itu biasanya based on apa ya (local / staging / prod)? karena biasanya tiap environtment itu beda resource 🙏
Pertama, gunakan asymptotic concept di sini dulu Bg, Kedua sesuaikan Resourcenya sesuai dengan kebutuhan melalui vertical scaling atau horizontal scaling (untuk membagi beban/muatan ke sistemnya)
nitip komen % cuma saampai 100 bang
Prinsip pareto biasanya kepakai di testing
kalo case nya create or update gimana mas ?
dalam 1 array ada 100 object, lalu di looping cek ref_code, kalo ada update kalo gk create.
lebih baik metode nya seperti apa ya mas ?
di DB udah ada perintah INSERT ON DUPLICATE UPDATE
@@ProgrammerZamanNow udah bisa mas, saya pake method nya UPSERT
prinsip
Orang Java bahas artikel orang .NET 🙃