-- Zakladni predpoklad clanku, ze zajisteni nejvetsi mozne dostupnosti DB se resi nakupen nejakeho bozskeho HW je trosinku ulet. I reseni za nekolik stovek tisic proste jednoho dne bude mit problem. Zakladni otazkou, kterou by si mel kazdy zodpovedet, je co budu delat az to "spadne" a co jsem ochoten investovat do toho, abych tento stav mohl nasledne rychle serit. Vsimnete si nerikam, aby tento stav nenastal. On jednou vzdy nastane a je vhodne znat reseni jeste pred tim.
-- U vetsich DB nebo u systemu kde RAM je plna obsluhy klientu a ne cache vetsinou system ceka na disk a ne na CPU.
-- Dulezite je jak HW pouzivam a pak az jaky HW mam. Napriklad rozdeleni disku, filesystem apod.
-- Jak tu nekdo psal, ze SCSI je blbost. Kde se da koupit IDE s temito parametry: 15K RPM, Average Latency 2 msec, Average Seek Time: Read: 3.6 msec, Write: 4 msec. 8MB cache.
-- DB jsou casto vyrazne mensi nez dostupne disky. Lepsi je vice disku mensi kapacity nez naopak.
-- Neni nic individualnejsiho nez (ne)vykon DB. IMHO je vhodne vzdy prihlednout k aktualnimu nasazani.
"-- U vetsich DB nebo u systemu kde RAM je plna obsluhy klientu a ne cache vetsinou system ceka na disk a ne na CPU. "
Přesně tak. K tím souvisí i další nesmysl v článku a to tvrzení o nutnosti rychlé paměti. Paměť není to, co zdrzuje.
Když nastupovaly DDR, tak ještě nejmíň rok se do serverů dávaly SDRAMy. Byla to vyzkoušená technologie a byly ECC.
Jestli byl cíl napsat článek o ničem s tím, že zajímavé detaily si lidi řeknou v diskusi, tak byl účel splněn ;-)
No jo, ale jak jiz jsem psal: staci koupit 2x IDE, dat je do stripu - rychlost stoupne shruba 1.8x. Jenze kapacita 7x vetsi a cena stejna. A nebude dlouho trvat a IDE disky budou take 10kRPM a 15kRPM. Jojo, lide IT oddeleni velkych firem zapominaji na to, co to znamena setrit prachy.
Nevedomost je sladka :)
Az IDE bude mit stejne pokrocile vlastnosti jako SCSI, tak tento argument bude spravny. Samozrejme v situaci, kdy o IT rozhoduje neinformovany clovek, nebo pokud si delam databazi pro 1-20 lidi, nebo na web, ktery ma 1000 hitu za den, tak je to samozrejme jedno. Docela bych se primlouval za FUNDOVANY clanek, ktery neznalym detailne popise rozdily v architekture SCSI x IDE.
:-)) To mam brat jako osobni invektivu? Myslim, ze vim velmi dobre jaky rozdil mezi SCSI a IDE. Na druhou stranu tyto 'pokrocile' vlastnosti jsou vyvazeny (ci spise prevazeny) penezmi, co za ne date. Ostatne jake pokrocile vlastnosti vam chybi na IDE?
Zkusme to jinak:
Myty o SCSI:
1) SCSI jsou spolehlivejsi
Nesmysl, z HW hlediska: plotny na SCSI disky vyjizdeji z uplne stejne linky nekde v Taiwanu jako plotny na IDE. Z SW hlediska: naopak diky komplikovanosti SCSI jsou s temito disky problemy (viz napr. fakt, ze do nekterych RAIDu proste nenarvete nektere SCSI disky - IDE je stejne uz deset let a jede vsude stejne)
2) SCSI jsou rychlejsi
Pravda, ale pouze castecna. Jsou rychlejsi pouze pro to, ze se ceka, ze finalni cena bude vetsi, tudiz se jeste zvysi napr. 15kRPM misto klasickych IDE 7.5kRPM. Neni to problem architetury IDE vs. SCSI, ale spise obchodniho modelu produktovych rad.
3) SCSI je lepsi
Vec nazoru. Jedine, co je dobre na SCSI jsou RAIDova pole, ktere vsak dneska jdou simulovat dost dobre softwarove. Opet se vsak musime bavit o cene/vykon. Kdybyste stavel dejmetomu 240GB RAID5 pole z SCSI, dostal byste se na nekolika-deseti-nasobnou cenu, nez kdybych to postavil z IDE. Pokud vam to za to stoji, hura do toho. Pro 99% lidi, kteri se zivi sami a nemaji za sebou rozpocet, kdy 0.5MKc neni nic je volba jasna...
PS: myslim si, ze mam s obojim docela velke zkusenosti a tim nemyslim nejaky drobno servrik.
[...]plotny na SCSI disky vyjizdeji z uplne stejne linky nekde v Taiwanu jako plotny na IDE. [...]
a na konci te linky je testovaci zarizeni, ktere tech nejkvalitnejsich 20% pusti dal jako SCSI a zbytek je IDE. 1/2 z toho pak koupi SUN a jemu podobni, nahraji tam vlastni firmware a disk slape jako SCSI 10 let.
Zbylych 80% svetove produkce pak figuruje jako IDE disky, s kterymi jsou problemy podle toho, jake stesti kdo mel.
To ovšem neimplikuje tvrzení "SCSI nezatezuje procesor!!!".
Navíc je to sporné. Zatížení procesoru není ani tak problémem technologie sběrnice disku, jako spíše problém komunikace mezi ovladačem řadiče a řadičem samotným. Pokud ATA i SCSI používají DMA (bus mastering), což by v novějších případech mělo být pravidlem, neměl by být rozdíl ve využití CPU výrazný.
Jak už jsem napsal jinde, důvod proč je SCSI o tolik rychlejší spočívá především v menší rotační latenci (vyšší otáčky) a tím pádem rychlejší době přístupu a pak také technologiích jako řetězení příkazů a odpojení sběrnice, které zvyšují efektivitu přenosů.
Ne neimplikuje a bylo to take jen zopakovani jinde rozvedene vety.
Ne ze nezatezuje - to by bylo hodne husty, ale oproti ATA100 disku zatezuje SCSI40 pri stejne realne propustnosti procesor zhruba na tretinu, zatimco to IDE na 100%
Fakticky zpusob jak to overit? Prehrat si hudbu pri intezivnim kopirovani/kompilaci kernelu. Po tomto testu uz nikdy do sve ws nedam zadne IDE nebo SATA, ale jedine SCSI.
Na pracovni stanici potrebuju vyuzivat vykon, ne mit 200GB kapacity. Onech 200GB se da narvat do naky jiny masiny
Kdyz uz je rec o zatezovani procesoru: zkuste si nainstalovat Wokna NT4 na IDE disk a zkopirujte na nej obsah CD pri zapnutem rezidentnim AV. Potom zapnete DMA, provedte tutez operaci a valte oci na ten rozdil :-) Vsechno neni jenom o discich, ale i o tom, jak s nimi ktery OS zachazi.
> 2) SCSI jsou rychlejsi
> Pravda, ale pouze castecna. Jsou rychlejsi pouze pro
> to, ze se ceka, ze finalni cena bude vetsi, tudiz se
> jeste zvysi napr. 15kRPM misto klasickych IDE
> 7.5kRPM. Neni to problem architetury IDE vs. SCSI,
> ale spise obchodniho modelu produktovych rad.
Nejde jen o otacky. Az bude IDE (resp [PS]ATA) umet
tagged queuing, tak to bude o necem jinem (pozor,
SATA sice udajne TQ umi, ale praxe je ponekud jina).
Zkuste si nejakou operaci vyzadujici neustale
seekovani po disku na 10kRPM SATA a na ekvivalentnim
10kRPM SCSI disku, rozdil je radovy.
"Kdybyste stavel dejmetomu 240GB RAID5 pole z SCSI, dostal byste se na nekolika-deseti-nasobnou cenu, nez kdybych to postavil z IDE. "
Myslíte ?
"Pokud vam to za to stoji, hura do toho. Pro 99% lidi, kteri se zivi sami a nemaji za sebou rozpocet, kdy 0.5MKc neni nic je volba jasna..."
Nevím kam na ty čísla chodíte.
Mám tu server od IBM, na kterém je RAID pole 360 GB (5+1 x 72) a celé to stálo cca 1/4 MKč. A k té spolehlivosti - když mi jeden disk odejte (což jsem simuloval "vyrváním" za běhu), pak si řadič ke zbývajícím čtyřem přidá šestý, záložní, dopočítá si kontrolní součty a dá pole do pořádku. Totéž ale v opačném směru když ten disk vrátím zpět. Přitom se dá na tom stroji celkem v pohodě pracovat, protože systém běží dál - akorát že se v tu chvíli musí systém podělit o propustnost disků s řadičem, který na pozadí přestavuje pole -> disky šlapou dočasně 2x pomaleji.
Ukažte mi toto na IDE - tak, aby to bylo i technologicky podepřeno a nemohlo nastat selhání z důvodů že se s IDE sběrnicí manipuluje jinak než ukládá norma.