Kakšen sever za sql in domeno z cca. 100 uporabnik
- Ustvarjalec teme igi
- Začetni datum
V DL380 G5 lashko vtakneš 8 146 GB SAS diskov, če pa je premalo imaš pa še HPjev MSA60 (12 SATA ali SAS diskov, lahko mešaš diske ,posamezno polje mora imeti enak tip diskov) ali pa MSA70 (24 diskov). Potrebuješ še E800 Smartarray kontroler in si zmagal. Uporabiš lahko 500 GB SATA diske ali 320GB SAS diske (3,5").
Čisto tako seveda ni. Delno pa tudi je... SQL server si zahteve spravlja v vrsto, nastaviti se da, koliko virov (CPU, RAM-a, niti itd...) mora imeti na voljo, da začne zahtevo sploh delati. Ko jo pa začne, se trudi, da jo čimprej konča in takrat ostali trpijo, ampak seveda tudi prihajajo njihove niti na vrsto vmes (razen, če je nastavljen tak transaction model, da ne morejo zaradi nivoja zaklepanja). Res pa je, da kompleksni select, ki povzroči table scan po mnogo tabelah, ker ni pravih indeksov, povzroči, da ostale stvari letijo iz cache-a in to se ostalim zahtevam pozna. Seveda tipična zahteva traja nekaj ms, nekatere daljše pa precej vplivajo na delovanje vseh uporabnikov. Meni praksa kaže, da na desktop enoprocesorskem sistemu že en select, ki traja dolgo zelo ubije odzivnost ostalih zahtevkov. Na sistemu s 400 konkurentnimi uporabniki n večprocesorskem sistemu, pa je ena sama zadeva, ki je rabila table scan čez dober milijon zapisov, drastično slabšala odzivne čase povsod po sistemu. Res pa je, da so uporabniki izrazito pogosto potrebovali to iskanje in ko smo našli, da je administrator po nesreči umaknil index, smo s tem rešili problem v celotnem sistemu. Je pa tudi res, da je nek indeks lahko dober tri leta, potem pa od nekega dneva ne več... Podatki so malo drugače razporejeni in SQLServer se odloči, da mu za neko akcijo več ne koristi. In če je to akcija, ki se med 100 uporabniki proži nekajkrat na sekundo, je to lahko problem. Tako da je vsak živ sistem potrebno spremljati.
Nekdo je omenil Oracle. Oracle dela vsaj glede zaklepanja nekaj drugače kot SQL server. Na SQL serverju je temu načinu še najbližje snapshot izolacijski nivo na SQLServer-ju. Vseeno pa je po mojem SQLServer dovolj dober za podjetja, ki jih najdemo pri nas. Mislim predvsem število uporabnikov.
Mogoče sem prvič napisal preveč laično, ampak za boljše odzivne čase je boljši HW poceni naložba, če pomaga. Vse ostalo zahteva še več truda in tudi to je običajno potrebno plačati tako ali drugače in je še dražje. Nekateri stvari je preprosto najti, kakšne pa zelo težko. Pri kakšni pa je še Dejan Sarka ugibal, zakaj se tako obnaša...
Potem je SQL Server povsem neuporaben za resne sisteme!
Jaz sem omenjal Oracle in njegovo delovanje zelo dobro poznam... tam na hitrost izvajanja več vzporednih procesov (poizvedbe / transakcije) vpliva predvsem I/O - en proses na drugega drugače ne vpliva. Pri UNIX/LINUX rešitvah se to lepo vidi, saj so vidni ločeni procesi v OS. Tudi na MS Strežniku deluje podobno, le da procesi niso vidni.
Jaz sem omenjal Oracle in njegovo delovanje zelo dobro poznam... tam na hitrost izvajanja več vzporednih procesov (poizvedbe / transakcije) vpliva predvsem I/O - en proses na drugega drugače ne vpliva. Pri UNIX/LINUX rešitvah se to lepo vidi, saj so vidni ločeni procesi v OS. Tudi na MS Strežniku deluje podobno, le da procesi niso vidni.
Tule bi sicer bil potreben poseg v aplikacijo: podatke iz baze preberes in zgradis XML (al pa preberes v strukturo), pa dol z baze. Da ne zaklepas recordov, ker dejansko tole potem zelo pohitri delo, ce delata 2 al vec blagajnikov na isti bazi.
Ce te prav razumem, da je transakcija nezakljucena, dokler je porocilo prikazano in tako zaklepa recorde ?
igi: virtualne masine ne bi ble primerne, ker spet zrejo RAM in procesor, torej resurse. Po moje je bolje, da so produkcijske masine fizicne: pa naj bo bazni streznik fizicno locen. Ti pa res svetujem, da vzames firmo s supportom, torej kvaliteten HW: HP al pa mogoce Dell je imel nekaj casa zelo ugodne cene za "majhne" streznike.
Drugace pa SQL Server dela cist solidno. Za velike sisteme pa seveda Oracle (je pa zato zelo drag). Download Oracla je (oz. je bil) zastonj, ampak za nekomercialno uporabo.
Je pa dost odvisno od tega, kako je napisana aplikacija.
Tud na Oraclu obstaja optimizacija SQL-a. OK fantje, zdaj funkcionalno dela, mora pa delat dost hitreje.
Ce te prav razumem, da je transakcija nezakljucena, dokler je porocilo prikazano in tako zaklepa recorde ?
igi: virtualne masine ne bi ble primerne, ker spet zrejo RAM in procesor, torej resurse. Po moje je bolje, da so produkcijske masine fizicne: pa naj bo bazni streznik fizicno locen. Ti pa res svetujem, da vzames firmo s supportom, torej kvaliteten HW: HP al pa mogoce Dell je imel nekaj casa zelo ugodne cene za "majhne" streznike.
Drugace pa SQL Server dela cist solidno. Za velike sisteme pa seveda Oracle (je pa zato zelo drag). Download Oracla je (oz. je bil) zastonj, ampak za nekomercialno uporabo.
Je pa dost odvisno od tega, kako je napisana aplikacija.
Tud na Oraclu obstaja optimizacija SQL-a. OK fantje, zdaj funkcionalno dela, mora pa delat dost hitreje.
Nazadnje urejeno:
To je seveda zelo .... rečeno. V RDBMS so stvari povezane. Ena transakcija vpliva na drugo. Res pa je, da Oracle omogoča, da branje vrne stare podatke, ki so pa bili vmes že spremenjeni s strani druge transakcije, preden je akcija branja končala. To seveda omogoča hitrejše delovanje pri branju. Pri M$ pa pravijo, da taki podatki niso konsistentni (saj vemo, kaj pomeni ACID pri transakciji). Dokler seveda niso tudi oni spravili skupaj shapshot zaklepanja. Sedaj je najbrž to tudi v redu
Vsekakor bi predvideval, da je Oracle verjetno primernejši za večje sisteme. Ampak sistem s 100 konkurentimi uporabniki (ali je mislil vsega skupaj 100 uporabnikov), ni velik sistem. Je pa vseeno res, da tudi tak sistem ne teče na vsakem HW-ju in da se da z določenim naporom precej dobiti na odzivnih časih. Definitivno je tudi res, da se veliki SELECT-i (po številu fizičnih akcij na disku) in hkratna masa sicer preprostih transakcij na SQLServer-ju ne marajo preveč, sploh, če je malo RAM-a. Mogoče se na Oraclu na enakem HW-ju bolj. Jaz sicer Oracla ne poznam, čeizvzamemo faks, imam pa dva kolega, ki to reč administrirata.
Na SQLServer-ju se da z zelo preprostimi orodji za uporabo iskati najbolj problematične dele in pustiti celo, da avtomatika predlaga rešitve. Po drugi strani se da s performance counterji tudi hitro ugotoviti, kje je HW ozko grlo. Ampak na palec ugotoviti, da bo nek HW totalno rešil problem, pa se po mojem ne da... Marketingarji velikokrat hočejo, da za ponudbo opišem zahteve za strežnik za podjetje, ki je opisano v enem odstavku in to ni resno delo, ampak ugibanje.
Nekoč je imel Compaq en kalkulator, da si izbral OLTP ali OLAP sistem in potem za OLTP sistem določil število transakcij na časovno enoto in ven ti je vrgel ustrezni strežnik. Ampak meni se je iz tistega zdelo, da mislijo, da bodo med transakcijami samo INSERT-i, ki so tako ali tako najhitrejši in verjetno še referenčne integritete niso predvidevali. V glavnem, dobil si hudo švohoten HW. Mogoče to orodje kje pri HP-ju še obstaja.
SQL server je cisto dovolj hiter
problem nastane ko v razvijalski firmi kjer so naredili software, se niso slisali za kratico DBA.
Potem vsak malo popravlja po bazi. indexi so jim spanska vas, da ne vejo kaj je clustered index je itak jasno, razlika med "nVarChar" in "Char"? kaj je to, velikokrat po bazi delajo z kurzorji in potem dobis kar dobis (beri: poizvedba v tabeli z nekaj miljoni zapisov traja nenormalno dolgo, moral bi jih pa pljuvat ven)
lp
ps: po mojem mnenju so mu to "overkill" mashino predlagali zato, da bi skrili svojo nesposobnost!
problem nastane ko v razvijalski firmi kjer so naredili software, se niso slisali za kratico DBA.
Potem vsak malo popravlja po bazi. indexi so jim spanska vas, da ne vejo kaj je clustered index je itak jasno, razlika med "nVarChar" in "Char"? kaj je to, velikokrat po bazi delajo z kurzorji in potem dobis kar dobis (beri: poizvedba v tabeli z nekaj miljoni zapisov traja nenormalno dolgo, moral bi jih pa pljuvat ven)
lp
ps: po mojem mnenju so mu to "overkill" mashino predlagali zato, da bi skrili svojo nesposobnost!
pa smo prišli do zaključka....
Katero firmo mi pa recimo predlagate za podpis pogodbe o vzdrževanju morebitnega novega serverja? Jst sem sicer imel v mislik kar iste majstre ki nam prodajajo SW, ker takrat ni zgovarjanja kdo je kriv, samo malenkost sem skeptičen v njihovo stokovnost z redkimi izjemami....
jest bi te prvo vprasal, koliko sploh je teh podatkov (miljon, dva, deset,...)? kolko je uporabnikov?
potem pa se malo preleti bazo oz sistem, naredis zakljucek, nato pa privijes "dobavitelja" programske opreme da malo naredi na optimizaciji.
Ker kriviti SQL server za slabo/ne delovanje svojega sistema je miloreceno idiotsko (s tem se srecujejo pri kolegu kateri uporablja SAOP, je pa pri vseh dosti podobno)
lp
ps: ze tu na alterju izgleda, kot da je par ljudi ki zadevo dobro poznajo, zmeni se z enim od teh, da stvar preleti s teboj
potem pa se malo preleti bazo oz sistem, naredis zakljucek, nato pa privijes "dobavitelja" programske opreme da malo naredi na optimizaciji.
Ker kriviti SQL server za slabo/ne delovanje svojega sistema je miloreceno idiotsko (s tem se srecujejo pri kolegu kateri uporablja SAOP, je pa pri vseh dosti podobno)
lp
ps: ze tu na alterju izgleda, kot da je par ljudi ki zadevo dobro poznajo, zmeni se z enim od teh, da stvar preleti s teboj