Üdv!
Azután érdeklődnék, hogy VPS-re v. M$ Azure Cloud szolgáltatásra érdemes tenni az alábbi adatbázist? (MSSQL)
Konkrétabban az adatbázis nem bonyolult, 8-10 tábla lenne és az egyik táblába kerülne be sok adat (a többi tábla metaadatok... stb.). Ez milliós nagyságrendű rekordszám lenne (tehát akár 10-15 millió rekord).
Kb. az éves adatbázis mérete 20-30GB lenne. (Az 1évnél régebbi adatok archiválásra kerülnének.)
Ez a nagy tábla kb. három mezőből állna, pl.: id,timestamp,value(float)
A rögzített adatokat (WCF, web service-en keresztül kerülnének be az adatbázisba) webes (ASP .net) felületen lehetne elérni, de ez nem jelent nagy forgalmat (kb. heti 1-2 lekérdezés).
M$ Azure Cloud esetén a licenc díjakat a szolgáltatás tartalmazza - ez ok.
Pl. "A" sorozat 2mag, 3,5GB RAM, 50GB SQL tárhely.
Egy Azure-on levő SQL mekkora adatbázist bír el? Van valakinek tapasztalata ezzel? Vagy inkább érdemes VPS-ben gondolkodni?
Mennyire bővíthető később ez a "tárhely"? (pl. +RAM, v. +HDD)
Hozzászólások
Nem méretfüggő, hanem attól, hogy milyen bonyolult lekérdezések futnak. Menni valszin menni fog, de legfeljebb teker majd.
Elég egyszerű adatbázis.
A lekérdezés nem a napi feladatok közé tartozik, inkább a soap/xml-ben törénő folyamatos (értsd percentkénti) rekordbeszúrás.
Illetve ezt még ki kell találni, hogy folyamatosan küldjük az adatokat v. utólagosan csomagokban.
A beszúrások csak akkor problémások, hogy ha van index update. Könnyen lehet, hogy érdemes mondjuk per hónap szétdobnak a nagy táblában lévő adatokat vagy ha van, akkor az adatbázis kezelő particiónálós megoldását, bár ilyet még nem használtam.
Lehet jobban kijössz egy PaaS megoldással, pl. https://cloud.google.com/datastore/
--
Az SQL Azure is PaaS, ezzel nem vagyunk beljebb. :)
Lehet, hogy rosszul fogalmaztam, és ez már SaaS. Vagy az Azure SQL IaaS, ha már virtuális gép paramétereket kell állítgatni. Mindegy. Szóval amire célozni akartam, hogy egy ilyen megoldás esetén nem kell avval foglakozni, hogy milyen virtuális gépet raksz alá, magától skálázódik teljesítmény problémák nélkül szinte a végtelenségig, egyszerű árazás mellett.
--
Az Amazon RDS eseten is lehet olyan dolgokat allitgatni, amik valojaban kozvetlenul virtualis gep-parameterekre vetulnek le, ez meg nem donti el azt, hogy valami PaaS vagy IaaS. Attol, mert te csak egy SQL szervert akarsz berelni, meg koltsegtervezesi okokbol akarhatod befolyasolni, hogy az instance-nak mennyi memoria alljon rendelkezesere, ami peldaul elsosorban virtualis gep-parameter, semmint SQL Server parameter, de ettol meg te nem VPS szolgaltatast veszel, hanem csak egy cloudos SQL-t. Lehet, hogy mogotte egy replikalt es/vagy loadbalancolt instance-rendszer epul fel az altalad megadott adatokbol.
--
Blog | @hron84
Üzemeltető macik
"id,timestamp,value(float)"
Ilyen adatszerkezetnél én a helyedben Cassandra-t akasztanék le szögről a cloud-ban, az pont erre való - idősoros adatok tárolására, szóval szerintem értelmetlen ilyen adatokat RDBMS-ben tartani.
+1 Cassandra / Accumulo.
Ha főként csak insert van, és a lekérezések ritkák, esetleg csak kiértékelés folyik a felgyült adatok alapján (pl naponta 1x, vagy óránként), akkor pedig bazinagy szöveges cucc-ba append, majd hdfs-re vele és hadoop mapreduce. (a cassandra és az accumulo is hadoop alapu, de azok key/value store-ok és csak a hdfs részt használják). Ha tömeges adat kiértékelést szeretnél, akkor én hadoop* megoldásnak esnék neki
// Happy debugging, suckers
#define true (rand() > 10)
Esetleg Couchbase?
En meg azt gondolom, hogy ha Cassandraban akarnak tartani, akkor abban lenne. A nyito postbol vilagos, hogy van egy kesz program, aminek - az elozetes meresek alapjan - tarhelyet keresnek, es nem most akarjak nagy hirtelen lefejleszteni / atfejleszteni az egeszet.
--
Blog | @hron84
Üzemeltető macik
Nem egy komplex rendszerről van szó és az eddigiek alapján nekem az a kialakult képem, hogy éppen azon döntés előtt állnak, hogy hova költöztessék a rendszert, beleértve akár azt is, hogy IaaS-ról PaaS vagy SaaS alapokra állnak át. De nyilván nem értek ehhez sem... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Igen, viszont egy koltoztetes (= atirok nehany szamot egy konfigban) vs database engine atallas nem teljesen ugyanaz a szitu. Raadasul pont az adatszerkezetbol gondolom, hogy ez nem egy onmagaert valo rendszer, hanem valami nagyobbnak a resze, marpedig egy blognal picit is komplexebb rendszert akkor egyszeru karbantartani, ha egyseges reszekbol tevodik ossze. Lehet egyenieskedni, de annak konkret okainak kell lennie, nem csak az, hogy a CouchDB szebb meg jobb. Ez nem csak fejlesztesi kerdes, hanem uzemeltetesi is, ahhoz meg engedd meg, hogy idestova 8 ev gyakorlattal en is ertsek... persze nem sokat, csak egy cseppecsket.
--
Blog | @hron84
Üzemeltető macik
-
"Raadasul pont az adatszerkezetbol gondolom, hogy ez nem egy onmagaert valo rendszer, hanem valami nagyobbnak a resze, marpedig egy blognal picit is komplexebb rendszert akkor egyszeru karbantartani, ha egyseges reszekbol tevodik ossze."
Én annak a híve vagyok, hogy feladathoz keressük az eszköz és nem a meglévő kompetenciához igazítjuk az üzleti igényt... az üzleti igény pedig nem RDBMS-t igényel, mert... leírtam már, de mindegy, hagyjuk... inkább üssük be kalapáccsal a facsavart a gipszkarton falba, mert 8 éven át így csináltuk és mindenkinek jó volt.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Nem, felreerted. En nem beszeltem kompetenciarol. Olvasgattam makgab irasait, nem gondolom azt, hogy a CouchDB szamara megoldhatatlan problemat jelentene.
Igazad van, az uzleti igeny valoban nem RDBMS-t igenyel - ha az az uzleti igeny, hogy a fent felsorolt jellegu adatokat taroljunk. Viszont en ketelkedek abban, hogy ez lenne az uzlet igenye, hogy egy csomo szamot timestamppal taroljunk. Ezek vagy valami meresi adatok, vagy valamilyen allapot adata valamilyen kulso eszkoznek. Mindket esetben az ertekek nem onmagukban valok, illetve maguk az adatok onmagukban meg nem alkotnak ertelmes egeszet, a problema egy fokkal komplexebb, valoszinuleg van egy eszkoz vagy alkalmazas ami eloallitja ezeket a szamokat, es van egy feldolgozo eszkoz vagy alkalmazas ami feldolgozza oket. Ez az adatbazis egyfajta kozvetito reteget kepvisel, plusz archivalja az atadott uzeneteket. Mivel a szamok onmagukban nem alkotnak ertelmes rekordot, csak ugy, ha valamihez kotik oket, azt gondolom, hogy azert lett ez az adatbazis elszeparalva a rendszer tobbi reszetol, hogy ha a szamokat tartalmazo adatbazis tulno egy meretet, akkor ne a fo rendszer adatbazisat tegye hasznalhatatlanna. Ez onmagaban veve alapvetoen nem szokatlan megoldas olyan adatbazisrendszereknel, ahol letezik az adatbazis meretkorlatjanak intezmenye, peldaul Oracle RDBMS vagy MS SQL eseten (noha nem feltetlen ez a legjobb megoldas). Mivel Oracle eseten lehet adatparticionalni is (illetve vannak sokkal kifinomultabb megoldasai is erre a problemara), ebbol gondolom, hogy az alkalmazas MS SQL-ben irodott (bar adatparticionalas ott is van, sokkal kevesbe hasznaljak), foleg, mivel a topicindito is e menten kezdett el kerdezoskodni.
En nem vagyok fejleszto, de azt gondolom, hogy ha csak egy darab komponens miatt kellene egy komplett uj fuggoseget berantani, csak azert, mert szerintem nem szep MS SQL-ben megvalositva, akkor a projektvezetom / product ownerem ugy vagna nyakon, ahogy illik. Teljesitmeny tekinteteben nincs erv a CouchDB mellett, hiszen ezeket az adatokat nem kell se gyorsan elerni, se gyorsan keresni, egyedul az INSERT muvelet sebessege szamit (ezt a topicindito leirasabol vettem), valoszinuleg valami riport-jellegu feldolgozas van adott idoszakonkent (orankent, hetente, franc tudja, nem is erdekes), aminek nincs felso idokorlatja, ha ot oran keresztul fut, az se erdekel senkit, amig a riportban vannak az elore megadott felteteleknek megfelelo szamok.
Csak egy darab tablaert, aminek az egyes rekordjai a kutyat nem erdeklik, behozni egy plusz komponenstol valo fuggest ugy, hogy igazabol konkret nyereseg nem realizalhato (a realizalhato nyereseg pedig irrelevans a feltetelezheto feladat szemszogebol) - szerintem ez hiba lenne. Raadasul ugy, hogy a CouchDB egy plusz uzemeltetendo valamit jelentene, egy idegen testet egy MS SQL-re epulo infraban, az otlet uzemeltetesi szempontbol is vet fel kerdojeleket - mindezeket meg mindig ugy, hogy nem latok erdemi nyereseget.
Szep dolog a NoSQL, en is hasznalom nagyon-nagyon sok helyen - ahol ertelme van. De csak azert, mert hirtelen termett egy olyan tablam, amit gazdasagosabb NoSQL-ben tarolni, meg nem fogok egybol egy NoSQL szerver telepito CD-ert rohanni.
--
Blog | @hron84
Üzemeltető macik
> olyan adatbazisrendszereknel, ahol letezik az adatbazis meretkorlatjanak intezmenye
> MS SQL
Hát elvileg igen, gyakorlatilag azért az 524 272 terabájtos méretkorlátozás nem hinném, hogy túl sok céget érintene. Ahol ez gond, ott úgyis egyedi megoldással fognak már dolgozni. Ez amúgy adatbázisonként értendő, abból pedig összesen 32 767 darab lehet egy instance-ben.
Köszönjük szépen Mr. Brossúra válaszát, sokat segített ezzel a tanácsadó szagú válasszal, aminek köze nincs a valós helyzetekhez.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
Tudod, mire gondoltam? Mert szerintem nem.
Az MS SQL alatt az adatbazisoknak egyedi meretkorlat adhato. Nevezheted ezt kvotanak is, engem igazabol nem izgat, de jobb lenne, ha utanaolvasnal mielott eloveszed a brossurat es a szerver limiteket kezded el sorolni, amik senkit nem izgatnak.
--
Blog | @hron84
Üzemeltető macik
Ezek szerint nem jött át a lényeg. :(
Most akkor az hátrány, hogy kvótázni lehet az adatbázist? CouchDB-nél nem lehet limitálni, hogy adott esetben az adatbázis ne terítse be az egész storage-et?
Nem. Egy szoval nem irtam, hogy hatrany. Legyszives, olvasd el az altalad kiragadott mondatot a kontextusaban:
"azt gondolom, hogy azert lett ez az adatbazis elszeparalva a rendszer tobbi reszetol, hogy ha a szamokat tartalmazo adatbazis tulno egy meretet, akkor ne a fo rendszer adatbazisat tegye hasznalhatatlanna. Ez onmagaban veve alapvetoen nem szokatlan megoldas olyan adatbazisrendszereknel, ahol letezik az adatbazis meretkorlatjanak intezmenye"
Ket dologrol nincs itt szo:
- a szerver szintu limitekrol
- a kvotazas hatranyairol
Amirol itt szo van, az egy adatbazis-tervezoi gyakorlat, miszerint a tarhely-ehes tablakat neha kiszervezik kulon adatbazisba, mert a fo adatbazis mar rendelkezik egy jol tervezheto meretkorlattal, amiben nem szivesen latott vendeg egy olyan tabla, aminek a merete onmagaban veve kiteszi a fo adatbazis meretenek tizszereset. Raadasul a kulon adatbazissal mod es lehetoseg nyilik az ilyen jellegu tablakat egy teljesen kulonallo kotetre (particiora) tenni, teljesen fuggetlenne teve ez altal a fo adatbazistol. Noha ez elerheto lenne adatparticionalassal is, megis van, amikor inkabb a teljesen kulonallo adatbazist valasztjak azok, akik az adatbazist tervezik - akar azert, mert nem ismerik annyira az MS SQL-t, akar azert, mert valami mas indok is kozrejatszik a dologban.
Otletem sincs, honnet jottek azok az infok, amiket belelattal az irasomba.
--
Blog | @hron84
Üzemeltető macik
> Otletem sincs, honnet jottek azok az infok, amiket belelattal az irasomba.
Lehet, hogy igazad van (ebben az esetben bocsánat), de most nincs kedvem újraolvasni az egészet. Szerintem a reggel nyolc előtt készülő posztjaimat egyébként ignorálhatod is. ;)
"Igazad van, az uzleti igeny valoban nem RDBMS-t igenyel - [bla-bla-bla]"
Ennyi a lényeg, nem kell túlgondolni.
"aminek nincs felso idokorlatja, ha ot oran keresztul fut, az se erdekel senkit, amig a riportban vannak az elore megadott felteteleknek megfelelo szamok"
Az RDBMS relációkat kezel, a NoSQL pedig adatsorokon és mapreduce alapokon dolgozik. Nyers idősoros adatok kezelésére nem szokás RDBMS-t használni manapság, mert nem arra való, a mapreduce eredményét viszont lehet RDBMS-be tenni és ott analizálni az eredményt.
"csak azert, mert szerintem nem szep MS SQL-ben megvalositva"
Nem azért, mert nem szép, hanem mert nagyon nem hatékony, nem arra való, drágább lesz üzemeltetni, nagyobb erőforrást, több odafigyelést, élő munkát igényel, satöbbi.
"De csak azert, mert hirtelen termett egy olyan tablam, amit gazdasagosabb NoSQL-ben tarolni, meg nem fogok egybol egy NoSQL szerver telepito CD-ert rohanni. "
Hát pedig de... főleg cloud-ba költözéskor pláne és erősen de.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
"Hát pedig de... főleg cloud-ba költözéskor pláne és erősen de."
Hat pedig foleg a cloudnal erdekes ez az egesz. Mert ha nem magad telepited a VPS-eket, hanem platformokat vasarolsz, akkor nagyon nem mindegy, hogy egy darab MS SQL instance-ert kell fizetned, vagy egy darab MS SQL plusz egy darab CouchDB instance-ert. Ez dupla penz ugy, hogy igazabol ezt a feladatot az RDBMS is lefedi, meg ha nem is idealis a feladatra. Most nezegettem az Amazon arait, es egy bizonyos szintig igazabol jobban jarsz, ha egy darab RDS instance-t veszel nagyobb tarhellyel, mintha ket RDS instance-t uzemeltetsz, mert a tarhely az olcsobb.
A magad telepitette gepekkel persze nincs ilyen problema, mert egy MS SQL meg egy CouchDB szerver nagyon szepen megfer egymas mellett - de akkor mi a francnak mesz cloudba? Egy csomo minden elony elveszik igy...
Ezzel egyutt az a gyanum, hogy nem fogunk egyezsegre jutni, mert te mindig is a fejleszto oldalarol fogsz kozeliteni en meg mindig az uzemeltetes oldalarol. Elhiszem, hogy a mapreduce erre valo, sot, koszonom, hogy ezt az infot megosztottad velem - ugyanakkor azert egy adott adatsoron vegzett par statisztikai szamitas meg egy RDBMS kepessegeit se haladja meg, mert ilyen feladatokat ezek a cuccok vegeztek mar akkor is, amikor a NoSQL orulet meg fasorban sem volt. Az RDBMS-ek nem lettek butabbak csak azert, mert megjelentek a NoSQL cuccok - csak a fejlesztok beleugrottak ebbe az uj oruletbe, csak mert a lekerdezeseiket nem kell annyira optimalizalni, es igy is olyan sebesseggel futnak, mint egy jol megtervezett RDBMS adatbazison. Ettol az RDBMS meg nem valik hulladektelepre valova.
--
Blog | @hron84
Üzemeltető macik
"Ezzel egyutt az a gyanum, hogy nem fogunk egyezsegre jutni, mert te mindig is a fejleszto oldalarol fogsz kozeliteni en meg mindig az uzemeltetes oldalarol."
Nem, én általában architect oldalról közelítem meg, figyelembe véve az üzlet, a fejlesztés, a tesztelés és az üzemeltetés feladatait, kompetenciáit is... ugyanis a legtöbb esetnél elég sok opció van a feladat megoldására és úgy kell megoldani, hogy cégszinten maximális legyen a haszon.
Szóval hiába találsz ki egy nagyon jól üzemeltethető rendszert, ha a fejlesztők szopnak a fejlesztéssel vagy az üzletnél csapódik le a plusz emberi erőforrás... ugyanez fordítva is igaz, ha az üzletnél elég sok bevétel jön egy módosítással, akkor azt akkor is érdemes bevállalni, ha ez miatt az üzemeltetők minden éjjel felkelnek, mert gyorsan csak ilyen megoldást lehetett csinálni, ésatöbbi.
"Ez dupla penz ugy, hogy igazabol ezt a feladatot az RDBMS is lefedi, meg ha nem is idealis a feladatra."
Miért lenne dupla pénz? Aktuálisan használt erőforrásra fizetsz, nem darabra. Ha a CouchDB/Cassandra ezt megoldja havonta $5 pénzből a maradékot meg az MSSQL megoldja $20 pénzből (hasamra ütöttem), a másik opció esetén meg $50 havonta a tisztán MSSQL, akkor ki lehet számolni a TCO-t, megnézni, mennyibe kerül a NoSQL bevezetése, ha megtérül, akkor _meg_ _kell_ _csinálni_.
Ha nem térül meg, akkor az ember megvonja a vállát és alkalmazza az orosz tűzoltók mondását: "hagyni kell leégni a picsába" és valami más hasznos dologgal tölti az idejét.
Mér, számol, dolgozik. És nem az üzemeltetés vagy az IT a drive, hanem az üzlet. Mindig.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home
" a másik opció esetén meg $50 havonta a tisztán MSSQL"
Stop, mitol lesz dupla osszegu a MSSQL? Marmint, az amirol beszelgetunk, megoldhato ugyanazon instance-n belul, a tarhely pedig altalaban nem szokta megduplazni az instance arat (illetve ahhoz _nagyon_ sok tarhelyet kell venni, hogy ez igy legyen).
En azt latom, hogy ez inkabb a $20 vagy $25 aru MS SQL-rol szolo vita, marpedig az uzemelteto plusz orakoltsege barmilyen esetben tobb lesz, mint $5 - nem beszelve a fejleszto oradijarol, ami az egyik legdragabb a piacon.
"Mér, számol, dolgozik. És nem az üzemeltetés vagy az IT a drive, hanem az üzlet. Mindig."
Ezzel hadd ne ertsek egyet teljes mertekben. Addig igazad van, hogy a vegso dontest az uzlet hozza meg, de igenis az uzemeltetes is mer, szamol, dolgozik, meg ha te, mint architekt ezt nem is latod. Mert az uzlet csak az uzemeltetes altal megadott ido- es eszkozigeny menten tud dontest hozni, ugyanis jellegebol fakadoan soha nem fog erteni az uzlet az uzemelteteshez vagy a fejleszteshez - nem is feladata neki. Raadasul ez egy oda- es visszahato folyamat, az uzemeltetesnek (vagy az architektnek) valahol azert meg kell fognia a nagyon elszabadult uzleti otleteket, hiszen minden szereplonek az az erdeke, hogy a szeker lehetoleg ne szabaduljon el a lejton a szakadek fele.
En azt gondolom, hogy egy jol mukodo cegnel az uzlet es az uzemeltetes nem egymas ellen dolgoznak, hanem osszehangolt csapatmunka zajlik, ahol vilagosak a celok, es nem parancsuralmi rendszer van, hanem egyuttmukodes a celok elerese erdekeben. Mindenki ugyanabban a csonakban evez, ha valaki forditva huzgalja az evezolapatot, azzal csak hatraltatja a tobbit, raadasul o sem er celba, csak a folyo kozepen fog csapkodni. Es ha lathatolag egy sziklaszirt fele megy a hajo, akkor mindenkinek kotelessege ezt minden rendelkezesre allo eszozzel jelezni, hiszen ha felfordulnak, az mindenki szamara csak rossz.
--
Blog | @hron84
Üzemeltető macik
Érdekel, hogy ki mekkora adatbázissal, rekordszámmal dolgozik. Ill. milyen környezetben fut (SQL,hw környezet...), milyen teljesítménnyel.
Nálam így néz ki jelenleg az architektúra: http://prezi.javaforum.hu/gacivs-devop/#/3/2
Az adatbázis jelenleg ~500MB körül van, de horizontálisan és vertikálisan is skálázható, néhány TB méretig teszteltem generált adatokkal.
--
https://test.gacivs.info
Ezekhez az ilyen 2D-ben navigalos prezentaciokhoz nem kellene egy palyanezegetot kitenni?
Tudod Doom alatt is volt ilyen:)
Vagy egy God mod, ahol le lehet PDF-ben tolteni:-D
Rinyalast leszamitva, koszi a prezentaciot, atnezem.
Szerk: En voltam a lama, alul az oldalszamozas egyertelmu (3, 4-1, 4-2, 5, stb).
Szoval amelyikben tobb fejezet van, ott le lehet lefele menni.
Szerk 2.: Most akkor teljesen kliens oldalon van megoldva a load-balancing?
Szerver oldalon csak a node-ok vannak amik a hatterben egy cassandra cloud-hoz csatlakoznak?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
megkérdezem az illetékeseket hogy mennyit árulhatok el;)
// Happy debugging, suckers
#define true (rand() > 10)
Van valakinek nagy PgSQL adatbázisa? Kíváncsi lennék mit produkál. :)
Nézz fel a postgresql-performance levlistára. :) Nekem amúgy van, de olyan 100MB körüli, megy szépen.
EnterpriseDB-ben ( fizetős PostgresSQL ) 30 GB Adattartalom elég nagy?
Nem Azureban van, hanem virtuális gépen! 8 Core, 24 GB RAM, másodpercenként 15-20 sor megy bele és 15 percenként kb 10000 sor megy át egy másik táblába. Ha kell bemásolom az postgres.conf-ot, ami erre a HW-re van optimalizálva!
2-4 TB-ig es 50 millio soros tablakig/materialized view-okig ha nem irsz brutal sokat brutal surun, es esszel irsz query-ket, teljesen jo a Postgres. Replikalni problemasabb, mint egy NoSQL-t, de ugyanakkor azonos hardveren efolott kezdenek kijonni bizonyos NoSQL megoldasok elonyei (amikert cserebe altalaban le kell mondani valamirol, ami RDBMS-ben van).
Igazabol a teljesitmeny attol fugg, mennyire optimalizalod be a mogottes DB-t. Lattam mar 40 GB-s adatbazist bunlassunak lenni, es lattam 60-80 GB-st piszok gyorsnak (mindketto MySQL, es mindkettoben volt egy-tobb tobbezres, tobbtizezres vagy meg nagyobb tabla). A sebesseget nem feltetlen befolyasolja a meret, az RDBMS-ek igyekeznek ugy tarolni az adatot, hogy ez ne befolyasolja erdemben a teljesitmenyt. Jol belott indexekkel, okos szervezessel akarmekkora adattartalom kenyelmesen kezelheto.
Ami a HW-t illeti, megmondom oszinten, en adatbazis ala a minel gyorsabb tarolo hive vagyok. SSD, ha nem lehet, akkor a leheto leggyorsabb winyokbol allo tomb. Amikkel eddig dolgoztam: volt SSD-ben RAID (gyors, de draga ha kiesik egy-egy disk, csak nagy meretekben eri meg), hw-es es sw-es RAID5-6-10 (nagyon oda kell figyelni, volt egy-ket hardveres megoldas, ami... hat fogalmazzunk ugy, nem nyugozott le, de meglehetosen alacsony szam allt az arcedulajan - szoval ez nem volt veletlen, a jo minosegu hw-ek mindig meghalaljak az arukat, es egyebkent se ezen sporolunk).
Memoriabol a minel tobb a jobb. Egyreszt a kulonfele query cacheknek meglehetosen sok memoria kell, bar ez nyilvan app fuggo, masreszt - ezert nem biztos, hogy nepszeru leszek, bar... mindegy - en jo otletnek tartom a jo nagy olvasasi diszk cache-t - a memorianal semmi nem gyorsabb, talan csak egy gyorsabb memoria. Az irasit persze vissza kell fogni - senkienk nem hianyzik egy hatalmas adatvesztes egy veletlen kernelpaniknal.
A CPU teljesen feladatfuggo, sima lookupokhoz tapasztalatom szerint nem kell sok, a legtobb esetben ugyis a hattertarolora / memoriara varunk, azon a proci eleg keveset dob. Az indexek meg a ravasz lekerdezesek viszont szeretik a gyorsat, en magam az Intel procikra szoktam ra, egy ideje meg igazabol mindegy, nem erzek effektiv kulonbseget ilyen altalanos jellegu feladatoknal, mint egy DB szerver. De a procikhoz kotodo nedves almokat altalaban a penztarca szokta bekorlatozni, nyilvan a Xeon procik a legjobbak szerverbe, de...
--
Blog | @hron84
Üzemeltető macik
Ahogy a kiirasbol is latod, minden egyes tier-nek van egy tarhely limitje, amit ha elersz, az SQL dob egy hibakodot, es abbol lehet tudni, hogy betelt a zsak. Ezen felul minden instance max 150 db SQL adatbazist tamogat, ebbol 149-et hozhatsz letre te, a 150. a master adatbazis.
Minden egyeb szempontbol ezek az instance-k tobbe-kevesbe ugy viselkednek, mint a valodi SQL szerverek (hiszen valojaban az is fut mogottuk), teljes mertekben transzparensek azokkal. Ami el tudja donteni az Azure SQL vs VPS kerdest, az az, hogy mennyire szeretnetek belenyulni az SQL szerver mukodesebe? Van egy csomo olyan parameter, ami belulrol is allithato, meg van egy csomo olyan, amihez mar registry-buhera meg minden mas kell. Az elso kategoriaban is lehetnek olyanok, amiket egy felhos szolgaltato bekorlatoz a szolgaltatas vedelme erdekeben, a masodikbol pedig szinte biztosan nem tudtok igenybe venni semmit, az olyan tuninghoz mar VPS kell. Ha van barmi olyan tuningotok, ami kell az adatbazis stabil uzemelesehez, de a szolgaltatasban az nem elerheto, akkor mindenkeppen VPS-t kell vennetek, minden mas esetben en azt gondolom, hogy az Azure SQL bosegesen eleg szamotokra (bar tarhelyben en azt ajanlom, egy kicsit inkabb lojetek fole, ha a penztarca megengedi, hogy biztos ne szaladjatok bele a storage limitbe).
Az MS Azure arazasaban kevesbe vagyok otthon, de az Amazon RDS az hasonlo szolgaltatast nyujt, mint az Azure SQL, es az arak nem nagyon ternek el, kb. az SQL szerver licencdijaval kerul tobbe az RDS instance, mint egy hasonlo felepitesu VPS - gondolom az Azure eseten is valami hasonlo van, de majd jon mrceeka es kijavit pontosabb adatokkal. Amit viszont nyerni tudtok az ugyon, az az, hogy egy SQL instance-t nem nektek kell karbantartani, frissiteni, javitani ha valami hibaja van, ez a szolgaltato felelossege (hiszen ti nem is fertek hozza az adott VPS instance-hoz), tehat uzemeltetesi oldalrol eggyel kevesebb infrastruktura-elemere kell gondot forditani.
--
Blog | @hron84
Üzemeltető macik