MySQL ir viens no atpazīstamākajiem un populārākajiem atvērtā koda projektiem, kas ļoti smagi cieš no ekonomiskās krīzes. Nedienu aizsākums meklējams brīdī, kad 2009. gada pavasarī Oracle paziņo par vēlmi iegādāties SUN Microsystems. Saistībā ar šo paziņojumu Eiropas konkurences padome veselu gadu izvērtē ietekmi uz DBVS tirgu, un šis apstāklis nenāca par labu MySQL. Iespējams vairāki lieli programmatūras izstrādātāji jau šajā brīdī uzsāka meklēt alternatīvus risinājums. Atļauja apvienoties vēl vairāk nostiprināja pārliecību, ka labāk laicīgi izvēlēties kādu citu risinājumu. Tirgū parādās MariaDB (viena no MySQL AB dibinātājiem Michael “Monty” Widenius projekts), kas ir MySQL atvasinājums. PostgreSQL izstrādātāji paziņo, ka viņi bija, ir un būs vienmēr atvērti un finansiālas problēmas viņus var ietekmēt minimāli, jo izstrādē piedalās pietiekami plaša un ietekmīga kopiena.
No MySQL projekta ir aizgājuši vairāki nozīmīgi speciālisti. Piemēram, projekta Drizzle (MySQL “vieglā versija”) izstrādātāji, kas tagad darbojas kompānijas Rackspace paspārnē. (Avots: www.opennet.ru)
Kritika saņemta arī no noslogotu interneta vietņu uzturētāju puses. Digg.com migrējis savu projektu no MySQL uz Apache Cassandra. Kā galvenais iemesls tiek minēts – nepietiekamā veiktspēja. (Avots:www.opennet.ru)
Diemžēl, labo ziņu nav daudz, un uz tām nāksies vēl kādu laiku pagaidīt. Viss atkarīgs no Oracle vēlmes attīstīt vai degradēt šo patiesi lielisko produktu.
Atļaušos piezīmēt, Digg izvēle pāriet no MySql uz Cassandra nebūt nenozīmē, ka MySql ir nepietiekama veiktspēja, bet liecina, ka viņiem neder tradicionālā, uz relācijām bāzētā arhitektūra. Bez tam, šobrīd novērojams NoSql vārdiņa bums, tāpat kā ar Ajax savā laikā.
Andris izņēma man vārdus no mutes
Tas, ka digg.com ļoti labi varētu derēt tieši kay=value tipa datubāze, vēl nenozīmē, ka MySQL ir pie kā vainīgs. Vienkārši katrai problēmai ir savs risinājums, labs vai ne tik labi piemērots.
Visa pamatā tomēr ir veiktspēja, ja pie vienāda daudzuma informācijas viena DB rezultātu atgriež ievērojami lēnāk, tad otra tomēr būs uzskatāma par labāku… Diez vai programmētājam īpaši interesē DBVS informācijas uzkrāšanas/apstrādes mehānismi. Ļoti maz būs tādu, kuri DBVS izvēlēsies pēc principa “šai sistēmai ir interesants apstrādes mehānisms” vai arī pēc principa “man patīk nosaukums”.
@Armands
Nevajadzētu, tā teikt, salīdzināt ābolus ar apelsīniem. Ir gadījumi, kad veiktspēja nav galvenā prioritāte. Klasisks piemērs būtu naudas pārvedums, kad pats svarīgākais ir operācijas drošums, ko nodrošina klasiska DBVS ar ACID operācijām. Ja mums interesētu tikai ātrums, bet ne drošums, tad vispār varam glabāt datus operatīvajā atmiņā nevis uz cietņa (memcache). Manuprāt, profesionāli programmētāji pat ļoti interesējas par to, kāds ir datu glabāšanas mehānisms un tieši kāds ir vispiemērotākais viņu prasībām un datu modelim.
Gadījumi protams ir daudz un dažādi… Operatīvā atmiņa ir labs risinājums, bet nav daudz tādu, kas spētu iegādāties šādas sistēmas… Iespējams Tev ir taisnība, ka programmētājs mūsu platumu grādos interesējas arī par DBVS datu uzglabāšanas mehānismiem un protams to drošību. Mūsu nopietnie programmētāji spēj arī administrēt datortīklu, konfigurēt ugunssienas, uzkniebt tīkla vadu un nomainīt printerim kārtridžu un veikt vēl daudz citu lietu… Manuprāt DB drošība vairāk tā kā trāpa DB administrātoru un IT drošības speciālistu lauciņā.