Comments on: MySQL idejas http://laacz.lv/2007/11/23/mysql-idejas/ laacz te un tur. Thu, 11 Mar 2010 10:33:07 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57856 Roze Thu, 29 Nov 2007 17:02:40 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57856 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" .. 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” ..

]]> By: Gints Plivna http://laacz.lv/2007/11/23/mysql-idejas/#comment-57855 Gints Plivna Thu, 29 Nov 2007 15:57:39 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57855 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. 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.

]]> By: j http://laacz.lv/2007/11/23/mysql-idejas/#comment-57854 j Thu, 29 Nov 2007 13:36:00 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57854 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 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 ..

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57850 Roze Thu, 29 Nov 2007 01:59:05 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57850 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 :) 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 :)

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57849 Roze Thu, 29 Nov 2007 01:55:27 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57849 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 .. 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 http://www.enterprisedb.com kas taisīts uz pgsql platformas ar visādām advanced fīčām u.c. ko būtu interesanti apskatīt ..

]]> By: Gints Plivna http://laacz.lv/2007/11/23/mysql-idejas/#comment-57848 Gints Plivna Wed, 28 Nov 2007 22:18:06 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57848 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ē. 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-izvel... 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ē.

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57847 Roze Wed, 28 Nov 2007 21:09:09 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57847 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) 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)

]]> By: e-remit http://laacz.lv/2007/11/23/mysql-idejas/#comment-57846 e-remit Wed, 28 Nov 2007 19:51:38 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57846 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. Roze: Oracle Express Edition 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.

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57845 Roze Wed, 28 Nov 2007 18:26:12 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57845 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.. 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..

]]> By: ingars http://laacz.lv/2007/11/23/mysql-idejas/#comment-57842 ingars Wed, 28 Nov 2007 14:50:14 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57842 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. 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.

]]> By: j http://laacz.lv/2007/11/23/mysql-idejas/#comment-57840 j Wed, 28 Nov 2007 12:46:06 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57840 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ā. ? 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ā. ?

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57839 Roze Wed, 28 Nov 2007 11:47:49 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57839 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ā 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...

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

]]> By: j http://laacz.lv/2007/11/23/mysql-idejas/#comment-57838 j Wed, 28 Nov 2007 11:05:21 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57838 ā, 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 .. ā, 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 ..

]]> By: j http://laacz.lv/2007/11/23/mysql-idejas/#comment-57837 j Wed, 28 Nov 2007 11:03:44 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57837 runājot par 1 indexa izmantošanu selectam, jaunajiem mysqliem ir (būs, būšot?) indexu apvienošana(merge) vai tamlīdzīgs process.. runājot par 1 indexa izmantošanu selectam, jaunajiem mysqliem ir (būs, būšot?) indexu apvienošana(merge) vai tamlīdzīgs process..

]]> By: Roze http://laacz.lv/2007/11/23/mysql-idejas/#comment-57836 Roze Wed, 28 Nov 2007 10:28:42 +0000 http://laacz.lv/2007/11/23/mysql-idejas/#comment-57836 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.. 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..

]]>