Srodne teme
18.08.2001. error 2002:
09.01.2002. pomoc oko foruma
14.08.2002. MySql Probelem
21.10.2002. mysql na slacku
31.01.2003. MySQL i apache
21.01.2003. MySQL problem
28.07.2003. Perl & MySql
01.10.2004. backtracking...
10.08.2003. hill
04.10.2003. php&mysql problem
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Intervju: g. Siniša Milivojević - MySQL AB

[es] :: MySQL :: Intervju: g. Siniša Milivojević - MySQL AB

Strane: 1 2

[ Pregleda: 13852 | Odgovora: 38 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.1.14.vie.surfer.at

Sajt: www.baze-podataka.net


+2 Profil

icon Intervju: g. Siniša Milivojević - MySQL AB28.05.2004. u 00:55 - pre 241 meseci
Za one koji ne znaju, Sinisa Milivojevic je jedan od razvojnih programera MySQL-a i jedan od zaposlenika firme MySQL AB. Potaknut njegovim intervjuom na sajtu linux.co.yu, obratio sam mu se sa zeljom da napravi i jedan intervju sa clanovima ES zajednice, konkretnije onim clanovima koje zanimaju baze podataka, pogotovo open source, kao sto je MySQL.
Sinisa je molbu prihvatio sa odusevljenjem i rekao je, da ga citiram:
"Ja bih bio VRLO pocascen da odgovorim na sva pitanja. O MySQL-u , meni,
open source-u , bilo cemu ..."

Dakle, izvolite postaviti koliko god pitanja zelite, ali da budu smislena i tematski vezana za MySQL i open source, eventualno neko ne preintimno privatno pitanje Sinisi. Zadnji rok za postavljanje pitanja je 04.06., nakon cega ce Sinisa pristupiti odgovaranju pojedinih pitanja.
Sinisa ce na pitanja odgovoriti putem E-Maila, ali ako bude raspolozen, mozda ga nagovorimo i da se uclani na forum i tako pocasti svojim odgovorima MySQL community na ES-u.

Vi ste na redu



[Ovu poruku je menjao Gojko Vujovic dana 28.05.2004. u 04:16 GMT]
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

Gojko Vujovic
Amsterdam, NL

Administrator
Član broj: 1
Poruke: 13651



+165 Profil

icon Re: Intervju sa Sinisom Milivojevicem28.05.2004. u 01:39 - pre 241 meseci
Konstatacija: MySQL zaostaje po performansama na velikim bazama (reda više gigabajta) i uglavnom ne uspeva da iskoristi mogućnosti mašine (slabo se skalira) jer jedan query koliko sam shvatio izvršava samo jedan thread. Sa tačke gledišta korisnika ispada da mysql uopšte nije threaded software.

Q1: Da li je ovo tačno?
Q2: Da li se planiraju neke promene na tom planu?
Q3: Postoji li workaround za ovo koji bi ipak omogućio skaliranje?
 
Odgovor na temu

caboom
Igor Bogicevic
bgd

Član broj: 255
Poruke: 1503
217.26.67.*

ICQ: 60630914


+1 Profil

icon Re: Intervju sa Sinisom Milivojevicem28.05.2004. u 01:47 - pre 241 meseci
zapravo, mozda bi bilo preciznije pitanje u kojoj meri je mysql thread-ovan (svakako verujem da nema paralelizovane subquery-e) i koliko se cesto lock-uje ispod haube i koliko to utice na performanse i pogotovo skalabilnost.
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.1.14.vie.surfer.at

Sajt: www.baze-podataka.net


+2 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB05.06.2004. u 18:57 - pre 241 meseci
Intervju je obavljen, a pitanja i odgovore mozete procitati ispod.

*** O MySQL-u ***

ES:
Reci nam, koju poziciju, po tvom misljenju, MySQL RDBMS zauzima trenutno na trzistu u odnosu na druge OpenSource RDBMS-e, a koju u odnosu na komercijalne?



SM:
Sto se tice pozicije, tu nije potrebno moje misljenje.

Tu brojke sve govore. Trenutno imamo 5 (pet) miliona instalacija u celom svetu, barem onih koji se mogu izbrojati. To su znaci sve instalacije koje su nam prijavljene ili koje Internet firme zaduzene za tu vrstu statistike su u stanju da izbroje.

Trenutno smo po broju instalacija prvi na svetu. Oracle je tu negde, a PgSQL ima manje od milion instalacija.

ES:
Da li MySQL u buducnosti namjerava otkinuti dio kolaca na podrucju Enterprise Business rjesenja ili ce i dalje ostati etiketiran kao baza za male i srednje firme ?


SM:
Mi smo poceli zestoko da se "uguravamo" u enterprise.

Imam za vas jednu informaciju, koja je jos uvek tajna za sve izvan MySQL-a, eto izuzev vas.

SAP aplikacije su prekjuce proradile sa MySQL 5.0 !!!!!!!!!!!!

To znaci da cemo za par meseci poceti da prodajemo SAP sa MySQL-om.

Mi smo jos od 2001. poceli da se uguravamo u taj deo trzista, otkada smo uveli InnoDB.

Nas prodor u enterprise trziste je 2001. - 2002. bio skroman. Od prosle godine su poceli da nas primecuju oni koji su to trzeste smatrali svojim.

Sada imamo dobar deo tog kolaca.

Mi sada imamo nekoliko hiljada klijenata (firmi), koje prodaju svoje enterprise programe strogo na enterprise trzistu i od svake te prodaje mi imamo prihod od licenci, a i od support-a.

Meni licno konkurencija bas na tom trzistu izuzetno godi.

Naime, to obicno ide ovako. Neka ogromna firma, kao na primer, General Motors, razmatra koji RDBMS da usvoji. Naprave aplikaciju koja radi sa dve ili tri baze, ukljucujuci MySQL.

Onda dodju i kazu:" Vi ste 15 % sporiji od baze A i 50 % sporiji od baze B".

To je za mene najveci moguci izazov. Taj posao mnogo volim da radim. Posebno mi prija kada cujem da je konkurencija poslala, nakon mojih optimizacija, tim od vise ljudi da probaju da pospese svoju instalaciju.

Samo ove godine sam imao okrsaje sa konkurencijom u osam ogromnih firmi. Svaki se okrsaj zavrsio nasom pobedom gde smo na kraju bili, u najgorem slucaju, 50 % brzi u proseku.

Pored mene, jos par kolega se bavi ovim poslom, tako da prakticno svake nedelje dovedemo neku ogromnu (vrednosti preko 2 milijarde dolara) i vrlo poznatu firmu.

Sve su to VRLO poznate firme, ali ih ne mogu pobrojati, jer je to poslovna tajna, na cemu nasi klijenti veoma insistiraju.

ES:
Kad bi MySQL prestao da bude OpenSource projekat i da se potpuno komercijalizuje (recimo iznos do $3000 za licencu), kako bi se to reflektovalo na buducnost MySQL-a? Tada bi dobijao vise novca i mogao bi zaposliti vise developera, pa bi i razvoj napredovao. Sa druge strane, OpenSource zajednica bi osudila taj postupak, a mogucu reakciju ne moze niko ni da zamisli. Da li je to uopste moguce ili je to samo neostvariva i nezamisliva pretpostavka?


SM:
Ne. To nije moguce, to je neostvariva i nezamisliva pretpostavka. To bi imalo katastrofalne posledice po MySQL.

Sta bi se desilo ??
Svi oni koji dzabe koriste MySQL bi presli na nesto drugo.

Svi oni produkti za MySQL, koji se sada nude besplatno, i koji toliko znaci i nasim korisnicima i nasim klijentima bi prestali da podrzavaju MySQL. To bi nam otelo jako puno klijenata.

Mozete li vi zamisliti MySQL bez PHP-a, Perl-a i sl ?? Bez MyPHPAdmin-a, MOODSS-a itd ???

Svi kursevi, forumi, news grupe, mailing liste, sve bi to nestalo.

Kada toga nema, i broj klijenata bi se drasticno smanjio.

Cak smo i MySQL Cluster izdali sa GPL licencom iz tog razloga.

Mi smo Open Source iz sebicnih razloga !!!

ES:
Marten Mickos, MySQL's CEO, izjavio je jednom prilikom da se MySQL drzi jednog principa iz 14. vijeka (Occam's razor):"No complexity beyond what is necessary". To bi se moglo tumaciti da MySQL razvija samo one komponente i dodaje samo one dodatke, koje veliki klijenti zahtijevaju, odnosno za kojima postoji najveca potraznja. Da li to onda znaci da postoji neka "komercijalna" klasifikacija na osnovu koje MySQL AB planski odredjuje sta ce se ubaciti u noviju verziju?

SM:
Ne.

Morate razumeti mog prijatelja Mickos-a. Ja mogu da pricam ovde sta god hocu, a on mora strava da pazi sta izjavljuje.

Mi se trudimo, koliko je to moguce, da izigravamo produkt sa manje funkcija od nekih najpoznatijih produkata. Mi jednostavno tu igramo "low profile" igru koliko mozemo, dok im sa druge strane otimamo enterprise klijente maksimalno.

Vi toga najverovatnije niste svesni, ali u pitanju je prilicno opasna igra.

ES:
Koje sve feature (dodatke) ce MySQL imati u buducnosti, kao sto su npr. stored procedures, triggers, views, podrska za XML i sl. ?


SM:
To uglavnom sve imamo.

Stored procedures i views su vec u funkciji u 5.0.

Ja sam sa zadovoljstvom napravio nekoliko bitnih odlika SP (Stored Procedures nap.a.) i ispravio odredjeni broj bagova za iste u zadnjih godinu i po dana. To jednostavno vec sada radi.
Trigeri ce doci za jedno godinu dana u 5.1.

XML export vec sada maksimalno postoji kod svih klijent programa, a import se sada radi za neke GUI produkte.

ES:
Konstatacija: MySQL zaostaje po performansama na velikim bazama (reda vise gigabajta) i uglavnom ne uspeva da iskoristi mogucnosti masine (slabo se skalira), jer jedan query koliko sam shvatio izvrsava samo jedan thread. Sa tacke gledista korisnika ispada da mysql uopste nije threaded software.
Q1: Da li je ovo tacno?
Q2: Da li se planiraju neke promene na tom planu?
Q3: Postoji li workaround za ovo koji bi ipak omogucio skaliranje?



SM:
Ovo je jako lepo pitanje.

Mnogo hvala na istom, jer je to nesto na cemu sada prilicno radimo.

Prvo jedna ispravka. Velika baza nije baza reda vise gigabajta nego vise terabajta. Gigabajti su sada JAKO male baze.

Imamo sada otprilike dvadesetak (a mozda i nesto vise) klijenata koji placaju za support, koji imaju vise od 0.5 TB podataka. Sada kolega i ja pravimo okvir projekta za firmu (jedna od 5 najjacih u svetu) koja planira oko 10 TB.

Sto se tice thread-ova, tacno je da u vecini slucajeva jedan query izvrsava jedan thread. Ima izuzetaka. MyISAM zna da dodaje index ili ispravlja tabelu sa N thread-ova (konfigurabilno) InnoDB zna da radi INSERT / UPDATE / DELETE sa dva thread-a.

To medjutim u ogromnoj vecini slucajeva UOPSTE nije bitno. Za scaling je taj feature prilicno nebitan. Zasto ?? Zato sto u stvarnom zivotu na opterecenim instalacijama imate retko ispod 20 - 100 upita koji se istovremeno izvrsavaju. Sta vam onda znaci izvrsavanje upita u vise thread-ova. Pa koliko to CPU-a imate ??? 40 - 200 ??

Ovo o cemu vi pricate ima smisla samo kod benchmarking-a. E tu ako trci jedan upit, onda je stvarno bitno da se taj isti rasporedi na par thread-ova (threads = niti na srpskom). Ali i ti benchmarci sa pravom ustupaju mesto multi-threaded benchmarcima, kakvi su nasi fork ili super-smack ili najnoviji TPC benchmarks.

Samo sam u jednom slucaju pozeleo da imamo tu funkcionalnost. Radilo se o HP SupreDome masini sa 128 procesora.


ES:
Mnogi kazu da je PostgreSQL baza bolja od MySQL-a. Oba RDBMS-a su OpenSource. Oba RDBMS-a ne rade previse na podrucju marketinga. Kako to onda da je MySQL vise zastupljen u odnosu na PostgreSQL ?


SM:
Ako bi pitali kolege iz PgSQL-a oni se sa vama ne bi slozili. Naprotiv, oni tvrde da je nas marketing agresivan, sto je
tacno.
Mi strava mnogo radimo na marketingu, ali tihom. Svaki dan bar 2 - 3 clanka.

Ja sa time, naravno nemam nista.

Zasto je MySQL vise zastupljen ????

Ja licno mislim zbog jednostavnije instalacije i administracije. I zbog toga sto nama ne treba VAKUUUUUUUUUUM.

ES:
Mozes li opisati par situacija u kojima bi se trebao koristiti MySQL umjesto nekih skupljih RDBMS-a ?
Da obradimo i neki konkretni primjer. Mozes li nam ukratko objasniti, u slucaju da neka firma sa 20-30 zaposlenih ima potrebu za bazom podataka, zasto bi ona trebala koristiti MySQL (ili zasto ne) i koliko novaca godisnje bi ta firma morala izdvojiti za MySQL Commercial licencu + support ?


SM:
Do 2001 bi mogao da opisem gomilu situacija gde bi trebalo koristiti komercijalni software. Danas su to retki slucajevi.

Tesko mogu i da se setim koji.
Recimo, ako koristis aplikativni server, koji ide samo sa bazom A. Ili ako zelis full text search po PDF-u ili RTF-u . I slicno ...
Sto se tice te firme, ako ista ne prodaje software, koji trci sa MySQL-om onda ne treba da da ni dinara za licencu.

Sto se support-a tice, zavisi od toga kakav je support potreban. Imamo siroku lepezu u toj ponudi, od 1000 EURO-a do 50.000 EURO-a.

ES:
Navedi 10 najvecih firmi koje koriste MySQL.


SM:
Vrlo nezgodno pitanje. Mogu navesti samo i iskljucivo one koje su se javno deklarisale u novinama da koriste MySQL. To, nazalost, nisu i one najinteresantnije, koje moram da precutim, iz gore opisanih razloga.

Evo jednog VRLO kratkog spiska. One koje imaju zvezdicu su firme koje zahtevaju da im ja licno pruzam support:

Yahoo
Google
* Intel Corporation
Novell
* Hewlett-Packard
* Sabre
Sun
* NASA
Ericsson
Associated Press

Ponavljam. Najbolja imena nisam smeo da navedem.

Najvise volim da radim sa Intel-om, iz sebicnih razloga. Poklanjaju hardware. Pre dve godine sam dobio dual PIII Xeon, a sada mi stize neki strava IWILL multi-CPU server sa UPS-om itd ........ Za dzabe ....

ES:
Koja je tacno tvoja radna pozicija u MySQL AB i mozes li opisati jedan svoj radni dan?


SM:
Ovo su dva pitanja a ne jedno .... ;o)

Ali, za oba je zajednicko da su se strava menjali od 1998. na ovamo. 1998. nas je bilo troje u firmi, a sada nas je 150.

Poceo sam kao programer, zapravo tacnije kao Developer. Radio sam na dodavanju novih funkcija u serveru, kao na pr. GRANT, UNION's, sub-selects, derived tables, ROLLUP i stotine drugih.

To su bila divna vremena i zeleo bih opet to da radim. Sada za to nema vremena i jedino od programiranja sto radim je ispravljanje bagova, sto mnogo volim da radim.

Sada, nazalost, 90 % mog radnog vremena provodim upravljajuci nasim komercijalnim support-om. Taj support ne podrazumeva samo podrsku klijentima, koji za isti placaju, vec i consulting (remote i on-site), kao i pre-sales support, koji sam gore objasnio.

Onih 10 % koristim za ubijanje bagova u serveru i jednom u dva meseca stignem da dodam i nesto novo.

Sto se tice radnog vremena i to se menjalo.
Prve cetiri godine sam radio 12 - 16 sati dnevno, 7 (sedam) dana nedeljno bez odmora i icega. Nakon toga su stigle posledice u vidu narusenog zdravlja, sto nije ni cudno.

Nakon toga sam poceo da smanjujem i danas sam na 9 - 10 sati denvno, sest dana nedeljno. Ali svaki minut (ima izuzetaka kao ovo pisanije) je iskoriscen sa maksimalnom koncentracijom.

Sta radim. U zadnje vreme najvise e-mail. Kada prodje spam i virus filter, meni stize dnevno izmedju 700 i 1000 poruka, od cega je 25 % nebitno. Ostalo mora da procitam, a na neke i da odgovorim.

Dnevno posaljem izmedju 100 i 250 poruka. Hvala Bogu, te sam "slepi kucac".

Pored toga zurim u debugger, u IRC gde izdajem uputstva, savete i komande kolegama iz support team-a ili diskutujem za kolegama iz development-a. Neki customer-i koji puno placaju mi se javljaju na ICQ.

Pored toga koristim gomilu alata (svi su nasi interni i nema ih u javnosti) na nasim internim WWW stranicama, za support, bagove, klijente itd.

Isto tako, u svakom trenutku sam prikljucen u proseku na 3 masine po svetu, ili jureci neki bug ili pomazuci klijentu.

To je to otprilike. WWW surfanje radim pola sata nedeljno. Zadnji put sam igrao neku igricu pre pet godina.

ES:
Kakvo misljenje imas o MySQL certification programu i uopste o samim sertifikatima ?


SM:
Nemam misljenje o certifikatima. Mi nikoga, na primer, ne zaposljavamo na osnovu certifikata. Svako se kod nas zaposljava nakon testa koji traje najmanje nedelju dana, obicno dve. Ko prezivi ........

Sto se tice MySQL certifikata, mislim da je relativno dobar. Ja sam tu malo pomogao.

ES:
Koju bi knjigu o MySQL-u mogao preporuciti?


SM:
E to znam.

U ormanu imam 20 knjiga koje sam sve dobio besplatno jer sam autorima kobajagi pomagao. Ili nisam ni pomagao, ali me pominju u knjizi u kojoj su o nekom mom produktu, na primer MySQL++, posvetili poglavlje.

Najbolja knjiga je nas Manual, izdao ga (mislim) O'Reilly.
Nakon toga su ubedljivo najbolje knjige mog predivnog druga Paul DuBois-a. Izdaje ih, mislim, Riders.

ES:
Zasto se na logotipu MySQL-a nalazi delfin i zasto je dobio ime Sakila ?


SM:
Ja nisam strucnjak za marketing.


*** Uopsteno + privatno ***

ES:
Da li si upucen u stanje IT branse na podrucju bivse Jugoslavije i kako bi ga trenutno opisao? Sta bi se moglo popraviti da "balkansko" trziste bude perspektivnije?


SM:
Ne znam puno o tome, jer sam u zadnjih 5 godina u Srbiji bio 3 dana.

Samo mogu da govorim na osnovu onoga sto mi kazu moji drugari.
Situacija je i tuzna i ruzna.
Kada najbolji ljudi odu u inostranstvo, onda klince i nema ko da uci.

Situacija je ZNATNO bolja u Hrvatskoj i Sloveniji.
Ne moze informatika u Srbiji da stoji bolje sa takvom privredom i opstim stanjem.

ES:
Kako uskladjujes tzv. "kompjutersku ovisnost" sa bracnim zivotom?


SM:
Ocajno lose. Moja zena me grdi skoro svaki dan. Uvece me odvlaci klestima na veceru oko 11.

Moj licni zivot se desava u par sati pauza i nedeljom. Ali i u tome uzivam neopisivo mnogo.

ES:
Da li si ikad razmisljao o osnivanju vlastite firme i cime bi se ona bavila ?


SM:
Ne. Uopste nemam smisla za biznis. Nismo svi za sve talentovani.
Da stvar bude gora, mislim da bi mi trebalo bar 3 meseca da se presaltam na nesto drugo.

ES:
Kako si ti shvatio OpenSource filozofiju i kako bi ju interpretovao mladjim generacijama?


SM:
Velika je razlika izmedju OpenSource-a i besplatnog software-a.
Prvo je samo filozofija razvoja a drugo je mnogo sire.

O ovome bi mogao da pricam satima, naravno. To ima i prednosti i mane.
Osnovno je to da je vrlo sirok krug ljudi uvucen u razvoj software-a, iako je to u 99 % slucajeva testiranje, ali i to je VEOMA znacajno.
Vrlo sirok krug ljudi testira, predlaze i pravi svoje pratece produkte i usluge koje obogacuju osnovni produkt. Neka vrsta masovne filozofije.

ES:
Navedi nam par komicnih pitanja vezanih za support na koja si morao dati odgovor.


SM:
Ima dosta.
Pre cetiri godine sam prestao da komuniciram sa besplatnim mailing listama, tako da se ovo dole odnosi samo na klijente koji placaju.

Na primer:

"Sta je to JOIN ???"

"Zasto MySQL stane kada iskljucim masinu ??"

"Kako da dobijem C: prompt ??"

"Nakon 16 sati lupanja Control-C moj program je pukao. Zasto ??"

#######################################################

Ako imate jos neko pitanje, komentar i slicno, izvolite ovdje napisati konkretno i jasno.
Da citiram Sinišu:"... Pored toga, ako moji odgovori iniciraju jos neko pitanje, moze i to dodatno. Dakle, dopustam jos jednu kratku rundu...".

Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

Gojko Vujovic
Amsterdam, NL

Administrator
Član broj: 1
Poruke: 13651



+165 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB05.06.2004. u 19:24 - pre 241 meseci
Odlično :) hvala g. Milivojeviću sto je odvojio ovoliko vremena i za nas.
 
Odgovor na temu

caboom
Igor Bogicevic
bgd

Član broj: 255
Poruke: 1503
*.verat.net

ICQ: 60630914


+1 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB11.06.2004. u 23:03 - pre 240 meseci
hokej, posto nam je "dopustena" jos jedna kratka runda, hajde da pretresemo neke zanimljve momente :)

Citat:
Prvo jedna ispravka. Velika baza nije baza reda vise gigabajta nego vise terabajta. Gigabajti su sada JAKO male baze.


sa ovim se sasvim slazem, gigabajti su bazice, ali naime bio sam svedok jednog zanimljivog ponasanja mysql-a nad bazicama. elem, zbog ogranicenja 32bitnih arhitektura koje nije potrebno navoditi desavaju sa izrazito zanimljivi efekti na tabelama >2Gb. naime, ocekivano usporenje, prevazilazi sve granice ocekivanog i desava se da select-i traju >20 puta duze od insert-a, a jos zanimljiviji efekti se desavaju sa update-ovima i alter table-ovima. naravno, ocekivano je da dodje do solidnog pada performansi, ali ovo je odista interesantna pojava, moje pitanje je "zasto?" i "da li postoji neko resenje, ili je problem u arhitekturi mysql-a?". ono sto ne mogu da potvrdim, ali mi se odr. broj ljudi zalilo i na ne preterano dobre performanse na 64bitnim arhitekturama, koliko je to tacno i u cemu je tu problem, ako ga ima, ili su u pitanju glasine? dakle, ovde govorimo o velikim tabelama.

Citat:

Sto se tice thread-ova, tacno je da u vecini slucajeva jedan query izvrsava jedan thread. Ima izuzetaka. MyISAM zna da dodaje index ili ispravlja tabelu sa N thread-ova (konfigurabilno) InnoDB zna da radi INSERT / UPDATE / DELETE sa dva thread-a.


ok, ovo je lep podatak vidljiv iz source-a :)

Citat:

To medjutim u ogromnoj vecini slucajeva UOPSTE nije bitno. Za scaling je taj feature prilicno nebitan. Zasto ?? Zato sto u stvarnom zivotu na opterecenim instalacijama imate retko ispod 20 - 100 upita koji se istovremeno izvrsavaju. Sta vam onda znaci izvrsavanje upita u vise thread-ova. Pa koliko to CPU-a imate ??? 40 - 200 ??


ok, hajde da usporimo. :) ovo vise lici na politicki nego na tehnicki odgovor. obicno pametno tredovane aplikacije implementiraju odr. thread pool gde boss thread (ili koja god da je arhitektura aplikacije) "dodeljuje" odredjenom thread-u zaduzenje. naravno, hyper-thread-ovane aplikacije imaju problema i u sustini rizikuju da ce raditi sporije (400 thread-ova na 1-nom procesoru zaista nije dobra ideja), ali pametno simultano obavljanje poslova stvarno donosi odlicne rezultate. mislim da bi dobar primer bile neke baze iz domena "poslovnih tajni", a tajna je u najosetljivijem delu svake thread-ovane aplikacije aplikacije (pored baratanja sa share-ovanim resursima, mada je i direktno vezana za pomenutu), a to je sinhronizacija thread-ova. ono sto se meni cini, ovako na prvu loptu ne ulazeci u zaista detaljnu analizu sorsa, jeste da mysql ima problema sa mutex-ovanjem na svakom koraku, sto je kul po pitanju thread safety-a, ali neoprezno baratanje istim moze dovesti do dosta praznog hoda, i naravno, pada performansi.
uostalom, zasto bi bilo iskljuceno da imam eto npr. 8, 16, 32, 64 ... n procesora u single image-u? krenimo i sa brojkom 2, kako mysql koristi, eto, 2 procesora? kako ce mysql 5.x raditi po tom pitanju i koji je timeline po pitanju performansi, ako postoji.

Citat:

Ovo o cemu vi pricate ima smisla samo kod benchmarking-a. E tu ako trci jedan upit, onda je stvarno bitno da se taj isti rasporedi na par thread-ova (threads = niti na srpskom). Ali i ti benchmarci sa pravom ustupaju mesto multi-threaded benchmarcima, kakvi su nasi fork ili super-smack ili najnoviji TPC benchmarks.


hopla, hajdmo jos malo da prodiskutujemo o ovome, najlakse je sve pripisati benchmark-ovima. nisam primetio da je mysql bas sampion na vise konkurentnih upita i to bih mozda povezao sa onim sto sam napisao iznad. sto se tice benchmark-a, oni su uvek diskutabilni i subjektivni, pogotovo benchmark-ovi koje izbacuju softverske kuce a ukljucuju njihove proizvode. postoje industijski TPC-H testovi i ja trenutno ne znam za nista relevantnije, ili mozda gresim?
 
Odgovor na temu

neetzach
LDAP specialist, Qindel
Iberija

Član broj: 4825
Poruke: 616
*.vdial.verat.net

Sajt: www.udarnik.net


+4 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB18.06.2004. u 13:30 - pre 240 meseci
Hej, pa sta je s tim drugim krugom pitanja? Ja se ubih nedelju dana prateci, al' nista... Je l' ce biti nekog odgovora ili, da naucimo da zivimo sa MySQL-om i njegovim problemima?
Sve se ponadao da cu da cujem po cemu MySQL moze da parira komercijalnim bazama kad ono... Pih...
What I hear, I forget. What I see, I remember. What I do, I understand. What I screw up, I
master.
 
Odgovor na temu

caboom
Igor Bogicevic
bgd

Član broj: 255
Poruke: 1503
*.vdial.verat.net

ICQ: 60630914


+1 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB18.06.2004. u 13:34 - pre 240 meseci
pa po ceni svakako, ali mene zanima da li moze jos po necemu (dakle, govorimo o tom fiktivnom "enterprajz" trzistu) i naravno -> kada <- posto je kod mysql-a sve u nekoj konstantnoj najavi godinu-dve dana unapred.
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
66.228.70.*



+6 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB18.06.2004. u 13:43 - pre 240 meseci
Dva pitanja od mene:

1)
Citat:
Velika je razlika izmedju OpenSource-a i besplatnog software-a.
Prvo je samo filozofija razvoja a drugo je mnogo sire.

O ovome bi mogao da pricam satima, naravno. To ima i prednosti i mane.
Osnovno je to da je vrlo sirok krug ljudi uvucen u razvoj software-a, iako je to u 99 % slucajeva testiranje, ali i to je VEOMA znacajno.
Vrlo sirok krug ljudi testira, predlaze i pravi svoje pratece produkte i usluge koje obogacuju osnovni produkt. Neka vrsta masovne filozofije


Pošto i sam kažeš da se "širok krug ljudi" koji je uključen u razvoj MySQL-a praktično bavi QA-om i nikad i ne vidi source, kako je to činjenica da je source dostupan uopšte relevantna za vaš razvojni model? Da je MySQL recimo closed source ali i dalje besplatan, koliko bi to imalo uticaja na vaš razvojni proces?

2) Koliko razumem, ti si pravio MySQL++ bibliteku. Koliko je ova biblioteka u praksi prihvaćena? Moj utisak je da "tipični" db developeri smatraju da su MySQL++ i slične biblioteke (DTL, OTL) "previše komplikovani".

Hvala unapred.
 
Odgovor na temu

neetzach
LDAP specialist, Qindel
Iberija

Član broj: 4825
Poruke: 616
195.178.35.*

Sajt: www.udarnik.net


+4 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB18.06.2004. u 18:06 - pre 240 meseci
Uzmimo sledeci slucaj:
- imamo bazicu sa odredjenim brojem tabela od preko 2gb;
- tabele su tipa MyISAM zbog boljih performansi od ostalih tipova tabela;

Problemi:
- u slucajevima kada tabela "pukne" ili treba da se radi izmena tabele (u pitanju su pomenute tabele od 2GB), REPAIR ili ALTER TABLE traju i po nekoliko dana na dvoprocesorskim masinama sa hyperthreadingom - pritom je tabela zakljucana, a mysql proces koristi 100% jednog procesa dok drugi ne radi nista;
- MyISAM ne podrzava dve paralelne operacije nad tabelom, tako da je baza neupotrebljiva dok se radi unos vise miliona redova;
- upita nema mnogo ali su cesto relativno veliki (preko 1 MB), a SELECT je veoma spor, i pritom jedan procesor crkava, a drugi ne radi nista.

Pitanje:
Da li je u planu paralelizacija, npr. da se kao u ovom slucaju koriste OBA (ili vise ako ih masina ima) procesora za ALTER, REPAIR, SELECT i sl. ? (Dakle rec je o paralelizaciji jednog upita)

[Namerno potenciram tabele od preko 2gb jer na 32-bitnoj arhitekturi performanse padaju drasticno]
What I hear, I forget. What I see, I remember. What I do, I understand. What I screw up, I
master.
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.1.14.vie.surfer.at

Sajt: www.baze-podataka.net


+2 Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB13.07.2004. u 21:13 - pre 239 meseci
Neodgovoreno pitanje od korisnika sa nadimkom galisnik:
Instalirao sam mysql 4.1.3 (ima podršku za uft8 character set i kompajliran
collate utf8_slovenian_ci!!). Kreirao sam mali programčić u VB-u (Koristim Win2000 Pro i Serbian Latin tastaturu i Regional settings). Kreirao sam probnu tabelu u test bazi:

CREATE TABLE `probautf8` (
`id` int(11) NOT NULL auto_increment,
`naziv` varchar(50) character set utf8 collate utf8_slovenian_ci NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Unio sam par slogova naredbom:

insert into `probautf8` (naziv) values(convert('čičak' using utf8));

Napravio sam jednostavan upit:

SELECT * FROM probautf8 ORDER BY naziv;

i dobio u Text boxu sledeće:

adžija
ćuran
brašno
czech
dvor
džak
đura
efim
čičak
čoček
čućemo se
franjo
gorila
hajduk
istina
jugo
kljucati
ključ
lašva
Ljubljana
Mrčajevci
ništarija
njuh
Oliver
Pendžer
rukohvat
Severina
sušica
Šakotić
Trogir
Uroš
vozač
zdravlje
žaba

Kao što možete primijetiti sve dobro sortira osim 'č' (vidi ga očigledno kao e sa akcentom) i 'ć' (vidi ga očigledno kao spojeno ae). Da li je greška u mysql-u kod sortiranja ili 'č' i 'ć' nisu dobro prevedeni u utf8 (inače, identično se dobija i bez upotrebe funkcije CONVERT, znači ona je u ovoj priči beskorisna)? Takođe i LJ i NJ ne vidi kao jedno slovo već kao L i J, te N i J, tj. kao dva slova (što doduše nije tako strašno kao sa č i ć).
Pošto je Win2000 već potpuno unicode spreman, greška je u mysql-u, tako bar ja mislim.

Konačno je mySQL ponudio i neko kompajlirano sortiranje koje zadovoljava naše potrebe, ali...
Dakle, ima li neki konkretan odgovor na ovo pitanje?

Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

galisnik
NS

Član broj: 18494
Poruke: 81
*.teol.net



Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB15.07.2004. u 08:18 - pre 239 meseci
Hvala StRiPy
Činjenica je da je sortiranje nacionalnog alfabeta važna stvar prilikom odabira DB-a, i da je kvalitet neke DB i time određen (koliko nacionalnih alfabeta podržava kroz character set i opcije sortiranja).
Kada će mySQL imati punu podršku (kompajliranu) za naše sortiranje?
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB07.08.2006. u 18:44 - pre 214 meseci
Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

To ne mogu u potpunosti da opravdam. Delimicno opravdanje mi moze biti samo to
sto sam u medjuvremenu napredovao do polozaja tehnickog direktora podrske za
ceo svet i to sto nam je, u medjuvremenu, broj klijenata narastao vise od pet
puta.

Bice odgovora, bice ... evo upravo pocinjem ...
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 15:45 - pre 214 meseci
Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

Dakle, imamo sledece pitanje:

> sa ovim se sasvim slazem, gigabajti su bazice, ali naime bio sam svedok jednog zanimljivog ponasanja mysql-a nad bazicama. elem, zbog ogranicenja 32bitnih arhitektura koje nije potrebno navoditi > desavaju sa izrazito zanimljivi efekti na tabelama >2Gb. naime, ocekivano usporenje, prevazilazi sve granice ocekivanog i desava se da select-i traju >20 puta duze od insert-a, a jos zanimljiviji efekti > se desavaju sa update-ovima i alter table-ovima. naravno, ocekivano je da dodje do solidnog pada performansi, ali ovo je odista interesantna pojava, moje pitanje je "zasto?" i "da li postoji neko > resenje, ili je problem u arhitekturi mysql-a?". ono sto ne mogu da potvrdim, ali mi se odr. broj ljudi zalilo i na ne preterano dobre performanse na 64bitnim arhitekturama, koliko je to tacno i u cemu je tu problem, ako ga ima, ili su u pitanju glasine? dakle, ovde govorimo o velikim tabelama.

Gore opisano ponasanje mi nije nepoznato. Takvi slucajevi nam se pojavljuju par puta tokom godine dana. Dakle, od desetine hiljada slucajeva koje obradimo, pojavi se par njih koji bi, manje
ili vise odgovarali onom gore.

To ponasanje je totalno atipicno i vezano je za ocajno lose konfigurisani MySQL ili operativni sistem ili za probleme u hardware-u. Vrlo cesto je to problem na Linux-u, kada administrator ima tu nesrecu da MySQL koristi NPTL biblioteku za niti. Kako MySQL se oslanja jako mnogo na niti, svaki problem ili nestabilnost u toj biblioteci se reflektuje na MySQl. Prelazak sa NPTL na LinuxThreads u 90 %
slucajeva resava ovaj problem . Na zalost, NPTL je i dalje pun bagova, koje smo mi upravo poceli da prijavljujemo.

Pored NPTL-a, tu i tamo se desava losa konfiguracije ili fragmentacija.

Sve su to pomalo smesne stvari kada imate u vidu da trenutno imamo oko 300 klijenata koji placaju podrsku, a da imaju baze preko 5 Tb. Od njih preke 30 ima prek 20 Tb. Itd ...

Trenutno razresavam probleme odrzavanja tabela za neke velike firme, tabele od 0.5 - 1.5 Tb. Kada citam ovo pitanje za 2 Gb, iskreno se nasmejem.

Sledece pitanje:


> ok, hajde da usporimo. :) ovo vise lici na politicki nego na tehnicki odgovor. obicno pametno tredovane aplikacije implementiraju odr. thread pool gde boss thread (ili koja god da je arhitektura > aplikacije) "dodeljuje" odredjenom thread-u zaduzenje. naravno, hyper-thread-ovane aplikacije imaju problema i u sustini rizikuju da ce raditi sporije (400 thread-ova na 1-nom procesoru zaista nije > dobra ideja), ali pametno simultano obavljanje poslova stvarno donosi odlicne rezultate. mislim da bi dobar primer bile neke baze iz domena "poslovnih tajni", a tajna je u najosetljivijem delu svake > thread-ovane aplikacije aplikacije (pored baratanja sa share-ovanim resursima, mada je i direktno vezana za pomenutu), a to je sinhronizacija thread-ova. ono sto se meni cini, ovako na prvu loptu ne ulazeci u zaista detaljnu analizu sorsa, jeste da mysql ima problema sa mutex-ovanjem na svakom koraku, sto je kul po pitanju thread safety-a, ali neoprezno baratanje istim moze dovesti do dosta praznog hoda, i naravno, pada performansi.
> uostalom, zasto bi bilo iskljuceno da imam eto npr. 8, 16, 32, 64 ... n procesora u single image-u? krenimo i sa brojkom 2, kako mysql koristi, eto, 2 procesora? kako ce mysql 5.x raditi po tom pitanju i koji je timeline po pitanju performansi, ako postoji.

MySQL nije zasnovan na thread pool-u. kod MySQL je prilicno jednostavno. Jedna konekcija = jedan thread. To je uradjeno iz vise razloga, od kojih je mozda najvazniji onaj vezan za "deeply embedded" MySQL kako sada trci na mnogim ruterima, POS sistemima, i mnogim programima (na primer komercijalna verzija Adobe Acrobat 10). Dakle, gornji opis pool-a ne vazi za MySQL.

Sto se tice problema sa mutex-ima i usporenja zbog istih, toga je naravno bilo, ali sada je to naravno uglavnom istorija. Ostala su samo dva problema usporenja kod mutex-a i to oba kod InnoDB-a.

Jedan je vezan za auto_inc kolonu, a drugi za slucajeve kada imate preko 1.000 simultanih transakcija koje dovode do preko 500 do 8.000 komandi u sekundi. Na svu srecu, imamo par olaksica:

*) takvih klijenata je relativno malo

*) Do kraja godine ce oba problema biti resena ...

Necete verovati, ali pokusali smo da resime te probleme na drugi nacin, ali se ispostavilo da je 90 % tih resenja sporije od mutex-a !!!!!!!

Ukratko, MySQL nema vecih problema sa mutex-ima. Bilo ih je dok su thread biblioteke bile u samom povoju, ali u poslednjih 4 - 5 godina malo ....

Sto se tice 2 procesora, MySQL ce koristiti oba ako ima najmanje dve konekcije. Ili ako imate jednu konekciju sa InnoDB tabelom (tabelama) i u istu radite INSERT/DELETE/UPDATE ili slicne
operacije. Imamo klijente i sa 96 procesora, i verujte da ih MySQL sve, ali sve sasvim lepo koristi.

Ono sto tu treba znati, JAKO DOBRO ZNATI, je kako konfigurisati i MySQL i operativni sistem, pa i hardware.

> hopla, hajdmo jos malo da prodiskutujemo o ovome, najlakse je sve pripisati benchmark-ovima. nisam primetio da je mysql bas sampion na vise konkurentnih upita i to bih mozda povezao sa > onim sto sam napisao iznad. sto se tice benchmark-a, oni su uvek diskutabilni i subjektivni, pogotovo benchmark-ovi koje izbacuju softverske kuce a ukljucuju njihove proizvode. postoje industijski > TPC-H testovi i ja trenutno ne znam za nista relevantnije, ili mozda gresim?

Hvala Bogu, i tu ste potpuno u krivu !!!!!!!

Sva sreca , MySQL jeste sampion u benchmark rezultatima sa N istovremenih konekcija.

Prvo, mozete pogledati neke od TPC benchmark-a koji imaju N konekcija i tu smo brzi od, na pr., Oracle-a.

Zatim, tu su benchmark rezultati iz standardnih SPEC domain-a. Tu smo u proseku brzi 20 % od Oracle-a. Ovi rezultati su stampani na SPEC WWW sajtu .....

Na kraju, mi imamo neke nove rezultate koje cemo da stampamo. Ja bi taj PDF fajl da upload-ujem, kako bi svi ucesnici mogli da ga prostudiraju, ali ne vidim gde se to i kao radi na ovom sajtu.

Da napomenem da sam trenutno konsultant na trenutno najpoznatijem projektu Evropske Unije koji se bavi sa satelitima. Sami pogodite o cemu pricam. Izabrani smo za taj projekt ne samo zbog
stabilnosti nego i zbog performansi. Na tom projektu u 8 tabela istovremeno trenutno postizemo 40.000 INSERT komandi u sekundi u 20 paralelnih niti.



[Ovu poruku je menjao misk0 dana 09.08.2006. u 11:34 GMT+1]
Prikačeni fajlovi
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 15:48 - pre 214 meseci
Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

Trenutno moj posao najvise ukljucuje pomaganje klijentima da predju sa komercijalne baze na MySQL ili sam ukljucen u dobijanje poslova, gde ja cinim da postignemo najbolje rezultate, te mogu stvarno da kazem da ima jako malo toga gde neka komercijalna baza moze da nam konkurise.


[Ovu poruku je menjao misk0 dana 09.08.2006. u 11:35 GMT+1]
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 15:49 - pre 214 meseci
Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

Sto se tice "Enterprise" trzista, trenutno isti cine 40 % naseg prihoda.

Mislim da je to dovoljan odgovor.



[Ovu poruku je menjao misk0 dana 09.08.2006. u 11:35 GMT+1]
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 15:57 - pre 214 meseci
Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

1) Pošto i sam kažeš da se "širok krug ljudi" koji je uključen u razvoj MySQL-a praktično bavi QA-om i nikad i ne vidi source, kako je to činjenica da je source dostupan uopšte relevantna za vaš razvojni model? Da je MySQL recimo closed source ali i dalje besplatan, koliko bi to imalo uticaja na vaš razvojni proces?

Da odgovaram na ovo pitanje pre tri godine, rekao bi da je strasna razlika.

Danas je ta razlika neznatna. U medjuvremenu su svi oni koji su bili izuzetno talentovani, citali nas kod i slali nam patch-eve prakticno zaposleni u MySQL-u .....;o)

Danas bi ta razlika izmedju besplatnog software-a i Open Source software-a bila mala, da nema jednog bitnog detalja. GPL licenca. Ta licenca zahteva Open Source, i zahvaljujuci toj licenci
prihodujemo puno od komercijalnih licenci. Ako ti nije jasno kako, pitaj ....

2) Koliko razumem, ti si pravio MySQL++ bibliteku. Koliko je ova biblioteka u praksi prihvaćena? Moj utisak je da "tipični" db developeri smatraju da su MySQL++ i slične biblioteke (DTL, OTL) "previše komplikovani".

MySQL++ je jako puno prihvacen u single-thread aplikacijama. Problem su multi-thread aplikacije, jer C++ exceptions nisu thread-safe. Bice 2010, ali ko ce da ceka toliko.

Sto se tice komplikovanosti, C++ API je MNOGO jednostavniji za koriscenje od C API-ja.



[Ovu poruku je menjao misk0 dana 09.08.2006. u 11:37 GMT+1]
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 16:04 - pre 214 meseci
Imamo sada sledece pitanje:

---------------------------------------------------------------------------
Uzmimo sledeci slucaj:
- imamo bazicu sa odredjenim brojem tabela od preko 2gb;
- tabele su tipa MyISAM zbog boljih performansi od ostalih tipova tabela;

Problemi:
- u slucajevima kada tabela "pukne" ili treba da se radi izmena tabele (u pitanju su pomenute tabele od 2GB), REPAIR ili ALTER TABLE traju i po nekoliko dana na dvoprocesorskim masinama sa hyperthreadingom - pritom je tabela zakljucana, a mysql proces koristi 100% jednog procesa dok drugi ne radi nista;
- MyISAM ne podrzava dve paralelne operacije nad tabelom, tako da je baza neupotrebljiva dok se radi unos vise miliona redova;
- upita nema mnogo ali su cesto relativno veliki (preko 1 MB), a SELECT je veoma spor, i pritom jedan procesor crkava, a drugi ne radi nista.

Pitanje:
Da li je u planu paralelizacija, npr. da se kao u ovom slucaju koriste OBA (ili vise ako ih masina ima) procesora za ALTER, REPAIR, SELECT i sl. ? (Dakle rec je o paralelizaciji jednog upita)

[Namerno potenciram tabele od preko 2gb jer na 32-bitnoj arhitekturi performanse padaju drasticno]


-----------------------------------------------------------------------------

Prvo, MyISAM je brzi za neke sheme i upite .... za druge je brzi InnoDB ...

Sto se tice brzine REPAIR / ALTER , sada se moze raditi sa do 16 paralelnih procesa.

Ali to ubrzanje je manje od onoga ako uspes da izkonfigurises Mysql da koristi drugi algoritam izgradnje indeksa ..

Brzi algoritam + izgradnja indeksa sa N thread-ova smanjuju vreme cekana za 10 - 30 puta ..

Sto se tice pristupa MyISAM tabeli dok se ova popravlja, to vec sada radi, jedino nije moguce koristiti indekse ....

Sto se tice tabela od 2 gb na 32 -bitnoj arhitekturi, taj mi problem nije poznat izuzev kod starih filesystem-a ...





[Ovu poruku je menjao misk0 dana 09.08.2006. u 11:38 GMT+1]
 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 16:20 - pre 214 meseci

Izvinjavam se svima sto nisam ranije odgovorio na pitanja.

To ne mogu u potpunosti da opravdam. Delimicno opravdanje mi moze biti samo to
sto sam u medjuvremenu napredovao do polozaja tehnickog direktora podrske za
ceo svet i to sto nam je, u medjuvremenu, broj klijenata narastao vise od pet
puta.

Imamo ovo pitanje :


----------------------------------------------------------------------------------------------
Instalirao sam mysql 4.1.3 (ima podršku za uft8 character set i kompajliran
collate utf8_slovenian_ci!!). Kreirao sam mali programčić u VB-u (Koristim Win2000 Pro i Serbian Latin tastaturu i Regional settings). Kreirao sam probnu tabelu u test bazi:

CREATE TABLE `probautf8` (
`id` int(11) NOT NULL auto_increment,
`naziv` varchar(50) character set utf8 collate utf8_slovenian_ci NOT NULL default '',
PRIMARY KEY (`id`),
UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Unio sam par slogova naredbom:

insert into `probautf8` (naziv) values(convert('čičak' using utf8));

Napravio sam jednostavan upit:

SELECT * FROM probautf8 ORDER BY naziv;

i dobio u Text boxu sledeće:

adžija
ćuran
brašno
czech
dvor
džak
đura
efim
čičak
čoček
čućemo se
franjo
gorila
hajduk
istina
jugo
kljucati
ključ
lašva
Ljubljana
Mrčajevci
ništarija
njuh
Oliver
Pendžer
rukohvat
Severina
sušica
Šakotić
Trogir
Uroš
vozač
zdravlje
žaba

Kao što možete primijetiti sve dobro sortira osim 'č' (vidi ga očigledno kao e sa akcentom) i 'ć' (vidi ga očigledno kao spojeno ae). Da li je greška u mysql-u kod sortiranja ili 'č' i 'ć' nisu dobro prevedeni u utf8 (inače, identično se dobija i bez upotrebe funkcije CONVERT, znači ona je u ovoj priči beskorisna)? Takođe i LJ i NJ ne vidi kao jedno slovo već kao L i J, te N i J, tj. kao dva slova (što doduše nije tako strašno kao sa č i ć).
Pošto je Win2000 već potpuno unicode spreman, greška je u mysql-u, tako bar ja mislim.

Konačno je mySQL ponudio i neko kompajlirano sortiranje koje zadovoljava naše potrebe, ali...
Dakle, ima li neki konkretan odgovor na ovo pitanje?

----------------------------------------------------------------------------------------------

To su stari, vec odavno reseni problemi.

Prvo, ne treba uzeti slovenacko sortiranje, vec hrvatsko.

Ovo sortiranje je bag u verziji 4.1.3 ... probajte 4.1.21 ...

Sto se tice LJ i NJ, ponavljam, birajte hrvatsku kolaciju.

Srpske kolacije nema !!!! Ima sve zivo, i tursko i jermensko i deset korejskih i japanskih ...

Zasto nema srpske kolacije ????

Niko nije uzeo da je napravi .... Hrvati su napravili svoju, turci svoju itd .... a u celoj Srbiji nema zive duse koja moze to da izvede.

Ja ne koristim nasa slova, a imam i pametnija posla.

 
Odgovor na temu

sinisami
Sinisa Milivojevic
Cyprus

Član broj: 102117
Poruke: 15
87.228.216.*

ICQ: 24571262


Profil

icon Re: Intervju: g. Siniša Milivojević - MySQL AB08.08.2006. u 16:29 - pre 214 meseci
Odgovor u vezi pitanja kada ce imati naseg alfabeta.

Nas alfabet je u potpunosti podrzan. Ono sto nije podrzano je sortiranje, to jest nema srpske kolacije. Ako koristite latinicu, hrvatska kolacija je podrzana i to u potpunosti. Dva hrvata su sela i izkodirala kolaciju.

Mi u MySQL-u sami kodiramo kolacije za one zemlje gde imamo korisnike koji placaju.

U Srbiji niko ne placa, ali MySQL je open source, pa sedite i kodirajte do mile volje !!1

Ako je u redu, vas kod ce biti uvrscen i bicete pomenuti u kodu.

 
Odgovor na temu

[es] :: MySQL :: Intervju: g. Siniša Milivojević - MySQL AB

Strane: 1 2

[ Pregleda: 13852 | Odgovora: 38 ] > FB > Twit

Postavi temu Odgovori

Srodne teme
18.08.2001. error 2002:
09.01.2002. pomoc oko foruma
14.08.2002. MySql Probelem
21.10.2002. mysql na slacku
31.01.2003. MySQL i apache
21.01.2003. MySQL problem
28.07.2003. Perl & MySql
01.10.2004. backtracking...
10.08.2003. hill
04.10.2003. php&mysql problem
Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.