Negribu noniecināt MySQL, bet tā ir tāda Web DB, tipa, forumiem. Oracle Express, ja nemaldos (slinkums meklēt), neatbalsta tādus apjomus. Var ieteikt PostgeSQL, smuka bāzīte un viņa jau bija spēcīga, kad MySQL vēl čurāja autiņos. Uz lieliem apjomiem tā arī nepatestēju, bet 1,5M ierakstu tabulas maisa ka prieks (uz ubuntu server PIV2.8@1GB)

m

karuuzo tu to saki, tāpēc, ka tā ir visbiežāk izmantotā Web risinājumos?
Jeb tu vari pamatot ar nopietniem argumentiem, nevis tā: "Reiz kāda vecenīte teica".

MySQL ar tādu lielumu tabulām arī strādā bez problēmām, vienkārši ir atkarīgs no tā cik līkas vai taisnas rokas tev ir.

#2: Kāda lieluma tabulām? 100M, 500M ierakstu? 1,5M tā nav tabula, tā ir tāda sīka tabuliņa ar kuru paspēlēties. Nu lab, no otras puses, 10-15GB, tā jau arī nav DB, tā ir neliela bāzīte :D Ja tur vēl liek iekšā bildes, tad vispār nav ko sākt. Vēl jau jāzina lietotāju skaits, pieprasījumu sarežģītība un skaits laika vienībā utt.

Faktiski jāzina, ko autors grib izdarīt, ja vienkāršiem SELECT/INSERT..., tik un tā neredzu jēgas izmantot MySQL :D Nesaku ka viņa ir slikta, bet, ja var dabūt mersi, kāpēc ņemt VW. Ja cilvēkam pēkšņi ievajadzēsies trigerus, procedūras vai kārtīgu SELECT uzrakstīt, neies jau migrēt uz citu DB. Ja jau cilvēks domā izvēlēties starp MySQL un Oracle, viņam visticamāk ir pie kājas MySQL saceptie CMS un izvēle jāizdara, pamatojoties uz citiem kritērijiem.

Eh, vispār tā nav vienkārša lieta. Ja gribi griezt masu sūda forumiņu uz freeware hosta - viennozīmīgi MySQL, ja domā par normālu sistēmu, tur jau jāzina vairāk parametri kā tikai iespējamais DB izmērs.

m

#3 Tu jau pats minēji par tiem 1,5Mb, nejau es.
Ja 10-15GB ir bāzīte, tad kas tavuprāt ir bāze?

Viņš ir rakstījis, ka viņam nevajag ne trigerus, ne ko citu.
Tā pat tu neesi vēl joprojām minējis nevienu nopietnu argumentu.

Un no kurienes vispār tu ņēmi, ka MySQL nevar strādāt ar lieliem datu apjomiem? Un kāpēc uz MySQL nevar uzrakstīt sakarīgu SELECT?

Nesen veidoju meklēšanas skriptu (princips līdzīgs googlei).
Meklēšana starp 100 000+ ierakstiem aizņēm apmēram 0.09 sekundes, bet tas ir kopumā ar php ielādes laiku..

Oracle un MySql pamatfunkcionalitāte ir līdzīga. Atšķirības ir niansēs, īpaši no uzticamības, scalability, drošības un uzturamības viedokļa.

Ja man būtu jāizvēlas, tad visam, kas ir mazāks par facebook un nesvarīgāks par KRITISKU informācijas sistēmu - MySql.

Vēl ļoti būtisks aspekts ir budžets.
Oracle Express ir tikai tāda "paspēlēšanās"

Oracle Standart Edition licence 1 procesoram maksā $ 17500
Db serveris, kas būtu "cienīgs" darbināt oracle maksā vēl $10000 + app serveris un backup serveris. Kopējās izmaksas, dzelži + licences būs ap $35 000

Tādas izmaksas jau velk uz lielu un nopietnu IT projektu, kuru vajadzētu projektēt nopietniem sistēmu arhitektiem nevis prasīt padomu čaļiem forumā ;)

Sākās :) Nu labi. Tātad, strādāju pie softa izstrādes, kur DB virs 500GB. Vienas sistēmas DB. Tur tabulu skaits, kurās pārsniedz 10M ierakstu jau vien ir virs 100. Nu jā, M nav MB, bet miljons ierakstu ;)

Ja runā par SELECT, nu SELECT jau uzrakstīt var, bet, ja esi strādājis ar nopietnām DB, ātri saproti, kas tev pietrūkst. Nevaru tev te tagad pārskaitīt, bet tas ir līdzīgi kā ar fotožopistiem, kas noliek GIMP. Jāsaka, ka Postresam ar ir savi ierobežojumi, bet iespējas krietni vairāk. Viena lieta, ko aktīvi izmantoju pēdējās 3 nedēļas, SELECT no SELECT. Ideāls pārskatu veidošanā :)

Par ātrumu, man Postgres uz tā paša PIV sajūdzot kopā divas tabulas, viena ~1,5M, otra 30K ierakstu, bez indeksiem (vispār bez, jo nezināju, ka Postges by default neveido indeksus priekš foreignkey) meklēšana aizņēma arī zem 1sec. Joks vienkāršs, uzliku buferus 512MB, TEMP buferus 256MB un šis visu sameta atmiņā un lidoja. Saliekot indeksus, protams, ka SELECT laiks nokrita zem 0.1sec. Jautājums, ko tu meklēji. 100K nav apjoms ;)

Nu lab, mēs varam te ņemties, bet tēma jau bija, ko labāk izvēlēties. Es strādāju ar lielām DB un priekšroku dotu Postgresam, varbūt tāpēc, ka Postgres jau pamatos tika būvēts kā nopietna DB, bet MySQL bija divu (trīs) cilvēku projektiņš, kas labi izdevies :)

m

PS. #5: Salīdzināji ar Facebook :) Viņam arī Oracle nelīdzēs. Tādiem projektiem tiek izmantotas Hash DB (nezinu kā viņas pareizi lamā). Neesmu pētījis, bet ideja vienkārši ģeniāla, ir tabulas tikai no diviem laukiem PK un vērtība :)

#5 no offence un tas forums ir datuve :D bet par teemu - postgeSQL butu tas virziens uz kuru vajadzetu skatities

MySQL to mierīgi pavilks, ja vien jums tur būs kāds, kas zina, kas ir indekss un kam ir nojēga par DB optimizēšanu, profilēšanu, my.cnf(my.ini) tūnēšanu (nu vismaz iekāriens lasīt par to visu :)).
Tepat MyISAM datubāze aizņem 22GB un darbojas kā nākas, bez aizturēm.

+1 par PostgreSQL.

#6 Vai vari pastāstīt pie kāda softa izstrādes tu strādā? Vienkārši interesanti ;)

Jautājums, ko tu meklēji.

Tā bija lapas iekšējā meklēšana.. ;) Visas sadaļas utt, tiek kešotas. Nu par struktūru es nestāstīšu..

Nu manuprāt ja jau MySql vilks tavu projetu, tad jau liec to!
jo ja galva strādā tad jau ar MySql var daudz ko izdarīt!

MySQL aizstāvji - uztaisiet tabulu ar 3 miljoniem ierakstu un 7 indexiem un uzlieciet dzēsties visus ieraksties, kuriem id beidzas ar 00 tb katru simto. jums būs lieliska iespēja apskatīties, kā visa db nolockojas un iefreezo, jo MySQL šo delete pieprasījumu gremos ilgi, dzēsīs ierakstus, reindexēs utt. selectēt un insertot var bez problēmām, bet dzēst ārā datus, kuri nav pēc kārtas, ir nagla pakaļā.

sn1per: tas ir tikai MyISAM vai arī visām storage enginēm kopīgi? MyISAM nepiedāvā row-level locking, tas fakts. Viņš loko visu tabulu, ja kaut ko vajag.

nezinu kam vēl, bet MyISAM tas toč ir, jo tomēr forumā vajadzēja full text searchu. bet izdzēšot topiku ar 4000+ ierakstiem viss forums apstājas uz pāris minūtēm. bet nu tika uztaisīts workarounds, ka ieraksti "atzīmējas" kā dzēsti vienā kolonnā un mazs batch process dzēš ārā pa dažiem ierakstiem minūtē, lai nebremzētos visa db.

 Nu MyISAM table-level locking lieto un nav piemērota lielām operācijām. Kaut ko dari tabulā - viņa visu loko, visi gaida uz vienu klientu. Toties iegūst ātrumu uz sīkām operācijām. Tas ir labi zināms fakts, un storage engine aprakstos ir minēti kritēriji, kad lietot to vai citu, atkarībā no gaidāmā klientu skaita un operāciju sarežģītības.

In general, if you're working on a datawarehouse, which are often used almost exclusively for reads and aggregation, with most bulk loads / updates off hours, then MyISAM is a great engine, as it doesn't have a lot of the overhead needed to support transactions and multi-version non-locking consistent reads, etc.

 Intensīvām nestandarta darbībām ir izmantojams InnoDB, Falcon utml dzinēji, kas piemērotāki intensīvākām darbībām. Da kaut vai tranzakcijas tie atbalsta. InnoDB pie tam prot atsevišķas partīcijas taisīt, cik vien vēlies.

#12 -
1.kart es teicu ja velk tad ir labs
2.kart, kav vajag vienā tabulā 3MIL. ierakstu!? :D
nu ir tādi kuriem vajag, bet ja piem uztaiss VNK forumu ar scriptu kurš dzēš 2 meneš neaktīvos topikus, vispār ir piemērots MySql.

Nu pag, daudzlietotāju sistēmās, kurās notiek intensīvas darbības ar tabulu, vispār nedrīkst pieminēt table lock :) Ja nu vienīgi tā tabula ir kāda key tabula un viņu vajag ik pa brīdim atjaunot, bet citiem tikmēr jāsūkā ledu. Vēl jau var uzlikt page level lock (nezinu, vai MySQL tādu atbalsta), kas samazina lokus un vecu topiku dzēšanai būtu diezgan piemērots. Jebkurā gadījumā, dzēst katru 100 ierakstu no 3M, tā vienmēr būs pi$anās, it sevišķi vienā transakcijā ar row level lock, tāpēc tādas darbības jāveic čerez Ž, piem., pa 1000 ierakstiem transakcijā vai (ideālākajā gadījumā) ar exclusive table lock, lai citi pagaida :)

m

PS. #10: Strādāju lielā kompānijā, kura izstrādā lielas sistēmas priekš citām kompānijām. Vēl ko gribēji dzirdēt :D

#16 kāpēc būtu jādzēš arā 2 mēnešus neaktīvus topikus, ja viņi visi ir par tēmu un ir atrisinātas kkādas problēmas?
#17 katru simto bij kā piemērs, reāli tas ir dzēst ārā ierakstus, kur topic_id=x un ierakstu skaits ir gana liels.

#18 NEVIENMĒR FORUMI IR DOMĀTI PRIEKŠ KAUT KĀDĀM PROBLĒMU RISINĀŠANAS! UN PASAK KAM VAJAG TO FUNKCIJU (NO 3M DĒST KATRO 100!?)????

#17: Zin, ir gadījumi, kad arī jādzēš "katru simto", piem., svītrotos ierakstus, kas tiek svītroti gada laikā. Ja runā par topic_id = x, tad tas ir ļoti nelāgs gadījums, jo tie ieraksti jau visticamāk netiek saģenerēti vienā piegājienā, bet vairākās dienās vai pat nedēļās, kā rezultātā neaizņem nepārtrauktu space. Vienīgi var izveidot neliela izmēra partīcijas (piem., pa mēnešiem), kā arī izveidot clastered index, tad dzēšana aizies kā smērēta. Protams, pie nosacījuma, ka DBVS to atbalsta.

#18: Nu forums jau ir ne tikai, lai sausi atbildētu uz uzdoto jautājumu, bet, lai cilvēki dalītos pieredzē, tas varbūt arī palīdzēs topika autoram rast atbildi. Un zini, "no 3M dzēst katru 100", tā ir klasika, kaut vai pie DB arhivēšanas. Protams, atkarīgs no tava lidojuma augstuma, izskatās, ka tev pieredze ar DB ir tāda ne pārāk, ja tu jautā, priekš kam vienā tabulā 3M ierakstu ;) A tu esi padomājis, piem., cik ieraksti tabulā, kurā uzskaita cilvēku zvanus vai īsziņas Pie nosacījuma, ka klientu skaits jau ~1M (nu tas ir, tādā bedrē, kā LV, nevis normālās valstīs).

m

#19 tas bija tikai piemērs, jo dzēst ārā topicu, kur useri pāris mēnešu garumā ir sarakstījuši nozīmē līdzīgu darbību, ieraksti nav veidoti pēc kārtas, tāpēc db ir visgrūtāk sagremot pēc dzēšanas un optimizēt db, lai selecti būtu ātrāki. tas ~ ir tas pats kas bibliotēkā grāmatas būtu sakārtotas pēc grāmatu nosaukuma alfabētiski. no viņām paņemt 100 pirmās grāmatas ir ātri, bet paņemt visas viena autora grāmatas nozīmētu iziet cauri visām grāmatām, izņemt ārā konkrētā autora grāmatas un pēc tam pārkārtot visus grāmatu plauktus, lai nebūtu caurumi pa vidu.

#20 redzi, forums ir no 2004. gada, kad tur mazs lietāju pulciņš kko marinēja savā starpā, bet kļūstot arvien populārāks auga un auga. toreiz viss lidoja uz nekādas kastes, tagad tur serveris ir ļoti jaudīgs un tāpat resursi tiek ēsti nežēlīgi daudz. a pāriet uz citu db pēc 6 gadiem būtu pain in the ass, ja ņem vērā, ka viss ir paštaisīts un autors nav gluži programmētājs, bet ar pamatzināšanām. vienīgais, kas tiek veikts pēdējā laikā, ir optimizācija, iets cauri, mainīti indeksi, lai viss notiktu gludāks, atrisināta šī dzēšanas problēma utt.

par autora uzdoto jautājumu - es arī piekritīšu #1, ka PostgreSQL ir labāka par MySQL, ir testēta arī ar samērā lielu datu apjomu, viss gāja gludi. Oracle vajag tādām ļoti nopietnām sistēmām + uzņēmumiem, kas var algot oracle guru, kuri risinātu problēmas :)

#21: zin, ne tādi vien brīnumi ir darīti :) Postgresa PHP (pieņemu, ka tas forums ir taisīts uz PHP) frameworks ir ļoti līdzīgs MySQL un, ja engine ir paštaisīts, vispār problēmām nevajadzētu būt. Ja tev vēl ir savas DB klases, nevis izmanto standarta, tad tā sāpe ir tik, cik izveidot analogu Postgresa klasi un pārdzīt datus.

Ja tev ātruma uzlabošanai ir jādzēš dati, tas nozīmē divas lietas - vai nu nepareizi salikti indeksi vai līki SQL. Palielinoties datu apjomam 100x, meklēšanas soļi indeksā palielinās 1x (normālām DB). B-Tree indeksa būvēšana arī neaizņem daudz laika. Datu dzēšana jāveic gadījumos, ja viņi tev nav vajadzīgi, traucē vai sāk pietrūkt vietas, citādi, DB serverim jāvar tikt galā, problēma ir tikai optimizēšanā.

Ja gribi, lai uzmetu aci, raksti PM. Nākamā nedēļa brīvāka, ja nepazudīšu no Rīgas, varu palīdzēt. Kā jau teicu, MySQL esmu tikai "redzējis", bet DB paliek DB :)

m