SQL inner join

Kolk je pa polj? včasih zna pomagat že to da namesto select * navedeš samo eno polje - v tvojem primeru a.id.

V večji tabeli sta 2 polji, v manjši samo ID.
Index je na obeh primarni na ID.
Obe tabeli sta na MyISAM, ker ne rabim zaklepanja, pa logov, pa podobnih zadev.

* je fuj, tako kot je napisal klemenSLO.

Probal pri sebi, sicer postgres, v dveh velikih tabelah (25 in 15 milijonv) pa je vzelo 25 sekund.

steev je 28. dec 2017 ob 16:00 izjavil:

Koliko je to celo večnost?

Sem nastavil timeout na 3000 s pa ni šlo.

Kateri podatkovni tip je a.id in b.id? Koliko pomnilnika porabi mysql med poizvedbo?

Zelo bo pomagalo če namesto * selektiraš samo polja ki so v indeksu i.e. polje ID, enkrat.
Tako zadeva sploh ne bo dostopala do tabel ampak samo do obeh indeksev.
Ker nimaš nobene dodatne omejitve bo delal full index scan kar pomeni da bo prebral cel index. Splača se query obrnit tako, da bo prebral cel manjši index in njegove ključe iskal po večjemu. In ne obratno.

Predvidevam, da je polje ID v obeh tabelah navadna številka, kar pomeni da mora prebrat nekaj sto megabajtov, kar tut za čistonavaden HDD ni noben problem in bi moralo bit fertig v roku nekaj minut.

Če se ti vmes seveda ne vpleta nekaj čisto tretjega.

znakovni, 45 znakov.

Tle se začne tvoj problem.

Seveda pomaga index.

A mySQL ma EXPLAIN ANALYZE?

WarpedGone je 28. dec 2017 ob 18:53 izjavil:

znakovni, 45 znakov.

Tle se začne tvoj problem.

Ampak drugače ne gre.
Ker podatke dobim v CSV datoteki, za obe tabeli.
In potem bulk insert, pa obdelava (join).

Jure14 je 29. dec 2017 ob 07:25 izjavil:

WarpedGone je 28. dec 2017 ob 18:53 izjavil:

znakovni, 45 znakov.

Tle se začne tvoj problem.

Ampak drugače ne gre.
Ker podatke dobim v CSV datoteki, za obe tabeli.
In potem bulk insert, pa obdelava (join).

Pa maš primer idja? Je integer ali ne?

Ideja je, da bi se dnevno uvažalo iz CSVjev in delal presek.

Pomožna ideja je, da bi dnevno dodajal samo v tisto manjšo tabelo,
ta drugo (trenutno večjo) pa bi dnevno praznil in imel notri samo zadnji uvoz iz CSVjev.
S tem izgubim sicer nekaj zapisov iz preseka, ampak je to sprejemljivo.

Sedaj pa še en razmislek:
če bi delal na ta pomožni način, ali je potem smiselno, da tista tabela, ki bi stalno rastla, sploh ima index?
Bi pa imel index na tisti, ki bi se dnevno praznila.
In potem naredim join
select * from prva where id in (select iz druge)

A si pravilno predstavljam, da bo zadeva naredila scan čez prvo tabelo (neindexirano) in iskala (po indexu) v drugi tabeli?

Dodatno: lahko naredim, da je tista dnevna (druga) tabela velika kak GB. In bi lahko v pomnilniku bila za čas poizvedbe.
A lahko join naredim, da bo ena tabela iz joina v pomnilniku, za hitrejše delovanje.

A si pravilno predstavljam, da bo zadeva naredila scan čez prvo tabelo (neindexirano) in iskala (po indexu) v drugi tabeli?

Ne.

Dokler baze ne vprašaš točno kako namerava izvest konkreten SQL, ne veš kako ga nemarava izvest - takšen ali drugačen EXPLAIN.

Hashmap ... po možnosti v kakšni javasranjeimplementaciji ...

I'm outahere.

smacker je 29. dec 2017 ob 11:21 izjavil:

Daj malo bolje opiši problem, ker če rabiš samo presek iz dveh CSV datotek, se to z hashmapom da rešit hitreje kot pisanje 120miljonov zapisov v bazo.

EXPLAIN

Torej:
2 CSV datoteki, dnevno se dodajajo zapisi v obe. V eno malo hitreje kot v drugo.
V eni je samo ta niz 45 znakov,
v drugi je en stolpec ta niz 45 znakov, drugi stolpec pa je podatek (tudi ena klobasa znakov).

Jaz bi rad občasno pognal neko zadevo (ker ne vem kako drugače, sem probal z uvozom v SQL in join), da mi vrne vrstice, kjer se tistih prvih 45 znakov ujema.

smacker je 29. dec 2017 ob 12:03 izjavil:

Hashmap

Se mi je zdelo, da je to nekaj v pomnilniku.
Kaj pa če je podatkov 30GB? Pomnilnika pa 8?

Kaj misliš, kaj je SQL index?

Lahko je marsikaj, hashmap je le ena (redka) možnost. Neki je uporaba orodja ki stvar že ima ornk implementirano, neki druzga pa ubadanje s polizdelki in peglanje nebroja njihovih problemov.

>> Kaj pa če je podatkov 30GB? Pomnilnika pa 8?
Irelevantno, 100% obdelava se zgodi v pomnilniku. Ali bo zadeva najprej komplet vse prebrala v pomnilnik, ali bo brala sproti je na končnem času vseeno. Razlika lahko nastane šele ko do istega podatka dostopaš več kot enkrat - kolikokrat se bo stvar prebrala v pomnilnik.

Ali so ključi vsaj v eni datoteki unique?
Če niso, kolikšen % je število enoličnih vrednosti glede na celoto?
Ali maš MySQL postavljen samo v ta namen ali je to že neki kar imaš v druge namene?

Na koncu to bo stvar mogu narest nekdo, ki ve kaj in s čim točno to dela.

Če lahko, dej oba fajla zazipaj in jih obesi nekam od kjer ju lahko potegnem dol.
Me resno srbi, kolk hitro lahko stvar našminkam. Če mi rata, dobiš recept.

Da bi kaj napredovalo ne vidim. Ti je že bilo povedano.
V škatlo daj SSD disk če ga še nimaš. Gor naredi en folder in tega poturi v mysql ini file kot tmp file handler. Restart mysql. In skoraj gotovo bo bolje.
Vsa ostala znanost pride na vrsto po tem dejanju - pri tvoji količini podatkov.

T.j. ko stvar zaženeš poglej v mysql procese, in tam ti piše, tvoj sql --> Copying to tmp table on disk
če je disk SSD bo pač hitrejše.

Gor pa obesiš SW ki se 99,99% časa ubada sam s sabo (garbage collection, ...)

Hash tabele uporablja zgoščevalno funkcijo (hash). Pri dodajanju elementov, se s to funkcijo iz keya izračuna index v arrayu, kamor se mora element shranit. Ko delaš poizvedbo ali key obstaja, se s funkcijo zračuna index, kjer se bi element moral nahajt, nato pa se pogleda ali je v arrayu na tem indexu kaj shranjeno. Vse skupaj se rahlo zakomplicira, ker se več različnih keyev lahko preslika na isti index, zato teoretična časovna zahtevnost ni čisto O(1).
Hash table @ Wikipedia