Pak terangin dong
read committed => naon?
repeatable read => naon?
serializeable => another naon?
'Availability'
gamau wkwkwkw
ck!
pelid
DM nih kalo ga mau.
Oke baru baca
read committed => Ga bakal baca dari write yang belum beres. Cuma yang udah di-commit aja.
repeatable read => Dalam transaksi kalo ada 2x read bakal ngehasilin hal yang sama. Sementara kalo read committed aja kalo ada transaksi lain yang ngubah rownya, maka bisa jadi read kedua berubah.
ada juga level snapshot, tapi di yugabyte disamain sama repeatable read
meanwhile kalo sql normal yang kek postgres, mysql ada read uncommited, satu level dibawah read commited
serializable => Dalam satu transaksi, transaksi lain harus nunggu kalo ada row yang lagi di-lock. Statenya ga akan berubah.
kalo mssql, lebih banyak lagi isolation levelsnya
read uncommitted gawat juga kalo masih otw
Makannya transaction jangan lama-lama lah ya.
Kalo bisa pake atomic operations aja.
plus kalo pake NewSQL jangan pake AUTO INCREMENT karena akan jadi hotspot mas @Ramad987
ga bisa enggres mz
halah boong aja om ini wkwkwk
Zaman old bikin aplikasi harus lock-lock di DB lama, bahkan stored procedure panjang.
Zaman sekarang saya nyari cara yang atomic aja. Hahahaha.
serializable itu ngejamin consistency, tapi ada drawback di performance. kalo misalnya 1 table punya write rps yang banyak banget, bisa jadi bottleneck
Benul
Cuma bermasalah kalo domain objectnya adalah hasil agregasi beberapa tabel.
Pas lagi operasi Save harus ngelock beberapa tabel.
Ooh bagian ini ga ke hindarin juga berarti ya
even di cluster deployment. misal deploy 5 node. ya kalo bikin transaction pake level serializable, consistency terjamin, tapi kita harus nunggu sampe data beneran ke write ke 5 node itu
Benar, jadi mindsetnya tetep sama aja. Nunggu quorum.
yang paling pusing di newsql itu kalo bikin JOIN query, tapi clusternya di sharding
Kalo ga serializable, bisa baca dari node lain tapi datanya belum quorum.
enggak mas, soalnya kalo AUTO INCREMENT artinya harus tau state dari row sebelumnya.
ada yang lebih pusing lagi: kalo database lost quorum, what should you do? wkwkkw
kalo statenya masih dalam keadaan di lock, ya berarti harus nunggu laig.
Matiiin, recover, replay.
SAMA AJA *kabur
hooo tidak semudah itu
Ini makanya kalo bisa domain object jangan banyak2 tabelnya. Problemnya RDBMS itu enakan di-JOIN daripada bikin array dalam satu field.
Lalu gimana mz?
Belum lagi kalo split brain 😛
yang bener mana ini...
Waktu itu client ttp mauny pake auto increment, akhirny diatur sequencingny, increment +100, starting point masing2 db beda
Ya kalo kata klien sih ya udah 😄
tapi AUTO INCREMENT itu memaksa sesuatu yang stateless jadi stateful.
bahkan masih ada yang mikir kalo primary keynya bukan integer itu lembet.
Padaha uuid itu ya integer juga. Cuma 128 bit.
Cuma ya ... ga urut aja hahaha.
Ini harus 'stop the world' sebentar
dari tadi nyari di docs yugabyte sama cockroachdb ga nemu. yowes ambil dari rqlite aja wkwkwk
ada yang lebih parah. mikir kalo walaupun ada UUID jadi ID, harus tetep ada column ID yang AUTOINCREMENT wkwkwkwkwk
Ya sama aja dong. Maksain sesuatu yg stateless jd stateful.
Saya sekarang sih: data yang unique saya akan jadiin key :))
Ga harus UUID kecuali memang perlu ID.
iya. padahal developer udah provide UUID
mwekekekeke iya di program rewrite pake ini
tapi masih ada aja role sebelah yang maksa AUTOINCREMENT
ada, rolenya ARCHITECT bukan?
System Analyst
bodo amat mau VARCHAR juga, zaman now CPU dah kenceng. Lagian index itu kan pake b+tree kan, ya masak selemot itu.
*kemudian saya ingat, kalo VARCHAR nya unicode, brengsek juga krn urutannya ... jadi ga urut.
ya 10-13 lah 😛
+1
Binary data juga bisa di-indeks, tapi indeksnya ga ada konteks (collation) nya. Jadi nurut urutan binernya aja.
Kalo ada collation, jadi ada konteksnya: misalnya e dan ë harus satu urutan, ga boleh sehabis z.
Karena domain modelnya jadi enak mas. Bisa disimpen sekali, ga perlu query dulu id nya berapa. Jadi bisa satu trx tanpa select.
Kalo enggak, domain modelnya jadi kotor, karena harus nyimpen idnya juga di situ. Padahal itu id dipake buat keperluan storage aja.
Mayan panjang bahas bukan golang, ga diomelin admin? Haha
gw sih gpp '__')
related kan
gw sih gpp database tertentu auto increment, 200rb rps, ga tembus juga jumlah writenya
bottlenecknya bukan di situ
Single instance itu? di mesin kyk apa mas?
yes single machine
16 core
Postgre? Mysql? Mssql?
tarantool
kalo multimaster baru terpaksa no auto increment
bottlenecknya dimana? network io?
di layer depannya lagi
ga bisa utilize fully 200K rps XD
Kirain, afaik ga kuat dbms spek segitu untuk rps sgitu
harus spawn lebih dari 1 instance buat utilize
yes dbms biasa paling 40K rps
jadi bottleneck pertama ya di database XD bukan di backend/api
api gw cuma bisa 70K rps per instance
Dbms? Spek macem apa itu mas?
Di tech empower benchmark max data update aja 24k
ya elah, 70K ya udah lah
tarantool tetep + api
iyes, makannya ga perlu bashing auto increment XD
16 core, nvme biasa
Di allo ada mas product yg sampe segitu? Rahasia perusahaan ga ya, haha
udah banyak yg balik sadar server gede 2 lebih ok daripada rent spawn vm server kecil2
lebih ga lelah maintainnya
Yg banyak2 melelahkan y, bnyk vm, bnyk repo, bnyk service
tapi kalo kube lebih enakan gini om :))
kecil2 dan banyak
Tar tinggal dikonsolidasi hehhee.