Vlákno názorů k článku Databázový server na platformě Intel 32bit od Veldrane - Ehm nevim zda clanek je urcen pro maly...

  • Článek je starý, nové názory již nelze přidávat.
  • 22. 3. 2004 23:28

    Veldrane (neregistrovaný)

    Ehm nevim zda clanek je urcen pro maly databazovy server nebo pro enterprise sferu ? Pokud si stavite maly databazovy server doma pro par uzivatelu snad mate pravdu, ale praxe je trosku jina mel bych vyhrady zejmena k tomuto:

    1. Zalohovani na DAT - to je vtip ??? - zalohovani na DAT je znacne zastarale, jednak vysoka nespolehlivost pasek, jednak maly objem, mala rychlost zapisu, cteni atd. Dnes se v zasade pouzivaji 3 technologie - SDLT, LTO a AIT, kdy vykony a objemy dat jsou srovnatelne AIT ma trosku vyssi rychlost obnovy, ale zase nepojme takovy objem dat, jako druhe dve technologie atd. V clanku chybi alespon zakladni info o zalohovacich softwarech (Networker, NetBackup, BackupExec, ArcServe, Tivoli atd atd)

    2. RAID & SCSI - vhodnost raidu a ted myslim urovne zabezpeceni ne nasazeni raidu jako takoveho (HW SCSI RAID je nutnost !!) je dana aplikaci. Jsou nejaka obecna doporuceni jako treba ze je vhodne rozdelit databazove soubory, transakcni logy a indexy, ale jaky typ RAIDu to zalezi na aplikaci. Je dobre mit vyhovujici velikost cache, vetsina modernich RAID radicu ma samozrejme baterii, ktera chrani cache proti pripadnemu vypadku. U velkych databazi se zrejme nevyhneme nejakemu SAN reseni (FC HB adaptery v serverech a centralni diskove pole s redundantnimi radici a treba s podporou VRAID). Co se velikosti stripe tyce tak by mel korespondovat s velikosti databazoveho bloku (bud by mel byt stejne velky a nebo 2x,4x vetsi - toto se zejmena hodi pokud pouzivate napriklad na oracle raw device). Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni. Pokud ctete/zapisujete spoustu random malych bloku, tak vam je RPM naprdlajs.

    3. Znackovy server
    Problem je hlavne ve spolehlivosti a predevsim v zaruce (zkusenosti s HP - pokud mate intel server pri vypadku byste tusim mel mit do 24 h. funkcni nahradu tzn. do 24 by mela byt zavada odstranena - hnidopichum se omlouvam, tohle mozna neni uple presne zneni, nicmene je Vam garantovana doba odstraneni). Pokud pozadujete vyssi zabezpeceni urcite by se hodil nejaky cluster. Uz vidim jak napr. u serveru 24x7 zhebne deska a bezite kupovat novou ;-)) (tohle neni na Vas, ostatni co chteji takovyto server stavjet na kolene si to preberou ;-))

  • 23. 3. 2004 0:04

    Miroslav Petříček (neregistrovaný)

    "Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni. Dalsi vjec je rychlost disku - RPM nam ovlivnuji rychlost hlavne pri sekvencnim zapisu/cteni."

    Tohle není až tak úplně pravda. Naopak rychlost otáčení disku je velmi důležitá pro dosažení nízkého rotačního zpoždění (rotational latency), které je vedle vlastní přístupové doby (seek time) kritickým parametrem dnešních disků a jedním z hlavních důvodů, proč jsou současné SCSI disky rychlejší než jejich pomaleji se otáčící ATA příbuzní.

    Pravděpodobně jste měl na mysli interní přenosobou rychlost (internal data rate), díky které mohou i pomaleji se otáčící IDE disky dosáhnout vysoké sekveční přenosové rychlosti, ale která v oblasti databází není tolik důležitá.

  • 23. 3. 2004 13:07

    Veldrane (neregistrovaný)

    Myslel sem RPM, (vystavovani hlavicek pri random cteni/zapisu) nicmene na toto jsem zapomnel