Ari ir testa lauks, kur shito varu experementet uz nebedu, tachu nu ta ka taa ir produkcija, negribas to darit, ja vien neuztaisa backup un nerestore uz citas mysql instances...vienigi tas restore ar visiem indexiem ir riktigs pain in the ass, jo ilgst paris dienas.

ja runa par performanci, tad mans ieteikums (Normalize with zeal, denormalize sparingly) - nezinu gan cik draudziigs mans-siikuels tam ir... jaa atminja nevilj tad 3rd ne paaraak

old school

nu nez vai tur ir daudz ko normalizēt 3 tabulās :D un nedomāju, ka laacz ir tik dumš, ka tur līdz 3. nf nenormalizētus datus un brīnās par lēndarbību..

nu man grūti spriest par optimizēšanu, taču neliekas nopietni uz mysql tāadus datu apjomums, jo mana personīga pieredze ir, ka jau pēc ~150M mysql sāk kārties.. un tas nozīmē meklē ko nopietnāku, no opensource piem postgresql, it kaa nedaudz iebremzē uz mazākiem datu apjomiem, taču nenokaras uz vidējiem lieliem..

vai kāds var padalīties ar kādu labu grāmatu vai vietnu tieši mysql server optimizācijā..

Roze ir "viņš" vai "viņa"?

Viņš, lol.

saldais .. jocīga tev pieredze.

Pēc savas pieredzes māku teikt ka MySQL (jebkuru DBVs) "prasmīgs" koderis var "nokārt" arī ar krietni mazākiem datu apjomiem / ierakstu skaitu.. proti lielākā sāpe parasti ir indeksu neizmantošana, tabulu struktūras un relāciju nekorekta izvēle/izveide, MySQL pamatprincipu/darbības nezināšana (piemēram fakts ka MySQL pie selecta izmanto tikai vienu tabulas indeksu līdz ar to indeksu uzlikšana katram tabulas laukam atsevišķi un tad mēģinot kobinēti atlasīt nekādu labo rezultātu nedos) utt

Kā piemēru varu minēt ka uz doto brīdi konkrēta projekta ietvaros tiek izmantotas arī 200+ Gb (~800milj ieraksti) samērā aktīvas tabulas, kas īpaši nerada nekādas problēmas.. domāju ka ir kapacitāte arī kādu laiku augt (p.s. serveris ir samērā standarta un nekādu fiber disku sistēmu nav). Tai pašā laikā cināmies ar dažiem lietojumiem/sadaļām kur ierakstu skaits nepārsniedz pārdesmit tūkstošus bet DB serveris ir knapi dzīvs..

zb,

es domaaju (iespeejamaas performances uzlaboshanai) preteejo processu i.e. denormalizeet (ir gadiijies to dariit arii vienai tabulai:)

roze, nez par kadu projektu tad tu runa? :) Latvija daudz tadu nav :))

Esmu dzirdējis par kādu diezgan lielu projektu, kurā datu pārnešana no MySQL uz Oracle deva jūtamus ātrdarbības uzlabojumus pat bez pieprasījumu pielāgošanas ...

Tas no operas viena tante teica? Jo idejiski tika izskatīts plāns par šādu rīcību UN savāktie IO / performances dati par tekošō sistēmu pārejai uz Oracle tad nepieciešamā aparatūra lai to vispār sāktu darbināt bija kā minimums virs 200k tugrikiem (ibm p5 + fiber storage).. Es neko sliktu nesaku par Oracle - labs produkts pareizām vajadzībām, bet ir jāsaskata nedaudz atsķīrība - oracle prasa priekš sava enterprise produkta arī enterprise līmeņa dzelžus (savādāk viņi neko negarantē), turpretī MySQLs tiek darbināt principā arī uz visādām miskastēm ;) Tas protams nekādi neatsver mysqla ilglaicīgās problēmas ar multi-cpu sistēmām to skeilošanu utt..

runājot par 1 indexa izmantošanu selectam, jaunajiem mysqliem ir (būs, būšot?) indexu apvienošana(merge) vai tamlīdzīgs process..

ā, un kādi ieteikumi, ja ir tabulas ar TEXT laukiem, kuros vajag meklēt ar LIKE? neko jēdzīgu no mysql neizdevās izspiest jau pie 1Gb lieliem datiem. nācās uztaisīt skriptu, kas sadala datus pa mazām tabuliņām un pēctam taisa "merge" tabulu ..

Jā kopš kaut kādas 5.1.x (varbūt arī 5.0) saucās Index Merge http://dev.mysql.com/doc/refman/5.1/en/index-merge-optimization.html

DB kā search engine jau neder pasen (atslēgas vārdi ir datu indeksēšana) un tam jāmeklē kādas fulltext searcheris.. Hints varētu būt Sphinx (google for it).

jā, Sphinxu pamanīju, nav grūti to pamanīt, jo visur tas ir pieminēts, kur tiek runāts par FULLTEXT indexu bremzēšanu. bet kāpēc neko tamlīdzīgu nevarēja iebūvēt mysqla indexu padarīšanā. ?

Roze, MySQL pie selecta izmanto vienu indexu arii ja ir 2 where clauses un uz katru attieciigo lauku ir index ?

imho, kaut kas speeciigaaks par MySQL buutu jaaizmanto ja projekts ir paaraudzis videejas web-page liimeni, bet tas ir tikai imho :)

Un nav Oracle lietoshana tik daarga. Taa ir taada stulba dogma tautaas iegaajusies. Nu nevajag uzreiz p5 un uber disku masiivus. Datu baazes performance ir vislielaakaa meera atkariiga no DB adminiem un aplikaacijas/db struktuuras developeriem. Runaajot par tiem pashiem indexiem, Oracle piedaavaa vairaakas iespeejas. Indexu tipi vien ir vismaz 3 - bitmap, b-tree, hash indeksi. Katrs no tiem ir labaaks specifiskaa gadiijumaa.

j: Nu var jautāt kapēc mysqlā nevar iebūvēt uzreiz arī webserveri? :) Vienkārša atbilde "use the right tool for the right job" jebšu neesmu redzējis nevienā dbvs meklēšanas risinājumu kas apmierinātu mūsdienu lietotāju prasības (datu apjoms / ātradarbība utt).

Bet ja tu būtu palasījis Sphinxa dokumentāciju tad faktiski viņs piedāvā arī funkcionalitāti native MySQLam proti storage engini SphinxSE ..

ingars: nu painteresējies cik ir oracle licences par procesora cori un mēs tad varam turpināt par 'dogmām' ;)

Kas attiecas uz indeksiem tad jā līdz šim MySQls izvēlējās tikai vienu indeksu (balstoties uz saviem statistikas datiem par to kurš no indeksiem varētu prasīt mazāk pārlases (filesort) pēc tam (tas pats uz aiz ORDER BY)). Tagad kādu laiciņu MySQLs mēģina šos indeksus mergot/unionot vai intersectot .. Bet faktiski tikai samērā nesen 5.1.x branch ir ieguvis relīzes kandidātu..

Roze: <a href="http://www.oracle.com/technology/products/database/xe/index.html" rel="nofollow">Oracle Express Edition</a> ir bezmaksas. Tiesa ir ierobežojumi: Datu bāze ne lielāka par 4GB, izmantot drīkst tikai 1 procesoru (uz datora var būt arī vairāki), drīkst izmantot 1 GB atmiņas (datorā drīkst būt vairāk), kā arī uz servera tikai viena instance.

Par dārgajiem dzelžiem Oraclim... cik atceros, kad parādījās Oracle 10g, šamie paši ieteica nelietot dārgus dzelžus, bet taisīt klāsteri no lētiem linux datoriem - gridu nodrošina pats Oracle.

e-remit: jā protams, bet ar tādiem limitiem db ganjauka var turēt arī txt failā vai teiksim izmantot kādu sqlite :)

Ietaupijumu uz klīstera izmaksām noteikti atsvērs licences un uzturēšanas izmaksas ..

Es protams neko sliktu nesaku par kvalitāti / kapacitāti un iespējām (jo daļēji vienkārši tāds "kapeikpi***" sindroms), bet tas lēti NAV :) Kā sacīt izvēlēties tikai divus no 3 (lēti / labi / ātri)

No vienas puses negribas nodarboties ar mārketingu, no otras puses lasu jau kādas pāris dienas komentārus un nespēju vairs izturēt :) Datubāzes cena, protams, nav tikai tās licences cena, nav arīdzan plus tās dzelžu cena un vēl kaut kādi tiešas izmaksas. Datubāzes cena ir ļoti daudz kas, tai skaitā arī izstrādātāju (ne)eksistējošās skilles, pieejamais darbaspēks, tas ko no tās grib izspiest utml. Tas viss ir uzskaitīts šite http://datubazes.wordpress.com/2007/11/21/ka-izveleties-datubazi/ un ļoti var būt, ka kaut ko esmu vēl aizmirsis. No otras puses ir pilnīgi skaidrs, ka katram no mums ir krietni lielāka pieredze ar kaut kādu vienu db, un šo db mēs labi pazīstam, un darboties ar to mums sanāk lētāk jo vienā laika sprīdī ar šo db mēs uztaisīs krietni vairāk nekā ar citu db, pie tam priekš citas db musm būs jāmācās, jāsaprot ko no tās var sagaidīt, ko nevar utt. Arī šis moments iet iekšā tajā db cenā. Bez tam ir tas, ko no tās db grib izspiest, esmu drošs, ka pasaulē var atrast arī lielākas db uz MYSQLa kā 200G, un es esmu redzējis arī nožēlojamas db uz Oracle, kas bremzē. Tā kā par ātradarbību runājot viss ir atkarīgs no tā

• vai es vispār kaut ko māku,
• tad vai es nemēģinu datubāzi X piespiest darboties tāpat kā datubāzi Y, kaut gan tā tas nemaz nav paredzēts un ieteikts,
• tad kādas man ir prasības un vai ši konkrētā db kaut ko tādu principā var dabūt gatavu vai nē.

Gint, zini kas tavā rakstā pietrūkst? Faktiskie DBVS produkti un salīdzinājums, tad varētu būt vairāk interesanti cilvēkiem kas ir šādas izvēles priekšā. Nav jau tā ka ir tikai 4-5 produkti (proti MySQL, MS SQL, Oracle, Pg SQL .. ) Ir visādi tādi interesanti veidojumi (nerunājot jau par visādiem db2, bdb utt) no savas pieredzes piemēram ANTS DB (inmemory DB) http://www.ants.com kas orākļa TimesTen sauc par smieklīgu, tad ir EnterpriseDB www.enterprisedb.com kas taisīts uz pgsql platformas ar visādām advanced fīčām u.c. ko būtu interesanti apskatīt ..

Pfft tikko iekomentējot pats paskatījos izskatās ka Oracle lēnām partnerojas un iepērk visu kas ir interesants ... laikam jau pasaulē tādas tendences :)

Roze, es tieši tāpēc uzdevu jautājumu par Sphinxu, ka viņam ir tas mysql storage engins ;) bet par to, kāpēc nevarēja iebūvēt - dbvs mērķis taču ir uzglabāt datus un ljaut tos atlasīt pēc visādiem parametriem. tai skaitā pēc kāda lauka vērtības daljas, kas tad arī būtu fulltext searchs. imo normāla dbvs funkcionalitātes sastāvdalja ..

Roze, es zinu, ka tas pietrūkst un būtu derīgi. Bet ir vairāki bet:

1. es zinu diezgan daudz par Oracle, mazliet mazliet esmu paostījis MS SQL Server un MySQL, līdz ar to es nekādi nejūtos spējīgs uzrakstīt kaut kādu salīdzinājumu
2. visas šīs db attīstās diezgan nežēlīgā ātrumā un tas salīdzinājums, kurā tiktu ieguldīts pamatīgs darbs būtu novecojis jau pēc pāris mēnešiem, kad kādam no produktiem iznāktu nākošā versija. Es apmierinājos ar to, ka otrā rakstā, kas BTW tajā augšminētajā ir referencēts, uzskaitīju db un iedevu linkus uz to lapām, tie vismaz nemainās tik ātri :) Un starp citu es jau nemaz neteicu, ka ir tikai 5 produkti, es teicu, ka tas ir mans subjektīvi objektīvais :) pirmais saraksts un ka es nemaz arī nepretendēju uz to, ka abi saraksti kopā ir izsmeļoši.

j: nu nav nekur teikts ka MySQL kādreiz to neiekļaus savā core produktā.. Nav jau tā ka visas pašreizējās MySQL engines ir bijušas no sākta gala, jo ne vienmēr viena produkta izstrādātājiem mūza apvelta ar pariezajām idejām par visām lietām.. Tas pats Oracle savu produktu ir papildinājis ar diezgan daudziem iepriekš ārpus-orākļa izstrādātiem risinājumiem ..

Gints: nu es jau arī neteicu ka tu saki ka ir tikai 5 produkti.. tas bija domāts no vispārējā viedokļa - proti līdzīgi kā teiksim webserveru jomā vispārīgs uzskats ir ka ir Apache / IIS un tad vēl kaut kas.. bet fakts ir tāds ka ir N citu produktu kas varbūt nav tik populāri, taču dažos gadijumos ir krietni piemērotāki uzdevuma veikšanai un pat jaudīgāki :)

Par to ka tāds darbs un analīze prasa laiku nemaz nešaubos.. Bet tas tā idejai ja nu kādreiz "uznāk" ..