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?

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.

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

Odlično :) hvala g. Milivojeviću sto je odvojio ovoliko vremena i za nas.

hokej, posto nam je "dopustena" jos jedna kratka runda, hajde da pretresemo neke zanimljve momente :)



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.



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



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.



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?

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

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.

Dva pitanja od mene:

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?

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.

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]

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?

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?

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

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]}

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]}

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]}

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]}

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]}

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

Sinisa, odgovaras na temu stariju od 2 godine, ali nije bitno, bolje ikad nego nikad ;)

Mozemo li te ocekivati vise na ES-u?

Ova tvrdnja mi nije jasna. C++ izuzeci generalno uzev jesu thread safe, mada to zavisi od OS-a. Misliš na činjenicu da ne možeš da baciš izuzetak u jednoj niti, a da ga uhvatiš u drugoj?

sinisa, hvala na odgovorima, ali zaista nisu relevantni nakon 2 godine, zar ne? :)

Jedna napomena.

Primetio sam da mi neki od vas salju e-mail.

Molim Vas da, ako imate neko pitanje, da ga postavite ovde na forumu.

Necu odgovarati na e-mail poruke, ali cu odgovarati na dodatna pitanja koja se postave ovde, na forumu.

Svi vi koji me kritikujete za pauzu od dve godine ste potpuno u pravu.

Evo ja se izvinjavam i obecavam da cu biti ovde redovnije, sto upravo i dokazujem.

Kako je u Beckereku ???

Ovo je odgovor na pitanje o C++ exceptions i nitima (threads).

Na zalost, na moju veliku zalost, o ovome bih mogao da napisem doktorsku disertaciju.

Toliko sam se specijalizovao za ovu problematiku da problem prepoznajem u core fajlovima koje je generisao mysqld bez simbola, to jest, gde sve citam u asembleru.

Pogledam puni stack i odmah proverim sa ldd (ako nije Windows). U 90 % slucaja sam u pravu. libstdc++ je ulinkovan !!! Kazem tim jadnicima da koriste nas paket umesto sto
neznalacki prave sami binary. I problem nestane .... Za uvek ...

O cemu se radi ???

C++ exceptions nisu thread safe. To je zato sto biblioteka za niti (threads) ne predstavlja deo C++ jezika. To nije problem OS-a, vec SVIH, ama bas SVIH kompajlera. Taj problem se javlja SAMO kod programa gde se promene desavaju brzo u nizu niti (threads) paralelno. Jednostavno, C++ ne spasave sve potrebne registre i vrednosti da bi C++ exception bili thread-safe. Posledice su stravicne. Nudjene su mi nekoliko puta stravicne pare da resim problem u aplikacijama koje pocinju da kresiraju bez razloga. I ne samo meni. To nije
moguce, jer niti nisu deo C++ jezika, te C++ kompajler ne pravi kod za exception tako da kada se kontekst promeni, izvrsenje koda se nastavlja kako treba.

Kod Jave je nit (thread) deo jezika i tu nema tih problema.

C++ ce dobiti nit kao deo jezika 2009.

Imaš li link na neki malo opširniji tekst o tome? Brzi pogled po Googlu mi daje samo suprotne tvrdnje:

http://h30097.www3.hp.com/cplus/uguexcp.htm
http://msdn2.microsoft.com/en-us/library/4t3saedz.aspx

Odgovor na zadnje pitanje o C++ izuzecima.

Prvo, sto se tice standarda, postojeci C++ standardi ne pominju niti, izuzev nesto malo mutex-e, sto je totalno nebitno. To znaci da je za C++ biblioteka za niti se tretira kao
i svaka druga, kao na pr. JPEG biblioteka. Kod standarda vazi pravilo, da ako se nesto ne pominje, to znaci da je to nesto van standarda. A sto se tice novog standarda, koji ce
imati niti, ima jedan PDF file , Stroustup-ov, koji se moze naci na Net-u. Ne znam tacno gde. Ja sam ga imao, ali sam ga izbrisao.

Sto se tice dokumentovanja, zar ti stvarno mislis da se sve dokumentuje ??

Ocekujes nesto ovako od proizvodjaca kompajlera: "Nas C++ kompajler puca sa C++ izuzecima i velikim brojem niti pod vecim opterecenjem" ???

Primera o tim problemima ima na vecini C++ mailing lista. Pogledaj arhivu MySQL++ liste do pre 4 godine, kada sam prestao da je odrzavam. Link se moze naci negde na nasem sajtu, ne znam gde.

Videces dosta kuknjave o C++ programima koji pucaju a da se ne zna zasto. Videces i moja objasnjenja i obrazlozenja ljudi koji o tome znaju vise nego ja.

A ako si bas zainteresovan, ako hoces, mogu da kada naletim na sledeci core file koji je nastao zbog toga sto je ulinkovan libstdc++, da objavim na ovom forumu assembler i stack trace koji govori vise nego jasno o tome sta se desilo.

A od celog STL-a su ulinkovani samo new i delete operatori, sto je dovoljno ...

Ja sam te slucajeve imao mnogo vise ranije. Sada manje jer ne pruzamo podrsku za mysqld binary koji nije download-ovan sa naseg sajta. Ali se i dalje to desava ...

Prilično pomno pratim comp.lang.c++.moderated news grupu i nikad nisam našao ništa slično na njoj a i nigde drugde, kad smo kod toga. Problemi prijavljeni na MySQL++ listi mogu da znače da postoje problemi u MySQL++ biblioteci, a ne u C++ kompajlerima.

Možeš li da objaviš komad koda koji bi demonstrirao ovu tvoju tvrdnju?

comp.lang.c++ je prilicno losa lista za ova pitanja. Na istoj sam slabo video ozbiljne, velike, komercijalne / open source projekte koji imaju problema sa C++.
Mozda se promenilo, ne znam.

Namerno sam rekao MySQL++ mailing lista, jer su se na istu javljale firme sa upravo tim problemima, a da nisu koristili uopste MySQL++, a neki cak ni MySQL !!!

Primer koda je moguce dati. Evo, ceo mysql source. Ulinkuj ga sa libstdc++ i pusti na instalaciji sa izuzetno velikim opterecenjem (na pr. preko 500 qps) i velikim brojem paralelnih niti (preko 500) i imaces kresing bar jednom nedeljno, pod uslovom da sve to trci 24 sata dnevno. Ulinkuj bez libstdc++ i nece biti problema godinama.

Ocekuje se da ce jedan manji projekt od tog biti izmenjen, oko 2 Mb source-a, da bi se izbacile C++ izuzeci. Kada se to desi, reci cu to na ovom forumu.

Ponavljam. Imao sam sigurno stotine tih slucajeva. Svuda su problemi nestali izbacivanjem STL biblioteke iz MySQL source-a. Bilo je o tome nesto pre vise godina i na [email protected] listi, a imali smo takvo obavestenje i na nasem sajtu.

Nas manual je pun upozorenja u vezi sa time. Na primer:

" This avoids problems with the libstdc++ library and with C++ exceptions. "

ili

" This avoids problems with the libstdc++ library and with C++ exceptions
(many compilers have problems with C++ exceptions in threaded code) and
compile a MySQL version with support for all character sets.
"

Zasto pise "many" a ne "all" ???

Tipicno svedski nacin razmisljanja mog najboljeg prijatelja, Monty-ja Widenius-a. Njegovo obrazlozenje: "Jeste, mi smo probali sve poznate C++ kompajlere na svetu,
ali mozda negde u svetu postoji neki koji nema tih problema ..."

Ne comp.lang.c++, već comp.lang.c++.moderated koja je mnogo ozbiljnija. Na njoj se redovno oglašavaju B. Stroustrup, Sutter, Alexandrescu, Meyers, Boehm... , a i threading gurui kao što je Terekhov i Kempf. Više puta je potezana priča o tome kako je potrebno da se podrška za niti ugradi direktno u jezik, ali iz sasvim drugih razloga - pre svega mogućnosti da se izuzeci bacaju između različitih niti.

Da li bi se usudio da tu svoju teoriju javno obznaniš na toj listi?



To sugeriše problem u libstdc++ biblioteci, a ne kompajlerima.


Ne znam. Ja sam prvi put radio na kompleksnoj MT aplikaciji 2000-te i video sam krahove uzrokovane svim i svačim (između ostalog i lošom STL bibliotekom koju je isporučivao Dinkumware, ali nije reč ni o kakvoj tajni već o poznatim problemima: http://www.dinkumware.com/vc_fixes.html ) ali kad smo jednom sve to pokrpili, aplikacija nam je trčala mesecima bez problema iako smo koristili izuzetke u MT okruženju. Sad radim na drugoj MT aplikaciji u drugom okruženju (Linux i g++) i opet viđam razne probleme ali ništa slično ovome što si opisao.

Jesi li razgovarao o tome sa nekim iz g++ tima?

Imaš li nešto manje? Bojim se da mysql ulinkovan sa libstdc++om ne predstavlja validan test-case za tvoju tvrdnju.

Da jer valjas pokazati da je problem bas do kompajlera, tj. do njegovog generisanja koda. Ovako problem moze biti do te biblioteke.

Posto je ovo MySQL forum, a ne C++ forum, ovo je moj zadnji odgovor na temu C++ izuzetaka.

Pre svega, bilo bi lepo kada bi se citalo ono sto sam ja napisao a ne samo neki detalj. Izmedju ostalih sam citirao nas manual i primedbu o "most" compilers. To "most" je iz naseg direktnog
iskustva sa svim tim kompajlerima.

Dakle, nas kompletan MySQL tim, kao i mnogi drugi koji su se javljali na nasim, je nasao primere pucanja programa sa puno niti pod velikim opterecenjem zbog C++ izuzetaka u jako velikom broju slucaja. Ova dijagnoza je utvrdjena za sve vaznije varijante GNU kompajlera, MS , Sun, IBM, HP i drugih kompajlera u celom nizu njihovih verzija. Neki od nas u MySQL-u, ukljucujuci i mene, smo se
specijalizovali za dijagnozu gresaka u kompajleru, tako da smo do sada poslali poprilicno puno test case-ova na razne adrese, ukljucujuci i g++ tim.

Test case za probleme za C++ izuzetke i niti nismo pravili, iz dva razloga. Prvi je taj da smo problem jednostavno resili izbacivanjem istih. O tome ima i tekst u delu manual-a o UDF funkcijama i C++ , jer cak i C++ izuzeci u UDF funkcijama pod velikim opterecenjem krse MySQL server. Kada se izbace C++ izuzeci, nestaju ti problemi. Zadnji takav slucaj sam imao pre pet meseci.

Drugi razlog je taj da bi pravljenje takvog slozenog primera zahtevalo bar dve nedelje rada, pri cemu bi isti trebalo menjati od verzije do verzije, i od kompajlera do kompajlera. Mi za to nemamo
vremena. Ja sam nasao jedva 10 minuta da ovo sastavim, sa cime zavrsavam temu o C++ izuzecima. Jedino sam spreman da na C++ forumu prikazem asemblerski kod i ostale podatke kao dokaz da je mysql server skrsen iskljucivo zbog C++ izuzetaka (iz new i delete operatora), kada se to desi sledeci put. Kada se za godinu dana pojavi taj novi projekt na kome se sada izbacuju masovno C++ izuzeci, da bi taj server konacno prestao da se krsi, ako budem imao vremena i to cu dati, ali takodje na C++ a ne MySQL forumu.

No hard feelings. Samo, kad neko iznese tako ozbiljnu tvrdnju kao da C++ izuzeci nisu thread-safe, očekujem i neki dokaz za to. To što mysql++ puca je samo dokaz da mysql++ nije thread-safe i ništa više od toga.

BTW, mislim da bi bilo profesionalno sa vaše strane da stavite ovde http://tangentsoft.net/mysql++/ obaveštenje da mysql++ ne treba koristiti u MT okruženju.

Stvarno poslednje pisanije o C++ izuzecima.

Kojesta ...

MySQL server nije MySQL++.

UDF funkcije nisu MySQL++.

Gomila drugih aplikacija , prijavljenih na MySQL++ i generalnoj listi, koje su kresirale i bez koriscenja MySQL++-a, nisu MySQL++.

I posledenje pisanje o tome sa moje strane.

Ako stvarno veruješ u to što pričaš, napiši negde na engleskom tu svoju tvrdnju (najbolje na zvaničnom sajtu MySQL-a) i potpiši se ispod pa mi pošalji link. Smesta ću ga proslediti C++ compiler vendorima i još nekim članovima komiteta za standardizaciju C++a pa da vidimo šta oni imaju da kažu.

Neka kratka uputstva za kreiranje srpskog (latinicnog, i cirilicnog) collation-a? Samo par linkova, da znam odakle da pocnem.

Da je MySQL lose resenje ne bi se o njemu ovoliko pricalo i ne bi ga koristio toliko veliki broj programera tako da ja ne bih na tu temu nego bih zeleo da postavim jedno tehnicko pitanje za Sinisu koje me smara vec veoma dugo:

Imam recimo tabelu t1 i u njoj polja p1, p2 itd.
p1 je primarni kljuc (auto_increment) biginit(20)
p2 je samo biginit(20)

Hocu jednom sql naredbom da izvrsim insert u tu tabelu ali da se u p2 upise ista vrednost koja ce biti upisana u p1 (formirana auto_increment-om)
Naravno od izuzetne je vaznosti da resenje bude potpuno pouzdano i u situaciji da istu bazu koristi 100 usera i da recimo u istom trenutku ima 40-ak konekcija.

Ne mogu p2 podesiti da bude auto_increment jer prilikom izmene zapisa drugacije obradjujem podatke u p2 (u suprotnom naravno p2 i ne bi imalo smisla da egzistira).

Mislim da problem potice odatle sto mysql poslednje upisuje p1 (primarni kljuc - autoincrement) polje i tada mu i formira vrednost tako da uopste ne znam kako ovo da resim a da bude brzo i pouzdano.

Pozdrav,
SJ