Dotaz: Kolik transakcí se dá udělat za sekundu?

[Tomáš]

Omlouvám se za úplně stupidní dotaz, ale nejsem v databázích zběhlý a nevím pořádně co vlastně hledat.

V práci máme nějaké aplikace, které můžou produkovat docela hodně logů (textové soubory), které se pak musejí zpracovávat a celé je to docela zdlouhavé a nepohodlné.

Napadlo mě, že kdybychom logovali přímo do nějaké databáze, tak by se celý proces zjednodušil. Tak se ptám, jestli by to vůbec ta databáze unesla.

Na několika počítačích beží dohromady asi 80-100 procesů (asi by to šlo předělat na vlákna, ale to s tím asi nesouvisí), z nichž každý může ukládat až 10 řádků za sekundu (když se to hodně blbě sejde). V texťáku má ten řádek většinou mezi 100 a 200 znaky (v 15 sloupcích), při použití numerických kódů by to šlo stáhnout tak na půlku. Všechny ty počítače jsou dost vytížené, takže databáze by nejspíš běžela na úplně jiném stroji.

Tak bych rád věděl, jestli by to mohlo vůbec fungovat. Ten databázový stroj by asi byl průměrný desktop, dá se čekat dvoujádrový procesor kolem 2,5-3GHz, paměť tak 2GB. Asi bych nasadil nějakou rozšířenější neplacenou databázi (MySQL, PostgreSQL). Bylo by myslitelné nasadit tam sqlite (zdá se mi jednodušší)?

Díky za všechny odpovědi, stačí i odkazy, kam se podívat.

Odpovědi

[okbob]

Databáze by to unesly, ale asi by Vám to bylo k ničemu. V případě, že ukládáte do databáze primárně texty, tak by se asi zjednodušil zápis, ale výkonnostně (při zpracování) by to bylo +/- stejné - hrdlem je čtení z disku (a to jak v případě čtení ze souboru, tak v případě čtení z db). Výhodou databáze je snazší konstrukce dotazů - rychlostně by Vám klasická SQL db nepomohla.

Na podobné úlohy existuje speciální třída SQL databází tzv. Streaming databáze. Ty zpracovávají data průběžně. http://hansgilde.wordpress.com/2009/03/11/making-progress-on-streaming-sql-languages/

[Heron]

To je nějakých 1000 insertů za 1s, tj 200kB/s, to není moc. Fungovat by to mohlo za několika předpokladů. Ta logovací tabulka by neměla mít indexy a tedy by se z ní nemělo číst. Jednou za čas (hodina, den podle potřeby) se ta tabulka přejmenuje a zpracuje pro další použití. Data se tak stále ukládájí do malé tabulky.

Občas (pro velmi vysoký výkon) se dělá Master-Slave replikace. Na master se ukládají data, ze slave se čtou a ve třetí DB (nebo v programu) pak zpracovávají.

S MySQL nebo PostgreSQL nic nepokazíš. Obě umí replikace (do budoucna, až těch zapisovačů bude 700 ), se to může hodit. MySQL s engine MYISAM by mohla být nejrychlejší. To chce vyzkoušet.

[cronin]

Cely tento dotaz je spatny. Opisujes problem velmi vagne, a zaroven podsuvas riesenie. Najskor skus lepsie definovat problem: Ake aplikacie? Ake logy? Je moznost obmedzit logovanie? Ako casto sa logy rotuju? Ako sa neskor spracovavaju? Co konkretne je "zdlhave a nepohodlne"? Kvantifikuj co znamena "zdlhave". Definuj co znamena "nepohodlne".

[Tomáš Pěnička]

Aplikace jsou věci na testovaní vyvíjeného produktu. Logují se chybové stavy, takže se dají omezit jenom tím, že všechno bude fungovat bez chyby (už aby to bylo!). Test může běžet několik málo dní, logy se analyzují od oka průběžně a důkladně po skončení testu. Nepohodlné znamená, že máme mraky souborů rozsypané na několika počítačích a v mnoha adresářích. Pak se musejí všechny logy nakopírovat na jedno místo a nějak je naparsovat a dostat z nich informace. Protože jde o vývoj, nedá se říct přesně, jaké informace hledáme, spíš to je hledání podezřelých stavů, čili hledání správného pohledu na data.

[cronin]

Z dlhodobeho hladiska odporucam precitat si knihy "Pragmatic programmer" a "Art of UNIX programming"; obe vysli nedavno aj v ceskom preklade. Netreba sa bat, v oboch nie je ani riadok zdrojoveho kodu.

Z kratkodobeho hladiska by ukladanie logov na zdielany disk umoznilo vyhnut sa pracnemu zbieraniu. Nad pribezne sa zapisujucimi logmi by mohli bezat predbezne analyzy, co by mohlo usetrit cas: "parser" by sa vyvijal subezne z testami, na konci testovacieho kola by boli k dispozicii logy okamzite na opatovne spracovanie. "Parser" by sa snad cim dalej tym viac vyvijal do stavu, aby fungoval co mozno najviac automatizovane.

[osvc1]

to co jste napsal je ok a uz jenom podle toho zapisku, kdybych mel s vami pracovat v nejakem projektu, tak bych do toho bez dalsiho sel.

Bohuzel dnes nenajdete moc lidi, kteri to vidi takhle. Vsechno co vyslo z vysokych skol po roce 2000 dnes neni schopno jit ani na zachod bez nejakeho grafickeho IDE. Zrovna tak se na skolach nekolik semestru omilaji databaze, pak se neni co divit, ze pri jakemkoliv problemu se po nejake databazi vola.

[stativ]

Vsechno co vyslo z vysokych skol po roce 2000 dnes neni schopno jit ani na zachod bez nejakeho grafickeho IDE.

Potřebu IDE náhodou docela chápu. Mě osobně nedělá problém používat ex-vi na editaci a na vyhledávání grep, ale v IDE je to jednodušší a hlavně pohodlnější a díky tomu jsem efektivnější. Výjimku zatím stále tvoří VCS (mercurial, subversion, git), které používám jen z řádky.

[okbob]

Problém není v juniorech, ale v seniorech, kteří nedokáží juniory vychovávat a rozvíjet :(

[Radim Kolář]

Jenomze dneska se nevyplati do junioru investovat cas a prostredky protoze jakmile ziskaji praxi tak zdrhnou za lepsi nabidkou. O kvalifikovane lidi v IT je velky zajem a vzdy se najde nekdo kdo vas preplati.

Ja jsem to asi 6 let zkousel a opravdu to nema cenu. Kdyz nezdrhnou a jsou za ty leta vycviku dobri tak vas zacnou vydirat: nabidli mi XX tisic a pokud nezaplatite XX + 5 tak jdu tam a vezmu si s sebou i par ostatnich.

[moira]

To je ale prostě zákon nabídky a poptávky. Buď najmu juniora, který se spokojí s menším platem nebo rovnou najmu někoho zkušeného ale prostě to bude stát víc. Mám pocit, jako by jsi chtěl někoho, kdo má zkušenosti ale platit bys mu chtěl jako človekovi bez nich. Jasně že vyškolení juniora stojí peníze, které ti pak jakoby "utečou", ale když najmeš profíka, tak ty peníze "navíc" zase vrazíš do jeho platu. Nebo ne?

[okbob]

Jednak si nemyslím, že to je jen o těch školeních - je to hlavně o času. Druhak - to je samozřejmé chování - za ta léta už nebudou Junioři - a pokud je firma nepovýší sama, tak utečou. Na druhou stranu - senior se zkušenostmi z konkrétní firmy má 10x větší produktivitu než junior.

Na pozici juniora nikdo schopný nebude dlouho. A bohužel - tady v ČR se nenosí automatické navýšení platu podle kvality, zkušeností (u IT firem).

[tecik]

Vtipne je to, ze si toto nejspis rikali Vasi seniori, kdyz jste byl junior Nic noveho, nic necekaneho A stale je to jeden krasny kruh

[moira]

Vsechno co vyslo z vysokych skol po roce 2000 dnes neni schopno jit ani na zachod bez nejakeho grafickeho IDE.

Tak to zase prrr, tohle se mě skoro dotklo

[podlesh]

Tak to skoro zafungovalo správně.

[lertimir]

Databáze primárně neurychli takovou úlohu, a ani nepomůže v analýze. databáze je v principu na udržení integrity dat. Tohle je dle mne přesně úloha na syslog. Když bych tohle dělal rozmyslet bych si co a kam chci logovat, nastavil aplikace at logují na syslog na nějaký cetrální logovací server, na syslogu si nastavil které aplikace to mají posílat do kterých logovacích souborů, a v závislosti jestli bych potřeboval okamžitou reakci nebo stačilo by pozdější zpracování tak bud nastavil nejaký online monitorovací systém jako hobit nebo vytvořil skripty na anjalýzu tech logů.

[tecik]

Dokonce by bylo lepsi logovat na jiny server Neni problem logovat syslogem vzdalene... a myslim ze by to slo i celkem rozumne nastavit, takze mnohem mene prace jak s DB, a aplikaci ktera to "tlaci do ni".

[Radim Kolář]

Na 3 GHZ singlecore ve VmWare se da udelat asi 7200 transakci za sekundu na PGSQL 8.3 nebo na DB2 9.5 za predpokladu ze se to podpori kvalitnim diskovym subsystemem a nejakou tou rozumnou pameti - tak 4 GB. Je potreba pouzivat prepared statementy.

Kdybych to delal pro sebe tak bych si tam dal DB2 EXPC, snadneji a rychleji se to oproti pgsql zalohuje, a v OLAP je to rychlejsi a jsou na to lepsi tooly. Pgsql se lepe zalohuje nez mysql (ma rollforward). Pokud ale neplanujete ty data zalohovat tak je to uplne fuk, co nasadite za databazi (krome sqlite na neni moc multiuser) protoze pozadovanou spicku 1000 insertu/sec by meli na dnesnim HW zvladat vsechny.

[AraxoN]

Ak ide len o to, že chceš logovať na jednom mieste, tak logovanie po sieti zvláda napríklad syslog-ng.

MySQL a PostgreSQL predpokladanú záťaž zvládnu pravdepodobne rovnako dobre. Ak pôjde väčšinu času len o inserty, tak rozhodujúca bude IMHO rýchlosť disku.

SQLite by som zo svojich úvah vypustil, lebo by si musel mať zdieľaný ten súbor po sieti a tam sú problémy pri zamykaní (závisí od protokolu), plus výkon znižuje réžia ďalšej vrstvy.

[trekker.dk]

Ak ide len o to, že chceš logovať na jednom mieste, tak logovanie po sieti zvláda napríklad syslog-ng.

Popřípadě svlogd - pouze UDP, ale na vnitřní síti to asi stačí.

[Tomáš]

Díky všem za odpovědi. Zamyslím se ještě jednou, jestli opravdu potřebuji databázi. Zatím jsem se nezamýšlel nad syslogem, ve firmě jsou preferovány Windowsy a tam veškeré užitečné programy chybí. Když teď vím, co hledat, tak to i najdu.

[oldfrog]

Kdyz budete do databaze logovat strukturovane, pomuze vam databaze s ditribuovanim logu (z vice stroju na jeden logovaci server) i se zpracovanim (odpadne parsovani textovych souboru). Takze to ve vysledku muze byt lepsi reseni, nez plain text logovani do souboru (jak nekdo navrhoval po siti pomoci syslog).

[Tomáš]

To jo jasné, o databázi jsem uvažoval, abych data měl zrovna strukturovaná (už teď jsou +- strukturovaná). Ale jak jsem pochopil diskusi, může to být kanón na vrabce. Zase na druhou stranu soubor se kopíruje jednodušeji, než databáze.

[okbob]

Co Vám brání si to vyzkoušet - udělat prototyp? Je to práce na odpoledne - a 100x lepší než si pak další rok nadávat do blbců. Každé řešení má svoje výhody a nevýhody.

[tecik]

Nechci Vas mistifikovat, ale kolega mi kdysi naznacil, ze i serverove Win umi SNAD odesilat systemove logy na vzdaleny server. Mozna by stalo za to prozkoumat tuto moznost (lec po googleni jsem nenasel nic extra zajimaveho).