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

Delam iskalnik po spletnih trgovinah.

Zaenkrat en proces zbira url-je in jih vpisuje v tabelo.

Druga dva procesa pa potem download-ata podatke.

In tu je prišlo do težave. Tega sedaj še nisem rešil. Trenutno je v bazi 240.000 produktov, in zaenkrat novih ne dodajam.

Sedaj sem rešil proces buildanja autocomplet-a. Sedaj moram še pofiksat search proces. Tu me malo matra, ker search rezultate na serverju zbildam v html in to vračam kot response. Tu mislim, da server potrebuje kakšno sekundo ali dve. Sem pa omejil rezultate na max 100.

And yes, I know, da "vi" delate tako, da vrnete (json) seznam, in potem JS na klientu zbilda html. Za to bo čas v naslednjem rewrite-u.

Prvi write je tako skoraj pri koncu in bo kmalu čas za public test. Potem pa rewrite.

In s tem, da že v prvo probaš naredit vse idealno, sem zgubil preveč časa, na koncu pa iskalnik kot celota ni delal. Sedaj pa bo.

Dvomim da spletni strežnik potrebuje 2 sekundi da zgenerira HTML iz pripravljenih podatkov.
Iskanje po bazi te heca. Gole baze niso najbolj optimalne za tekstovno iskanje po veliki količini podatkov.
Imaš pa možnost generiranje text index v bazi ali izven nje.

Za tvojo bazo je npr. to https://www.tutorialandexample.com/mysq... (nepreizkušeno na mysql).
Drugače pa recimo, če želiš iskalnik implementirat ločeno od baze:
- https://www.elastic.co/elasticsearch/
- https://lucene.apache.org/

win64 je 30. jun 2022 ob 09:41 izjavil:

Dvomim da spletni strežnik potrebuje 2 sekundi da zgenerira HTML iz pripravljenih podatkov.
Iskanje po bazi te heca. Gole baze niso najbolj optimalne za tekstovno iskanje po veliki količini podatkov.
Imaš pa možnost generiranje text index v bazi ali izven nje.

Za tvojo bazo je npr. to https://www.tutorialandexample.com/mysq... (nepreizkušeno na mysql).
Drugače pa recimo, če želiš iskalnik implementirat ločeno od baze:
- https://www.elastic.co/elasticsearch/
- https://lucene.apache.org/

Manjka ti lock pri branju. Vsaj za SQL server velja, da sta to dve akciji.

INSERT INTO table(id) SELECT id + 1 FROM table ORDER by id DESC LIMIT 1;

Če ti ne uporabljaš pravilno, še ne pomeni, da je šajze. Dela to kar si mu naročil, da dela. V takem primeru moraš preiskat celo bazo in obtežit rezultate (ali pa toliko da imaš zadost dovolj dobrih rezultatov), in po tem sortirat, ne pa po nekem idju, ki ti nič ne pove o kvaliteti rezultata.

Tole je pa rezultat zgornjega kverija:

id|string1       |relevance         |
--+--------------+------------------+
 0|ena dolga kava|0.0000000018859283|
 1|kava          |0.0000000018859283|

Šaj-se.

Ego si pojdi pumpat kam drugam. Hvala.

Kot rešitev sem uporabil UUID. O tem sem tudi pisal.

Autoincrement pa nisem želel uporabiti iz preprostega razloga. In to je, da začne štet pri 1 in ne 0. V configu se to ne da spremenit.

se strinjam s Spura, ravno zarad tega razloga sem svoje komentarje začel na način kakršnga sm začel. Že par let (lahko da pretiravam) je ista zgodba s temi tvojimi temami in se očitno v teh letih nisi kej dost naučil. Ego gor al pa dol.

lol, za take stvari pač ne uporabljaš ne max, ne sekvenc, ne auto increment. Vidim da maš že ideje za naslednje teme.

Čaki mal, zdej se pa že norca delate.

Dobra rešitev problema hitrega in bolj-ali-manj istočasnega vnosa, ki se pojavi ob uporabi maxid + 1, JE tudi autoincrement.


Utk,, število bitov, ki jih imaš na voljo, ne vplivajo na to, da bo autoincrement prvi vnosu kot prvi row vnesel 1(DEC) in ne nule.

HotBurek je 30. jun 2022 ob 14:33 izjavil:

Well, enega briga barva ventilčkov na gumah od avta, drugega pač ne.

Ne vem, v čem je point, da če tebe ne briga za ventilčke na gumah, da se pol zgražaš na une, ki so mu pa pomembni.

Dokler je nekomu pomembna barva ventilčkov, mi je čisto vseeno. Ko bo pa nekdo hotel ventilčke ki dihtajo, hkrati pa ne bi uporabil sivih, zato ker hoče kodrlajsasto sive, je pa pač bedak. Še posebej, če mu s kodrlajsasto sivimi ventilčki avto potegne 10 - 100x slabše.

Razumeš?

HotBurek je 30. jun 2022 ob 13:46 izjavil:

Kot rešitev sem uporabil UUID. O tem sem tudi pisal.

Autoincrement pa nisem želel uporabiti iz preprostega razloga. In to je, da začne štet pri 1 in ne 0. V configu se to ne da spremenit.

Se da pa v source kodi od marije.

HotBurek je 30. jun 2022 ob 15:01 izjavil:

7. Teden dni kasneje uporabim UUID namesto maxid + 1 in lepo poročam o 10x 100x hitrejšem vnosu. I'm happy.

Tega sem spregledal, zdaj mi je pa se manj jasno. Saj to ves, da lahko zapisujes z autoincrementom in potem beres s `select id - 1 from table`, ne?

HotBurek je 30. jun 2022 ob 15:07 izjavil:

Ja. Gre za first world problem.

Tisti, ki ste C/C++ špica, mogoče lahko na hitro pogledate in pokomentirate, zakaj je tako, in če je možno narediti fix.

Evo ti: https://slo-tech.com/forum/t802167/p762...

Tisto z select id - 1 je pa odlična opcija.

Spura je 30. jun 2022 ob 13:08 izjavil:

HotBurek je 21. jun 2022 ob 20:35 izjavil:

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...

To je najbolj debilen od vseh moznih debilnih razlogov zakaj bi sel clovek delat to kar ti delas ali pa kar je kuall pisal. Ne samo da je stokrat pocasnejse, ampak celo ne dela in delas pol neke retrye. Kako ti to ne pove da delas neki narobe? In tudi ce bi delal, kaksen legacy je to. Po cisto vsaki metriki absolutno cvek ideja.

HotBurek je 22. jun 2022 ob 15:18 izjavil:

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

Vsakic je isto: Ti se napacno lotis stvari, potem imas problem, odpres temo, folk ti svetuje da cisto spremenis pristop, ti noces poslusat, potem ti nekdo napise neko "resitev" znotraj teh tvojih idej, ki seveda dela k drek, ti si zadovoljen, ostale pa obtozis da imajo ego. Ubistvu imas ti ego, ker ne preneses nobene kritike svojih idej in si nic ne pustis dopovedat.

Odprl si kup tem za zelo kompleksne searche v SQL kjer je ful pomembn relevance in ordering, a nisi pomislil, da bi za to uporabil kak produkt ki je namenjen temu. Ti ne rabis real-time azurnost vpisanih podatkov, ti ne rabis real-time azuriranih indexov.

ne imet izpadov, bumbarček. jaz sem samo razlagal, zakaj ima napako v čist prvem postu v temi, za razliko od tebe, ki imaš neke izpade zarad svoje švoh psihe. btw takih programerjev je ogromno, ki so nesramni, vzvišeni, in tudi zato izgubijo stranke, ker jih stranke ne morejo gledat. bodo raje gledale enega bureka, ki je bolj ponižen, samo zato, da jim ne bo vsak dan pokbaril dneva. jaz pravim, da je dobro razumet stvari, že zato, da bo lahko debuggiral tujo kodo, ki pa uporablja ta pristop, ki ga je hotel burek v prvem postu. jaz uporabljam identity/autoincrement.

OracleDev je 29. jun 2022 ob 16:21 izjavil:

a bejž, da je hitrej če ne bereš cele tabele ob vsakem insertu.

max(id) ne bere cele tebele. ne govorit neumnosti. drug razlog je za hitrost kot pa branje cele tabele.

Po tvojem izseku je to primer, ko imaš v backupu tabelo z ničlami noter.
In to je še dodaten argument zakaj se ne ustavlja default vrednosti v id-je(0, 00000000-0000-0000-0000-000000000000).
Vsak ki bo videl nič v PK/FK bo predvideval, da to ni podatka. Očitno so enakega mnenja tudi pisci baze.

HotBurek je 30. jun 2022 ob 15:22 izjavil:

Evo, nov dan, nove resnice.

Dejansko se da imet auto_increment in da je prvi row id 0.

Setting: NO_AUTO_VALUE_ON_ZERO
Dokumentacija: https://dev.mysql.com/doc/refman/5.7/en...

Zakaj za boga je važno če se začne z 0 ali se začne z 1. Z id-ji se ja ne boš šel računanja?

Takšen primer je opisan na zgornjem linku:

For example, if you dump the table with mysqldump and then reload it, MySQL normally generates new sequence numbers when it encounters the 0 values, resulting in a table with contents different from the one that was dumped. Enabling NO_AUTO_VALUE_ON_ZERO before reloading the dump file solves this problem.

Samo omenim: select 'insert into ' + table + '(id) values (' + id + ');' from table;

In tabelo lahko vedno dropas.

Evo, fantje in dekline. Dobro jutro.


Poročal bom o težki zadevi, zato tisti, ki se hitro vzneburite ob vsaki manjši napakici: Take it easy.


No, takole. Do pred kratkim sem za id uporabljal: UUDI, VARCHAR(36), BTree unique index. Prilezel sem do ene 700.000 vrstic. Tu pa so se začeli INSERT/UPDATE ukazi izvajat vse preveč po požje.

In sem šel na internete iskat, kako drugi optimizirajo situacijo, kjer je UUID primary key.

Dokumentacija:
https://mariadb.com/kb/en/guiduuid-perf...

Na kratko. Dokumentacija govori o "third part" vrednosti za UUID (verzija 1), ki je vezana na čas, in naj se to vrednost uporablja na začetku vrednosti id-ja. Se pravi, iz UUID vrednosti se naj naredi rewrite, preden se to novo vrednost vnese v tabelo/stolpec. Z namenom, da bodo podatki v index-u razvrščeni naraščajoče glede na čas vnos.

Naslednja stvar, ki je omenjena v dokumentaciji, pravi, da VARCHAR(36) ni ok, in je boljše zadevo konvertat v BINARY(16) format in potem to novo vrednost vnesit kot id. Ta vrednost je sicer (za človeško oko) neberljiva, in jo je potrebno ob branju konvertat nazav v VARCHAR(36).

Tule je še ena spletna stran na to temo: https://stitcher.io/blog/optimised-uuid...


In kaj sem naredil? Well, rekel sem si, da je tole z UUID too much komplikacije & šajse za to, kar jaz delam in rabim, ter seveda uvedel custom id generator rešitev.

Id je tipa VARCHAR(18) in izgleda takole:

000000-0-000000000

Sestavljen iz treh sklopov:

000000 = to je shop_id, pred vnosom naredim LPAD(6)
0 = tu shranim bit, s katerim označim url_type; 0=base, 1=xml, 2=page
000000000 = to je page_id, pred vnosom naredim LPAD(9)

Ko se zgodi INSERT, vem za podatek shop_id in url_type.

Za page_id pa naredim:

# set page id
SET @page_id = -1;
	
# get current max page id
SELECT MAX(`page_id`) AS 'page_id' INTO @page_id
FROM `pages`
WHERE `shop_id` = p_shop_id AND `url_type` = 'page';

# if null then set to 0, othervise add 1 to current id
IF @page_id IS NULL THEN
    SET @page_id = 0;
ELSE
    SET @page_id = @page_id + 1;
END IF;

In ke je najkveč en process per shop_id, SET @page_id = @page_id + 1 ni problem in ne prihaja več do konfliktov za id pri vnosu. Vsak process dela "maxid" znotraj svojega pool-a.

Id potem zgeneriram takole:

# build id
SET @id = CONCAT(LPAD(p_shop_id, 6, '0'), '-2-', LPAD(@page_id, 9, '0'));

In zadeva dela. Trenutno poganjam uvoz (vnešenih je že 250.000 od 700.000), imel sem do max 35 hkratnih processov, več skoraj ne gre, ker je CPU na 100% ali zelo blizu.

Zaenkrat nimam še nobenega error-ja, a morem povedat, da se je INSERT nekoliko upočasnil od začetne turbo hitrosti. We will see.

Pa da ne omenjam te izjemne lepote, ko se id-ji izpišejo:

id                
------------------
000000-0-000000000
000000-1-000000000
000000-1-000000001
000000-1-000000002
000000-1-000000003
000000-2-000000000
000000-2-000000001
000000-2-000000002
000000-2-000000003
000000-2-000000004
000000-2-000000005
000000-2-000000006
000000-2-000000007

Na nivoju. Solid!

driver_x je 19. okt 2022 ob 10:36 izjavil:

Zakaj ID sestavljaš iz ostalih podatkov oz. delaš govorečo šifro?

To smo ga že na prejšni strani vprašali...

Well, obstajata dve opcije, kako klicat row po nekem unique id-ju.

1. Na tabeli je unique index na stolpcu "url", tako da bi lahko uporabljal url string kot ID, ko kličeš single row. Kar pa je, vsaj jaz tako vidim, zelo grdo.

2. Stolpec ID bi z lahkoto odstranil, ter na tabelo postavil UNIQUE INDEX (shop_id, page_id, url_type). Ampak, vsakič, ko bi želel klicat single row, bi moral telovadit s tremi ciframi, namesto z eno.

Kot rečeno, UUID sem uporabljal, a imam občutek, da nekaj ni štimalo (BTree Index, VARCHAR(36)), in bi rabil optimizirat. Tu pa mi ideja, da VARCHAR konvertam v BINARY pred zapisovanjem, potem pred branjem pa konvertam nazaj, ni bila zanimiva. Ter, da v grafičnem vmesniku vidiš neko solato.

In sem šel naprej s to idejo, da ID sestavim iz obsoječih podatkov (številk), kar omogoča, da ima vsak process svoj pool in se telovadba z "maxid" ne prekriva med procesi. ID je lepo berljiv. I like it.

V vednost, stolpci shop_id, page_id in url_type so še vedno tam, isto z podatki kot prej.