Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Polja koja mogu da budu al ne mora da znaci

[es] :: MySQL :: Polja koja mogu da budu al ne mora da znaci

Strane: 1 2

[ Pregleda: 9508 | Odgovora: 31 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

jablan

Član broj: 8286
Poruke: 4327



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 15:20 - pre 373 dana i 14h
Jel može malo više info o "Vodi racuna, kad radis SELECT ID,Sifra,Ime,Cena, a nema covering index - to je isto SELECT *. " pošto mi zvuči prilično čudno? Mislim, jasno je da neće moći da izvuče i vrati podatke iz samog indeksa, ali da li zaista mora da čita SVA POLJA sa diska, da bi ti vratio samo neka?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14219
*.com
Via: [es] mailing liste

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 15:41 - pre 373 dana i 14h
> ali da li zaista mora da čita SVA POLJA sa diska,

da, zavisno od storage engine-a cita ili ceo slog ili ceo page (u kome
je vise slogova), nije mysql izmisljotina, sve osim blobova se nalazi u
slogu i sa diska se cita ceo slog, blobovi se citaju u "drugoj turi" sa
"drugog mesta"..

za pg pogledaj npr
https://www.postgresql.org/doc...tatic/storage-page-layout.html i on
cita uvek ceo slog bez obzira sto vuces samo 1 kolonu (ignorisem
specijalne slucajeve za TOAST)

za mysql, dosta losija dokumentacija:
https://dev.mysql.com/doc/refm...nnodb-row-format-overview.html

ne znam kako radi mssql ali sybase od koga je nastao je citao ceo page
za svaki slog

...

tako da ne znam odakle cudjenje? ako mora da pipne tabelu (nema svu
potrebnu datu u indexu) mora uzme ceo row, teoretski ne mora ali je brze
da uzme ceo

inace mysql ne cida (po defaultu) manje od 1MB nikad sa diska, uglavnom cita ceo page, kesira (innodb_buffer_pool) etc etc .. ima cela prica objasnjena u manualu ali od kad su ga reformatirali nista ne umem tamo vise da nadjem pa me mrzi da trazim link gde sve to pise
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4327



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 15:46 - pre 373 dana i 14h
Jasno. Pitanje je samo da li dodatne kolone tu unose vidljivu razliku po pitanju performansi. I u kom momentu ta razlika opravdava deljenje tabele po vertikali sa svime što to donosi, tj. novi indeksi, novi upiti, JOINovi itd.

http://stackoverflow.com/quest...lumns-affect-query-performance
https://www.percona.com/blog/2...f-columns-affects-performance/
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14219
*.dynamic.sbb.rs.

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 15:57 - pre 373 dana i 13h
nemoj se preterano vezujes za SO tamo ima puno netacnih stvari posebno oko performansi ... (nisam citao taj link tako da mozda sve sto pisu 100% tacno) ali generalno za "dal bolje tante ili kukuriku" ne postoji univerzalni odgovor ... zavisi od slucaja do slucaja... bitno je da nekom bude jasno kako to radi da bi doneo pravu odluku ..

za mysql (da ne ulazim u ostale posto svi rade drugacije) mozes da racunas da on uvek cita ceo page, i taj page kesira, da li ti zelis da kesiras u ramu npr 50% nekih slogova koji ti nikad ne trebaju? podelis tabelu na dve i ono sto ti treba u 1% slucajeva bude kesirano samo 1% puta .. sa druge strane ako ti je valjan index i 90% citanja ti je samo index onda te bas briga i sve strpas u tu jednu tabelu .. ili ako imas 1000 artikala (neko spomenuo tu cifru?) 128G ram masina je danas dzaba ta baza nije cela velika 4-5G cela staje u ram, sto bi delio tabelu na 2 dela i komplikovao sebi zivot ... opet ako pricamo o petabajtnoj tabeli svaki bit koji moze da se ucari znaci ..

tako da ne bih ulazio u to sta je bolje, ja rekoh "najcesce", "veliki broj klijenata" i "ja" modifikovani v4 .. dal je najbolji, znam brdo primera gde bi to bilo samoubistvo, znam primere gde je do jaja resenje ..

jedino sto mogu da kazem "univerzalno", "silver bullet" je DOKUMENTACIJA ... sta god uradis do jaja dobro dokumentuj kako radi, zasto tako radi i zasto si doneo odluku da tako radi i koja si sve druga resenja uzeo u obzir i svako od njih zasto si odbacio, jer ta resenja, svake godine kada se radi review neko ce da predloze "ajmo da promenimo da bude ovako drugacije" .. ako nemas tu dokumentaciju - puno ce te kostati
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 1896

ICQ: 49345867
Sajt: model-m.blogspot.com


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 16:04 - pre 373 dana i 13h
Nije ovo samo do MySQL-a, to definitivno rade sve row-based baze koje znam. Mislim da negde ima dokumentacija da i Oracle baza to radi (velika "oracle database"), to su pricali kad su uvodili columnar support....

Ovaj tekst sa Percona sajta je dobar, mada mator - ali neko moje iskustvo je da, kad imas 200 kolona, prelazak na tabelu od 10 plus drugu od 190 i te kako znaci. E sad, sa 10 ili 15 verovatno ne znaci puno, ali ako projektujes sad, onda bolje da projektujes za dve tabele, pa ce ova druga vremenom narasti do mnogo... opet to je iz nekog mog iskustva. Te stvari se stalno dodaju, kako projekat odmice, a 95% vremena se ne koriste.

Sto se performansi tice, po meni, ako ti 95% vremena ne trebaju sve te kolone, i mala usteda ce ti znaciti, jer stedis na 19 od 20 izvrsavanja - da bi jedno bilo nesto sporije. Po meni to nije los tradeoff.... Ja samo napominjem sad, jer je neke stvari, tipa ovoga, uvek lakse resiti na pocetku, nego posle raditi refactor. :D

Naravno, BLOB u MySQL-u to resava drugacije, sad za 5.7 izlazi i X api (ili kako se zove vec taj javascript fazon api), pa on ima neku json podrsku, sve to ima nesto svoje i neko dodatno resenje za json... Ja pricam samo ako hoces da imas row-based bazu da ima smisla ovo resiti u startu. Pazi, na toj dodatnoj tabeli ti, verovatno, i ne trebaju indexi sem po id-u iz druge tabele, tu ces ulaziti samo kad ti treba, verovatno, ceo slog i to za tacno odredjen artikal. Ono po cemu pretrazujes (cena, ima na lageru i sl). ces verovano drzati u osnovnoj artikal tabeli.
Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4327



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 16:05 - pre 373 dana i 13h
Hvala Bogi, odlični saveti. Inače, nisam linkovao SO kao argument za ili protiv, već kao zanimljivo štivo. Evo ovaj lik (170k+ karma) je benčmarkovao, mada nešto drugačiji slučaj, COUNT(*) nad tabelom bez indexa:

http://stackoverflow.com/quest...query-on?noredirect=1&lq=1

 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14219
*.dynamic.sbb.rs.

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 16:30 - pre 373 dana i 13h
ma da imamo malo vise ovakvih diskusja ovde, ucmao se forum, a i meni se malo vezba komunikacija na srpskom :D ..

elem innodb je uzasan kada je count(*) u pitanju ... uzasi promiskuiteta :( .. a inace razni testovi koliko brzo ce radi "full table scan" su uzasno beskorisni ... prvo tog sto napravi sistem koji radi fts treba neko rokne, drugo, taj sto napravi fts, taj fts nece radi "sam na masini" ka kad to krene da se gomila svi testovi koje si radio mozes bacis u kantu :( .. tako da dal ce neko ustedi 10% brzina za fts ako uradi ovo ili ono, nebitno ...

ne pricam o olapima i postanalizi deep date .. to je sad neka druga prica (i ne vidi zasto bi bilo ko sa 2 grama mozga za to koristio mysql) .. pricam o realnom real time poslu.. kakav upit od 90 sekundi u real time svetu radi posao? koji klijent ce ti saceka 90sec da mu se ucita strana, otvori rezultat na telefonu, aplikaciji .. to jos ove knjihovodje trpe jer ne znaju za bolje, vec ovi mladji zovu i prete tuzbom kad im tako nesto probas uvaliti ..

tako da - fts - ima tu mnogo sta sto moze ali beskorisno

a za normalan pristup .. kada je mysql u pitanju bitno je shvatiti razliku izmedju formata innodb tabela (ako pricamo o innodb-u), i razliku izmedju staticnog i dinamickog sloga i kako se sta gde pise i kada se cita ..

 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 16:30 - pre 373 dana i 13h
Citat:
Pazi, na toj dodatnoj tabeli ti, verovatno, i ne trebaju indexi sem po id-u iz druge tabele, tu ces ulaziti samo kad ti treba, verovatno, ceo slog i to za tacno odredjen artikal. Ono po cemu pretrazujes (cena, ima na lageru i sl). ces verovano drzati u osnovnoj artikal tabeli.


Ma da, bas tako.
A svidja mi se i ovaj inheritance koncept, vec vidim da bih to mogao da primjenim na jednom drugom mjestu, tj. u 2.0 verziji :)
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14219
*.com
Via: [es] mailing liste

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 16:47 - pre 373 dana i 13h
obrati samo paznju, ako to ne pretrazujes, onda moze da bude i u blobu,
koji ne zauzima mesto u tabeli a mozes da ga povuces jednostavno, bez
join-a, kad ti treba a u njega mozes upucas u formatu koji ti je zgodan
za klijent
 
Odgovor na temu

Tyler Durden
Tyler Durden
Beograd

Član broj: 4312
Poruke: 3379
*.63.7.220.vultr.com.



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 18:46 - pre 373 dana i 11h
razmislicu jos, ali nesto ne volim da imam denormalizovanu bazu ako bas nemam neki dobar razlog
Beneath civilization's fragile crust, cold chaos churns...
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14219
*.com
Via: [es] mailing liste

Sajt: mysql.rs


Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 18:55 - pre 373 dana i 10h
a vidi razlog je uvek TCO .. iliti cena ..
denormalizacija ti smanjuje operativne troskove jer ti povecava
performanse pa za manje pare dobijes vise, ali ti povecava troskove
razvoja jer moras da imas dobru dokumentaciju i kada radis promene moras
da konsultujes istu (klasicno dobro normalizovan model je
self-docummented dok kod denormalizacije moras da objasnis sta je sta i
zasto je to tako) ..
 
Odgovor na temu

farmaceut
Apoteka
Banja Luka

Član broj: 182739
Poruke: 55
62.68.101.*



Profil

icon Re: Polja koja mogu da budu al ne mora da znaci14.07.2016. u 21:52 - pre 373 dana i 7h
EAV model ili neka varijanta, iako se cesto ne preporucuje, u tvom slucaju bi mogao biti rjesnje.
Np, ja za medicinskie eviencije koristim neku hibridnu varijantu Bogdanove "v4", gdje neke uobicajene podatke stavljam u "klasicnu" tabelu, a ostatak informacija ide u EAV. Imam oko 500 "entiteta" (razliciti tipovi medicinskih dokumenata) i skoro 20k razlicitih atributa.

I to sljaka odlicno, naravno moras biti svjestan sta radis, i sta su ti ogranicenja....

 
Odgovor na temu

[es] :: MySQL :: Polja koja mogu da budu al ne mora da znaci

Strane: 1 2

[ Pregleda: 9508 | Odgovora: 31 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.