Mariadb (InnoDB) istočasni insert v tabelo iz različnih procesov

Zakaj pa ne auto increment?

Autoincrement mi ni všeč čisto iz estetskega razloga.

In ta je, da začne štet pri 1 in ne 0.

To bi sicer lahko pofixal, in vnesel prva dva row-a na roke, potem pa auto...

dfaq ? Zakaj ti ni všeč, da začne štet od 1. Pa si mogoče pomislil, da obstajajo kje kakšna nastavitev, da ti začne šteti iz 0 ?

V tvojem primeri se dogaja sledeče. Recimo, da imaš v bazi samo eno vrstico z ID-jem 1.

Process1...getMaxId , vrne 1
Process2...getMaxID , vrne 1
Process1...Insert [id 2]
Process1...Commit
Process 2...Insert [id 2]
Process 2...Commit
BANG!

Sej pravm, odpuščen :)

Z 0 začet ne gre.

AUTO_INCREMENT columns start from 1 by default. The automatically generated value can never be lower than 0.

Vir: https://mariadb.com/kb/en/auto_incremen...


To, da ti je za id vseeno, kakšno vrednost ima... Well, različni smo. Mene motijo že gap-i (0, 1, 2, 4), če brišem nekje na sredini.


Kar se tiče hendlanja v primeru, da pride do konflikta (kot je opisal mr_chai), imam rešeno, da se insert izvaja v loop-u (max 6 krat), dokler insert ni uspešen. Vsak loop ima time.sleep dolg nekaj 100 ms.

A kadar proces, ki dela v while loop-u, na polno tolče inserte, drug proces nima šans, da pride zraven. In faila 6x, kar je na koncu insert fail.


Ena opcija, za katero bi šlo, je da se insert ukazi pišejo v log file:
process_01.txt
process_02.txt

Potem pa insert process v single mode-u to pograbi in požene. Slaba stvar je, da je tak sistem asinhronski.


Druga opcija je, da bi razdelil id pool-e in jih dodelil različnim procesom (ti so trenutno trije).

Se pravi:
process_01 id_pool = 0 to 999999
process_02 id_pool = 1000000 to 1999999
process_03 id_pool = 2000000 to 2999999

To bi delalo, malo bi moral pofixat, kako dobit maxid za posamičen pool. A nastali bi ti gap-pi.


Tretja opcija je, da bi proces, ki je poizkusil insert, in je dobil duplicate error za id, v file zapisal neko vrednost (npr. 2022-06-21-21-42-07---2022-06-21-21-42-12) in s tem drugim signaliziral, da naj naredijo v tem časovnem obdobju med insertom time.sleep.


LOCK TABLE ne gre, ker: LOCK is not allowed in stored procedures

Z UUID še nisem delal. Zgleda dobra rešitev. Kako pa v takem primeru sortiraš glede na čas insert-a?

AndrejS je 21. jun 2022 ob 21:53 izjavil:

Jaz ti priporočam da opustiš programiranje. Za ID se vedno uporabi autoincrement na nivoju baze - ali pa za ID uporabiš GUID. Ker tak ko ti to delaš- bo prišlo do katastrofe, ko boš 1x imel veliko podatkov v kratkem časovnem obdobju za vstavit

Glede sortiranja na čas inserta pa dodaš stolpec created (timestamp) - CURRENT_TIMESTAMP()

In to točno tako, kot ti je napisal, čas iz baze, ne iz klijenta!

HotBurek je 21. jun 2022 ob 21:49 izjavil:

Z 0 začet ne gre.

AUTO_INCREMENT columns start from 1 by default. The automatically generated value can never be lower than 0.

Vir: https://mariadb.com/kb/en/auto_incremen...


To, da ti je za id vseeno, kakšno vrednost ima... Well, različni smo. Mene motijo že gap-i (0, 1, 2, 4), če brišem nekje na sredini.


Kar se tiče hendlanja v primeru, da pride do konflikta (kot je opisal mr_chai), imam rešeno, da se insert izvaja v loop-u (max 6 krat), dokler insert ni uspešen. Vsak loop ima time.sleep dolg nekaj 100 ms.

A kadar proces, ki dela v while loop-u, na polno tolče inserte, drug proces nima šans, da pride zraven. In faila 6x, kar je na koncu insert fail.


Ena opcija, za katero bi šlo, je da se insert ukazi pišejo v log file:
process_01.txt
process_02.txt

Potem pa insert process v single mode-u to pograbi in požene. Slaba stvar je, da je tak sistem asinhronski.


Druga opcija je, da bi razdelil id pool-e in jih dodelil različnim procesom (ti so trenutno trije).

Se pravi:
process_01 id_pool = 0 to 999999
process_02 id_pool = 1000000 to 1999999
process_03 id_pool = 2000000 to 2999999

To bi delalo, malo bi moral pofixat, kako dobit maxid za posamičen pool. A nastali bi ti gap-pi.


Tretja opcija je, da bi proces, ki je poizkusil insert, in je dobil duplicate error za id, v file zapisal neko vrednost (npr. 2022-06-21-21-42-07---2022-06-21-21-42-12) in s tem drugim signaliziral, da naj naredijo v tem časovnem obdobju med insertom time.sleep.


LOCK TABLE ne gre, ker: LOCK is not allowed in stored procedures

Z UUID še nisem delal. Zgleda dobra rešitev. Kako pa v takem primeru sortiraš glede na čas insert-a?

Kot so že zgoraj omenili, mislim da je edina rešitev prekinitev delovnega razmerja.
No resnično upam, da ne bodo te tvoje "rešitve" laufale kje na produkciji in probavaš bedarije kar tako za hec.

Če bi prvi post bil zgolj akademsko vprašanje bi ti odgovoril da je rešitev uporaba "Serializable" isolation level (default je "read commited"), ki bo poskrbel da je tudi read zablokiran med transakcijami in bo torej izvedel striktno eno za drugo in ne bo nikoli konflikta. Za več branja tu: https://mariadb.com/kb/en/mariadb-trans... Velja upozorilo, da serializable isolation level čisto iz performančnega vidika načeloma nočeš nikoli uporabit, razen ko res res ne gre drugače. Pa še takrat je morda softwerski locking boljša rešitev kot serializable transakcija.

Ampak ponavljam to ima zgolj akademsko vrednost, ali pa recimo kak edge use case kjer ne smeš sheme spreminjat na bazi. Da pa nekdo noče identity ali sekvence uporabit in gre raje take hacke delat samo ker se mu tako zahoče pa je norost.

HotBurek je 21. jun 2022 ob 22:14 izjavil:

Čas inserta pa seveda vnesem iz klienta, ker mi je v Python-u lažje (in hitreje) spisat, kot v SQL-u.

Si kdaj pomislil na to, kaj se bo zgodilo, ko bosta dva klienta z nekoliko različnim časom pisala v bazo? Točno tako. Sortiranje po času ne bo več delovalo pravilno. Kaj se bo zgodilo, ko bo nekdo z drugega časovnega pasu pisal v bazo?

Pri simulatorjih se pogosto uporablja tudi virtualni čas. Bi v tem primeru v bazo pisal virtualni čas pod čas nastanka/modifikacije?

Pri insertu vedno uporabljaj čas baze, ne klienta. No, lahko zraven daš še čas klienta, čist tko za info, če že hočeš.

Za ID pa autoincrement oz sekvence.

Za te stvari mora skrbeti baza, ne client. Če bi te stvari prepustil bazi, ne bi rabil tele teme, projekt bi bil pa že zaključen. Tako pa ugotavljaš, kako izvajati simple inserte z več procesov.

GupeM, za slabost (oz. več njih) vnosa datuma iz klienta za "čas vnosa" v bazo vem. Vseeno hvala za deljenje informacij in obrazložitev.

Moram pa rečt, da sem kar malo presenečen, koliko se vas je odzvalo z željo po pumpanju lastnega ego-ta. Nisem vedel, da je tako hudo.

Pa lep dan še naprej.

Sploh se ne gre za ego in pumpanje. Problem HotBureka(kualla?), je ravno v tem, da ko dobi dober nasvet, še vedno vztraja kako je njegova rešitev dobra in da sploh ni slaba. To lahko vidiš pri vseh njegovih IT-jevskih vprašanjih. Če se imaš namen učiti, ni problema, samo prosim, če ne upoštevaš dobrih nasvetov, kaj je potem sploh point spraševanja tule po slo-techu ? MIslim, da je bolj problem njegovega ega, kot našega. Če se hočeš česa naučiti, si moraš včasih priznati, da mogoče pa nekaj nisi dobro naredil. In to velja za vse, junior, seniorje in super savante.

Utk je 22. jun 2022 ob 15:51 izjavil:

Nihče mu ni rekel, da naj pusti programiranja zarad vprašanja.

AndrejS je 21. jun 2022 ob 21:53 izjavil:

Jaz ti priporočam da opustiš programiranje.

Slabo berete.

kuall je 22. jun 2022 ob 15:52 izjavil:

Utk je 22. jun 2022 ob 15:51 izjavil:

Nihče mu ni rekel, da naj pusti programiranja zarad vprašanja.

AndrejS je 21. jun 2022 ob 21:53 izjavil:

Jaz ti priporočam da opustiš programiranje.

Slabo berete.

Očitno si ti tist, ki slabo bere. To smo mu predlagali šele potem ko je "razložil" zakaj ne mara autoincrement.

Jaz nikjer ne vstrajam, da tako kot sem trenutno postavil insert, da se tako dela in da je to najboljš rešitev.

Dobil sem odgovor, da naj namesti INT za id uporabim UUID. Kar bom, mogoče ob enem izmed naslednjih rewrite-ov, tudi naredil. Mogoče. Ampak ta informacija je koristna, tudi za druge, ki se bodo znašel v isti situaciji.

Kar se pa ostalega tiče, je bilo pa veliko nepotrebne ego-eko-solate.

Tako da hvala za koristne informacije. Now, lets move on.

kuall je 22. jun 2022 ob 15:56 izjavil:

mr_chai je 22. jun 2022 ob 15:50 izjavil:

Sploh se ne gre za ego in pumpanje. Problem HotBureka(kualla?), je ravno v tem, da ko dobi dober nasvet, še vedno vztraja kako je njegova rešitev dobra in da sploh ni slaba.

če sem jaz dobil kak dober nasvet na slo techu sem ga vsekakor upošteval, ampak so žal zelo redki. večinoma je samo lajanje. debata o null je bila bolj akademska, ali pa enkrat debata o decimal: nisem se naučil nič novega tam kar ne bi že vedel, za decimal/float sem moral potem sam poguglat, da sem dobil pravo razlago, ker mi razni jypeti niso bili sposobni razložiti, razen to sem se naučil, da slo tech raja rada nesramno laja in si pumpa ego.

mr_chai je 22. jun 2022 ob 15:53 izjavil:

Kuall, tudi ta tvoja rešitev je slaba.

imaš boljšo? nalimaj, ne da samo lajaš, bom tisto uporabljal, če je res boljše. razen identity/autoincrement, kar je očitno seveda boljša rešitev, ampak včasih rabiš tudi to.

Saj smo ti zgoraj omenili. Na evo ti nalimam to kar bi moral HotBurek narediti pri svoji tabeli. Primer iz Postgresa.

      CREATE TABLE kurceva_tabela( 
      id INTEGER PRIMARY KEY GENERATED ALWAYS AS IDENTITY, 
      neki TEXT,
      created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());

It to je vse kar on rabi, če bi ga dejansko pozorno prebral, bi videl, da bi on rad samo sortiral podatke po datumu kreiranja vrstic v tabeli. In on se je problema lotil na napačen način, hotel je namreč dobiti vrstni red vstavitve podatkov z generiranjem lastnega id-ja. Da greš pa sam poizkušat implementirat nekaj kar ima baza že interno implementirano, je pa res malo mimo no.

In povej mi dragi kuall, kdaj bi ti rabil to rešitev tvojo oziroma od HotBureka ? Ti si tisti ki tukaj nekaj brez veze laja. Ravno point našega zgražanja je v tem, da te vajine "rešitve" za vnos podatkov v tabelo ne rabiš NIKOLI!

Sem precej ziher, da dolgi lock v tem primeru povzroči transakcija, ne pa sam insert. Insert ne rabi iskat največjega idja, ker ima stalno pripravljenega naslednjega. Če izbrišeš zadnjo vrstico, ne bo njenega idja dobil naslednji insert, kar je tudi prednost autoincrementa pred nekim skropucalom.
Da nekdo rabi članek, ki mu pove, da ni dobra ideja klicat nek webservis dokler imaš odprto transkacijo, je tudi žalostno.

primer1: firma ima identity številko x in y pozicij zaposlenih. unikatni index na (x,y). y moraš ročno povečati. za y uporabiš mojo kodo. seveda se da drugače organizirati stvari v tem primeru ampak če bi rad, da ima vsak v firmi svojo unikatno zaporedno številko, ki jo ponavadi potem tudi prikazuješ uporabnikom v programu, uporabiš ta način.

Ne. Uporabiš tabelo za firme in tabelo za pozicije, povežeš s FK, pa bo vse avtomatsko štimalo.

Vsi nasveti do zdaj so zanič.

Pravilna rešitev je pohekat M/a/y/ria/SQL source kodo, da bo auto_increment deloval tako kot je tebi vizualno všeč.

Nato v vsak projekt, ki ga delaš dodaš kot req. še lasten server s custom *SQL instalacijo in še več zaslužiš.

Da ne govorimo o tem kako bi te vaše "solucije" delale ko bi imel 5 insertov naenkrat. Pustimo 1000...

kuall je 23. jun 2022 ob 13:45 izjavil:

če insert z identity zaklene celo tabelo to pomeni, da uporablja isti mehanizem kot moja koda.

Nima veze identity ali ne. Vsaj probaj preden razlagaš napačne stvari naprej...

Se pa ne strinjam s tistimi, ki bi odpuščali HotBureke, ker da NIKOLI ne rabiš telovadit z unikatnostjo in da ti vse probleme reši identity. Včasih moraš shranit tudi kakšno "lepše" unikatno zaporedje ali (pol)govorečo šifro in takrat imaš podoben problem.

ena transakcija bo dobila deadlock/timeout, to hočeš povedat? al se sploh ne da to rešit drugače kot z identity kolono?

kuall je 23. jun 2022 ob 15:39 izjavil:

ena transakcija bo dobila deadlock/timeout, to hočeš povedat? al se sploh ne da to rešit drugače kot z identity kolono?

To, da začneš s transakcino ne pomeni da bo katerakoli tabela samodejno zaklenjena. In tudi select sam po sebi ne bo ničesar zaklenil.

Situacija je lahko tudi naslednja:
- seja 1 zažene stavek za max id
- seja 2 zažene stavek za max id
- seja 1 poizkuša zapisati
- seja 2 poizkuša zapisati - zapisa ne zaradi napake

Zato bi moral prvo zakleniti celo tabelo. In potem se greš lahko branje.
Ampak ne zaklepat celih tabel zaradi takih stvari. In tudi max načeloma mora prebrati celo tabelo da sploh vrne vrednoat.

win64 je 23. jun 2022 ob 16:13 izjavil:

In tudi max načeloma mora prebrati celo tabelo da sploh vrne vrednoat.

načeloma spljoh ne, saj imajo idji index. celo tabelo se bere, ko se dela table scan (ni indexa), ne seek (je index). index seek po moje najde v prvem ali drugem poskusu z uporabo max(id), tak da vrne takoj.

Dobro jutro.


Evo, fantje in dekline, sedajle sem pognal dva "masovna" inserta: enega po tastarem (maxid + 1), enega z uuid.

In ne boste verjetli, kakšne so prve ugotovitve. Tista rešitev z uuid je malenkost hitrejša. Od oka za x10, x100. I like it.

Sedaj me pa zanima glede definicije row-a, kamor shranjujete uuid:

- Kater tip uporabljate za ta row?
- Kater index uporabljate za ta tip?

Moj trenutni setup je: varchar(36) tip, ter hash unique index.

Dobivam občutek, da SQL baza sploh ni prava rešitev na kateri bi gradil aplikacijo.