Výpočet potřebného výkonu stroje pro DB

[chroo]

Ahoj,

mam svuj projekt (free mobilni aplikaci), delam to spis pro zabavu a mam nejake odhady kolik cca budu mit uzivatelu, kolik dat si oni ulozi, jak casto sluzbu pouziji a tak. Jak mam postupovat, kdyz bych rad spocital technicke prostredky, ktere pak dam databazovemu serveru Postgres?

P.S. prosim, odpovedi typu "proste to tam placni, o nic snad nejde" nebo "nech to odbornikovi" mi jsou k nicemu, snazim se to sam naucit a porozumet.

[Reklama]

[lobo]

tazko povedat na zaklade toho popisu
zalezi od toho ci je ta aplikacia narocna na zapis alebo citane a o aky objemoch dat hovoris.

je rozdiel ci mas 100k klientov zapisujucich nejaky 40bajtovy log kazdych 30 sekund, alebo ci mas 10k uzivatelov ktori tahaju ten isty balik dat naraz na klienta alebo 50 klientov uploadujucich 100 MB denne

[Pavel Stěhule]

Ahoj,

mam svuj projekt (free mobilni aplikaci), delam to spis pro zabavu a mam nejake odhady kolik cca budu mit uzivatelu, kolik dat si oni ulozi, jak casto sluzbu pouziji a tak. Jak mam postupovat, kdyz bych rad spocital technicke prostredky, ktere pak dam databazovemu serveru Postgres?

P.S. prosim, odpovedi typu "proste to tam placni, o nic snad nejde" nebo "nech to odbornikovi" mi jsou k nicemu, snazim se to sam naucit a porozumet.

Můžete udělat hrubý odhad - nic víc - databáze se při větší zátěži nechovají lineárně - a navíc dnes do toho vstupuje ještě virtualizace. Tudíž stejně je potřeba vždy počkat na provoz a pak podle potřeby jít s konfigurací nahoru nebo dolů. A ještě do toho vstupuje cena. Jaká jsou doporučení: 1. velikost RAM - pokud chcete opravdu rychlou aplikaci, pak pro DB byste měl mít víc 2-1x RAM velikosti databáze - např. eshopy. Tím se částečně eliminuje typicky pomalé IO ve virtuálech. Pokud máte rychlé IO a nepotřebujete ultrarychlou reakci, pak velikost paměti pro DB by neměla být méně než 1/10 velikosti databáze. Dalším faktorem je počet jader CPU, které by mělo být cca 1/10 max connection - případně 1/10 typického počtu aktivních uživatelů - např. jedna z největších www aplikací v ČR, ale dobře vyladěná potřebovala pro 10K přihlášených uživatelů cca 40 aktivních připojení do databáze - a 8CPU docela dobře stačilo. Dále platí jednoduché pravidlo - čím lépe a více používám cache, tím méně zdrojů mám v db, a naopak. Také záleží na tom, jaké dotazy tam posíláte, jak často tam posíláte pomalé dotazy, jak dobře se hitují cache datových stránek a pod - ale to se v podstatě nedá zjistit bez reálné zátěže.

[j]

Kdyz mas tu aplikaci tak to vyzkousej. Zajima te mnoztvi dat, pocet ctecich a zapisovych operaci ... a pak to zhruba vynasobis. Samo je to odhad. Idealne provedes test v aspon nekolika desitkach lidi. Z toho se to odhaduje o poznani lip. Nijak jinak se to zjistit neda.

Jak bylo receno, neplati to uplne linearne, protoze dvojnasobek lidi neznamena dvojnasobnou zatez.

[karel]

z vlastni skusenosti, vim ze se to moc odhadnout neda, vse ukaze cas a provoz, co se ale da je vymyslet si a odsimulovat navstevnost x uzivatelu, ale co je jeste lepsi odsimulovat jak se ti to bude chovat treba po roce provozu cili nahrn si tam vymyslena, ale radoby realna data. Mozna se budes divit, ze i s jednim clientem se to cele nejak kouse.

[Reklama]

[Filip Jirsák nepřihlášený]

Nikdy jsem neslyšel o tom, že by tohle někdo nějak počítal. Vždy je to v první fázi odhad na základě předchozích zkušeností, později upřesněný na základě simulací provozu.

[chroo]

Tak hruby odhad snad udelas, ne? Nebo jak se rozhodnes (napr.), jestli ti staci server s 1GB pameti nebo potrebujes 16? Ze to nejde spocitat presne a ukaze cas chapu a diky za tu informaci, ale hruby odhad snad problem neni.

[Pavel Stěhule]

Tak hruby odhad snad udelas, ne? Nebo jak se rozhodnes (napr.), jestli ti staci server s 1GB pameti nebo potrebujes 16? Ze to nejde spocitat presne a ukaze cas chapu a diky za tu informaci, ale hruby odhad snad problem neni.

Je to docela problém - ti, co dobře znají databáze, tak samozřejmě neznají jak se chovají konkrétní aplikace, a ti, co ty aplikace programují a administrují většinou málo znají databáze. Běžně se používají dvě strategie u nové aplikace - 1. vezmem takové železo, jaké máme, 2. vezmem takové železo, které jsme schopní (případně zákazník je schopen) zaplatit. Samozřejmě, že se to dá dělat i chytřeji, ale až na výjimky se stejně vaří z vody, jen se to trochu lépe podá, aby to vypadalo trochu technicky.

[andy]

Ide o to ake mas poziadavky. Pre niekoho je ideal aby vsetky data (resp aktualny working set) boli v RAM, pre ineho staci malicko, lebo tlaci do tabuliek logy alebo nieco. Mozes si pozriet manual postgresu, tam su nejake odporucania a potom to zratat podla svojho datoveho modelu/poziadaviek. Ale aj tak potom zistis, ze to je alchymia a databaza nie je jediny faktor a ovela jednoduchsie je urobit testy na konkretnom prostredi. Dalsi faktor uz Pavel spominal - virtualizace. Pre pomale disky je ine nastavenie ako pre SSD. Ak chces nejaky vzorec, tak to asi tazko.

[j]

U vetsiny databazi mas v dokumentaci neco na tema "pro databazi o velikosti N s pocetem IO operaci X doporucujeme HW Y". Pokud neznas ani N ani X tak muzes Y leda cucat z prstu. A samozrejme i ta doporucena vec je nejakej +- nastrel pro nejaky "bezny" vyuzivani.

Trebas, ja tu mam databazi, kterou zaroven pouziva rekneme +- 50 lidi. Ma to +- 200GB. Nastrel pro tohle je HW, co zvladne cca 5k IO, ma 32GB ram a 2x4 jadra. Realita je takova, ze RAMky by asi stacila i pulka, CPu jedno a disk 1/4novej (rychlostne).

Pak tu mam cosi co zovou aplikacnim serverem (coz to teda rozhodne neni ale necht), tam prozmenu tvrdej, ze to disk nepotrebuje prakticky vubec a stacej tomu 4GB ram + 2 jadra.  Realita je takova, ze to ma 16GB a 8jader a maka to na 50% i vic.

=> jinak nez realitou se stejne neda zjistit, co je potreba. Jedina jistota je, ze tvurce prevazne HW spis podstreluje, aby se pripadnymu zakaznikovi nezdalo, ze to bude stat moc penez.

[Pavel Stěhule]

=> jinak nez realitou se stejne neda zjistit, co je potreba. Jedina jistota je, ze tvurce prevazne HW spis podstreluje, aby se pripadnymu zakaznikovi nezdalo, ze to bude stat moc penez.

Nebo naopak přestřeluje, by si zjednodušil život a snížil riziko reklamací - určitě to není u všech projektů - ale jsou projekty, kde cena za hw jde jen do nutných nákladů, a slyšel jsem o databázích, kde po několika letech provozu bezproblémově přešli na poloviční mašinu.

[j]

Tak mozny je vsechno, ovsem moje zkusenot je takova, ze mam asi tak 10x vykonejsi HW nez pozadoval dodavatel, a bez dalsich "neautorizovanych" zasahu (jako trebas vlastni tvorba indexu) by se to nedalo pouzivat, a to tak ze vubec (no dobre, dalo, faktura se vyrabela jen asi 15 minut ...). Dodavateli treba neprijde divny, ze vyrobi tisicovku zaznamu v logu za minutu, ale smazat jich za minutu neumi ani 100. Ja jich za minutu smaznu i milion ...

[karel]

Tak mozny je vsechno, ovsem moje zkusenot je takova, ze mam asi tak 10x vykonejsi HW nez pozadoval dodavatel, a bez dalsich "neautorizovanych" zasahu (jako trebas vlastni tvorba indexu) by se to nedalo pouzivat, a to tak ze vubec (no dobre, dalo, faktura se vyrabela jen asi 15 minut ...). Dodavateli treba neprijde divny, ze vyrobi tisicovku zaznamu v logu za minutu, ale smazat jich za minutu neumi ani 100. Ja jich za minutu smaznu i milion ...

JJ tak to byva, sam sem nikdy optimalizace az tak nehrotil, o to se preci postara v mem pripade hosting, ale pak prisla doba kdy navstevnost sla nahoru a hosting se odmitl starat, nastoupil tedy pronajem dedik servru a uz sem se musel starat o vse, to sme pak s kamaradem stravili x veceru nad prepsani velke casti kodu tak aby se co nejvic pouzivaly cache kde to jen slo. Aby se dotazy rozpadly protoze nektere joiny trvaly moooc dlouho a nebyli ani spatne napsane jen se toho proste chtelo takrikajic moc, zvlast kdyz do toho jeste lili inzerty a update z jinych vlaken. 

Jak sem psal uplne jinak aplikace funguje na vyvojovem stroji, jinak na serveru, a uplne jinak po x mesicich ci letech provozu, kdy neuprosne pribyva zaznamu, ktere se treba jen sorti.






 

[Pavel Stěhule]

Tak mozny je vsechno, ovsem moje zkusenot je takova, ze mam asi tak 10x vykonejsi HW nez pozadoval dodavatel, a bez dalsich "neautorizovanych" zasahu (jako trebas vlastni tvorba indexu) by se to nedalo pouzivat, a to tak ze vubec (no dobre, dalo, faktura se vyrabela jen asi 15 minut ...). Dodavateli treba neprijde divny, ze vyrobi tisicovku zaznamu v logu za minutu, ale smazat jich za minutu neumi ani 100. Ja jich za minutu smaznu i milion ...

To už je ta realita - ne každý dodavatel má lidi, kteří rozumí databázím - navíc dost často evidentně nefunguje dlouhodobější vztah dodavatel - uživatel. Sám dělám databáze 15 let a deset let intenzivně a snažím se dodat aplikaci, která bezproblémově přežije náběh produkce a první měsíce - a pak udělám jedno doladění a korekci po měsíci, po půl roce, po roce. Některé chyby se objeví po dvou po třech letech - případně jen u některých zákazníků - větší databáze je nutné pořád sledovat a hlídat - a k tomu je potřeba spolupráce. Dost často ale dodavatel nemá vůbec žádnou zpětnou vazbu - slow queries, logy, ... a to pak nefunguje.

[Pavel Stěhule]

Po pár iteracích pak máte aplikaci, která drží roky. Samozřejmě nesmíte udělat zásadní návrhové chyby - to se pak po pár letech přijde na to, že je to pomalé a kromě totálního přepsání se skoro nic moc nedá dělat.