Par MySQL
Labs skaidrojums, kāpēc daudzi neizmanto MySQL liela apjoma datu apstrādei. Protams, tā ir tikai viena no problēmām, bet, ja MySQL ieviestu iespēju izdalīt un apstrādāt vienu pieprasījumu vairākos paralēlos threados, kuri eventuāli varētu tikt novirzīti vairākām kastēm vai pat to grupām, tam visam nebūtu cenas.
Interesanti, ka neskatoties uz virtualizācijas uzvaras gājienu pēdējā laikā, datubāžu vadības sistēmas aizvien vēl turpina balstīties uz procesoru skaitu un atmiņas apjomu (scale vertically). Lai realizētu distribūciju, tiek izmantoti risinājumi, kuri darāmos darbus sadala paši, pirms tos nodot SQL serverim (scaling horizontally).
Starp citu, MySQL viena pieprasījuma - viena pavediena vājums ir uzskatāmi novērojams replikācijas gadījumā, kad replikācijai tiek izmantots tikai viens paralēls process. Pie liela izmaiņu apjoma replikācija var sākt diezgan nozīmīgi lagot, jo māsters visas darbības veic paralēli, taču replikācijai tas viss ir jāizdara secīgi viena pavediena ietvaros.
Starp citu, tieši out of the box replikācijas trūkums ir tas, kāpēc viena diezgan apjomīga iekšējā projekta vajadzībām neizvēlējos PostgreSQL.
Tas tā - ofisa loriņi sakārtoti pa kastēm rītrīta ceļojumam uz jauno biroju un ir mazliet laika pirms nākamā cēliena pašarīt pa vairākas nedēļas nelasītām lapām.
2007. gada 22. novembrī, plkst. 16:10
> Starp citu, tieši out of the box replikācijas trūkums ir tas, kāpēc viena diezgan apjomīga iekšējā projekta vajadzībām neizvēlējos PostgreSQL.
Kaut kad pirms pusgada rakstīju klientam īsu pārskatu/pētījumu par PostgreSQL replikācijas iespējām un savus ieteikumus. Basically, cik atceros, replikācija vismaz uz aci izskatās gana out of the box... protams pāris variantiem nedaudz pietrūkst kkādu setup tūļu, bet nav nemaz tik slikti.
2007. gada 22. novembrī, plkst. 16:28
2003: Oracle Corporation released Oracle Database 10g. (The g stands for "grid"; emphasizing a marketing thrust of presenting 10g as "grid-computing ready".)
šķiet ka vismaz domāts par horizontālo scaling tiek.
2007. gada 22. novembrī, plkst. 16:46
Oracle, ja tiek izmantots RAC (real appliaction clusters) var paralelizeet SQL teikumus (ne visus, protams) pa vairaakaam nodeem, skat piemeeram sho rakstu: http://www.oracle.com/technology/pub/articles/conlon_rac.html
2007. gada 22. novembrī, plkst. 16:53
No otras puses vienmeer jaatceras, ka jebkaads paraleelisms buus deriigs un veelams tikai tad, ja sisteemaa ir briivi IO un CPU resursi, citaadi, paraleelisms patiesiibaa visu nokaus veel vaoraak. Naakoshais moments - datiem ko proceseeshanas rezultaataa gruuzh uz kaut kaadu galveno manageri ir jaabuut kaut cik kompaktiem citaadi tiikls tiks bezjeegaa noslogots, jo sevishkji ja vairaaki useri reizee gribees kaut ko mezhoniigi paralelizeet. Treshkaart vajadziiba peec paaraak biezha paraleelisma var noraadiit uz probleemaam aplikaacijas dizainaa, jo normaalaa vismaz OLTP aplikaacijaa tas ir diezgan rets pasaakums, iespeejams, ka taadaa gadiijumaa ir veerts padomaat par kaut kaadaam atvasinaataam tabulaam, kolonaam, materialized views Oracle gadiijumaa utml risinaajumiem.
2007. gada 22. novembrī, plkst. 20:24
Tikai jautājums: vai MySQL Cluster konkrētajā gadījumā tiešām neder? Jamie sola asinhronas transakcijas un arī replikāciju uz urrā. Iesaku šo saiti: http://www.mysql.com/products/database/cluster/faq.html
2007. gada 27. novembrī, plkst. 14:46
Visnotaļ skaļš paziņojums šai sakarā ;) http://storagemojo.com/2007/11/26/grid-is-dead/