NetCount 0.4: Návrh databáze (diskuse)

[Josef Kufner]

Z pohledu zpracovávajícího programu je nejvýhodnější klasický unixový timestamp. Tj. počet sekund od nějakého data. Velice pohodlně se s tím počítá – je to v podstatě obyčejný long int.

[Miloslav Ponkrác]

Já osobně bych nasadil jinou databázi, už hlavně proto, že mysql je komerční program s omezenou licencí.

Co takhle sqlite, nebo firebird?

[Leoš Literák]

Mysql je FOSS aplikace sirena pod GPL. A komu GPL vadi, muze si koupit jinou licenci.

[Miloslav Ponkrác]

Jasně, že může. Ale nikde není zaručeno, že mysql třeba hned zítra se nepřestane vyvíjet pod GPL a bude se za ní muset platit třeba tisíce euro pro každého, kdo jí používá. Samozřejmě je také možné, že komunita bude pokračovat na stávajících GPL zdrojácích mysql, což je ale utopie.

Že nestraším bezdůvodně dokládá fakt, že ke změně licence mysql již několikrát došlo, naposled z LGPL na GPL, tedy firma mysql ab zostřuje. Mnohé softy musely získat výjimku, aby mohly dále mysql bez problémů používat, což je hlavně krok nutný pro firmu mysql ab, protože jinak by se mohlo stát, že třeba php, apache a podobné by našly náhradu za mysql a mohlo by to ohrozit samotnou firmu mysql ab. Stejně tak získaly výjimky některé další licence, ale pouze na klientskou část na mysql, pokud jsem to dobře pochopil.

Pro mě je jednodušší odstřelit ze svých projektů právně zbytečně omezující programy, zvláště pokud existuje spousta mnohem liberálnějších a často i lepších databází. Sám stavím na mysql jen tehdy, pokud si to někdo přeje, mám s mysql velmi značné zkušenosti, ale pro sebe jí již nepoužívám. Výsledkem je, že jsem také velmi mile překvapován tím, jak schopnější jsou jiné databáze oproti mysql.

[Jiří (BoodOk) Kadeřávek]

Zrovna u RDBMS, ktery je GPL a ke kteremu pristupujete pomoci vicemene standardniho dialektu SQL nejsou Vase obavy na miste. I kdyby k Vami popisovane situaci doslo, nikdo dalsi by GPL verzi nevyvijel a autor by zjistil, ze k dalsimu vyvoji aplikace nutne potrebuje nove funkce, pak neni zadny problem data odmigrovat. Pokud navic ma autor nejake zkusenosti s MySQL, pak IMHO neni duvod si nyni komplikovat zivot.

[happy barney]

lol, standadni dialekt
pani, nic proti, PostgreSQL je podla mna najlepsie riesenie (po vyradeni oracle z okruhu moznych kanditatov)

[Jiří (BoodOk) Kadeřávek]

V tomto typu projektu se od ANSI SQL nemusite temer hnout. Co se tyce rozdilu oproti ANSI, jsou dobre popsany, viz. http://dev.mysql.com/doc/refman/5.0/en/differences-from-ansi.html. A pokud si nejste jist, tak si mod SQL nastavte, at nemuzete pouzivat mysql specifika. Proti PostgresSQL nic nemam, ale uzivatel to na aplikaci nijak nepozna (mozna v rychlosti).

[happy barney]

mna rozosmialo to spojenie, nie to, co vyjadrovalo

[......]

Podle mě je MySQL i PostgreSQL na tento typ prográmku/skriptu trošku "kanón na vrabce" nebylo by lepší použít něco jednoduššího? Bude ukládat co pět minut pár bajtů dat, nebude provozovat bůhví co.

[happy barney]

informacia o 1000 klientoch, kazdu povedzme minutu jedna, to uz je slusna davka
nevraviac o slove sloboda (ak nepoznate, wikipedia pomoze ), tentokrat vo forme sloboda vyberu.

[......]

Nějak moc ti to mluví. Nevím kde by vzali 1000 klientů. To by to nesměl obsluhovat bash script. Jinak na 1000 klientů už nemusí vymýšlet co už dávno vymyšlené je. A co sem pleteš svobodu?? Malinko mi uniká co tím míníš. Pokud vím chtěl poradit něco vhodného a PostgreSQL to podle mě není. Jinak vyjadřuji svůj názor, takže laskavě respektuj zas ty moji svobodu slova

[happy barney]

no ja som zas navrhoval, aby sa netrapil vyberom to ci ono, ale definoval rozhranie a nech si to uz user pouzitym programom nakonfiguruje. Ja pouzijem postgresql, vy pouzijete neviem-co-ine, a autora to vlastne zaujimat nemusi. To je to, co som myslel pod "slobodou vyberu"

[Miloslav Ponkrác]

hahaham vy jste toho moc v databázích nenapsal, že. standardní dialekt sql chceche u mysql chceche a není problém data odmigrovat chceche

možná u super jednoduchého projektu máte pravdu, ale pak už je to jenom nemístný optimismus z Vaší strany

[Jiří (BoodOk) Kadeřávek]

Muzete se zamotat do stored procedures, triggeru a jobu, ale je to vase volba. Ja na druhou stranu nechapu, co by melo byt sloziteho na jednoduchem backendu na ukladani hodnot s casovou znackou a generovani zepar statistik, zejmena kdyz vy navrhujete sqlite :-o. Kdyz chci vyvrtat par der, tak si koupim vrtacku za par stovek, kdyz postavit dum budu spekulovat nad podporou, zarukami a koupim si ji od Hilti.

A kdyz uz copy pastujete posmesek, tak si alespon zkontrolujte, ze original neobsahuje chybu a hlavne, vynechte pls. osobni utoky.

[Miloslav Ponkrác]

složitého nic. jenom prostě vím jak dopadá projekt, který počítá s tím, že pak se prostě vymění db. mnohokrát jsem viděl pláč a skřípění zubů a finanční náklady veliké. ono je to na začátku jednoduché, ale nikdy nevíte kam ten projekt dojde a co nakonec všechno bude obsahovat.

[Hynek (Pichi) Vychodil]

Když jakýkoliv projekt změní výrazněji své specifikace, je potřeba zahájit vždy nový projekt. Změna z jednoduchého store pro jednoduché hodnoty na "nikdy nevíte kam ten projekt dojde a co nakonec všechno bude obsahovat". Je vždy důvod od toho utíkat jako by vám za patam hořelo a volat pomóóóc.

[Michal Kubeček]

Kdyby ta Hiltka stála stejně jako noname, rozhodl byste se také pro noname?

[Leoš Literák]

FUD. Nemuzou nutit platit uzivatele GPL verze. Mohlo by se to tykat jen te dalsi verze, ktera by uz pod GPL nebyla. Ale neni mozne vam odebrat soucasna prava. Urcite by vznikl fork, ktery by delal minimalne sustaining (security fixy apod).

[Miloslav Ponkrác]

Proboha, Vy snad neumíte číst, že?

Vždyť to píšu, že současná verze GPL zůstane, ale co s tím. Pokud se nebude usržovat, tak se klidně může stát, že za pár let je nepoužitelná. Nepůjde vůbec spustit na budoucí verzi Linuxu, například. A teze, že se jí ujme skupina a bude tuto MySQL verzi udržovat považuji předem za nemístnou utopii.

Další verze ovšem GPL být nemusí a nikdo Vám to nezaručí. Pokud manžerům mysql ab prdne v kouli a rozhodnou se to udělat, tak to udělají. Každý kdo používá mysql je napůl hříčkou několika manažerů jedné firmy, abych to trochu přehnal a zdůraznil jak to myslím.

[Michal Kubeček]

A teze, že se jí ujme skupina a bude tuto MySQL verzi udržovat považuji předem za nemístnou utopii.

Tak úplně nemístná utopie to není, třeba InterBase tohle štěstí měla. Ale také to nebylo úplně bez problémů a svou roli hrála i skutečnost, že se na tom podílela podstatná část klíčových vývojářů. V každém případě souhlasím, že to rozhodně nelze považovat za automatické a bezproblémové.

[Miloslav Ponkrác]

Jenže Interbase je podstatně kvalitnější produkt, než mysql. Dělat Firebird může být radost, protože je to kvalitní a velmi dobrá databáze, jejíž možnosti už před deseti lety vysoce převyšovaly možnosti nejnovější mysql 5.1.. Já osobně bych se projektu udržování mysql neúčastnil, protože si myslím, že dělat na mysql je zbytečné.

Taky podceňujete sílu Windows. Interbase byla databáze protlačovaná Borlandem se speciální super podporou v Delphi, takže udělat pěknou promakanou grafickou aplikaci nad Interbase byla doslova na chvilku. K tomu si připočtěte, že Borland neměl tak šílené licenční podmínky jako mysql a nenutil Vás platit šílené sumy peněž za to, že takovou aplikaci distribuujete.

Před deseti lety patřila Interbase k tomu nejlepšímu, co na Windows existovalo pro malé a střední aplikace.

Interbase měla opravdové zázemí lidí, kteří Interbase do detailu znali a opravdu jí využívali. Je potom logické, že takový projekt získal obrovský zájem. Ale kdo by stál o mysql? Spousta lidí znovu a znovu mysql opouští kvůli nesmyslným podmínkám a cenám. Stále potkávám lidi, kteří chtějí udělat projekt nad mysql, a chtějí ho prodávat a jsou vyvalení cenou, a diví se, že to propaguje open source komunita.

Já bych se klidně připojil k projektu Firebird, ale rozhodně ne k projektu mysql. Firebird používali především programátoři a mnohdy velmi dobří programátoři i databázisté. mysql používá 99,9%, kteří buď programovat neumí, a nebo select je vrchol jejich shcopností. Je nabíledni, pro který projekt sežene spíš pokračovatele.

[Jiří (BoodOk) Kadeřávek]

My vime, ze mate problem s GPL, tak uz toho nechte. MySQL je GPL, vy s ni mate problem a statisice dalsich ne. To je holt zivot.

[Miloslav Ponkrác]

Koukám, že Vy máte problémy se mnou. To je holt život.

[Jiří (BoodOk) Kadeřávek]

S Vami ne, s vasimi utoky na GPL a vse co s tim souvisi ano. Zkuste to umet rozlisit.

[Miloslav Ponkrác]

Máte problémy se mnou, ujasněte si to. O GPL píšu to co si myslím, sice tím možná znesvěcuji Vaši modlu, ale to je holt život, jak už jste se zmiňoval.

[Jiří (BoodOk) Kadeřávek]

Dejte si tam nick treba Carknop Valsolim a budu s Vami diskutovat stejne. Neznam Vas, GPL neni ma modla, ale licence, ktera dokazala zmenit zpusob fungovani v IT k lepsimu, proto si myslim, ze ji proste a priori odsuzujete nepravem.

[Miloslav Ponkrác]

GPL má své klady a zápory jako ostatně naprosto všechno na tomto světě. Kdybyste nechtěl vidět jednostranně, pochopil byste, že neodsuzuji GPL jako takovou, ale jen některé její rysy. A už vůbec jí neodsuzuji a priori jak píšete, ale své důvody vysvětluji a rozebírám. GPL licenci jsem nadšeně a nekriticky vítal do té doby, než jsem si jí pořádně přečetl a zamyslel se nad jejími důsledky.

GPL je licence, kterou jednoznačně pouze vítám třeba u kernelu, nebo ve zdrojových kódech gcc. Na druhé straně GPL není jenom jednoznačně přínos a jednoznačně změna k lepšímu. Abyste mě nenařknul z jednostrannosti, GPL má na svědomí spoustu dobrého a to této licenci neupírám.

Naproti tomu mnohé aspekty GPL se musely a nusejí řešit, především nesnášenlivost GPL s jinými licencemi, její virové chování, a musí se zavádět v mnoha projektech spousty výjimek z GPL, aby GPL šlo obhájit.

Také nemohu přehlédnout, že velmi mnoho projektů si GPL nevolí za svojí licenci, namátkou Apache, PHP, Mozilla a spol., sqlite, Firebird, atd..

Nemohu také nevidět, že mnozí vývojáři se takových projektů účastní mnohem ochotněji, není-li to GPL. Mnozí velmi kvalitní vývojáři si také uvědomují a mají dostatek morálního cítění, že pokud použijí pro své účely projekt X, že k němu přispějí a vrátí část své práce komunitě. Tak je to správné jak to cítím já. Ale pokud jim komunita nedá možnost jinou, než zveřejní všeho pod GPL, čeho se jen dotknou, najdou si jiný projekt, který je licenčně takto nesvazuje.

[Michal Kubeček]

Velmi nešťastné je zejména použití GPL u knihoven. Tam je její infekční chování vyloženě nepřátelské vůči vývojářům, kteří by chtěli používat jinou než Jedině Správnou Licenci. To je ale záměr, vždyť FSF sama vyzývá k používání GPL u těch knihoven, které nemají adekvátní non-GPL (ať už open source nebo closed source) alternativu. Z jejich pohledu je to správné - cílem je, aby veškerý software byl licencován pod GPL - ale o nějaké podpoře spolupráce při vývoji nemůže být řeč…

[Luk]

O tom, proč nemám rád u GPL knihoven, jsem kdysi psal. Nemám u nich ale žádný problém s LGPL. U programů mi GPL obecně nevadí, i když u některých bych přivítal spíše nějakou jinou licenci.

Paradoxně mi GPL nejvíc vadí u jádra, a to kvůli tomu, že to blokuje možnost používat některý hardware nebo to minimálně působí komplikace. Výrobce nechce poskytnout informace, ovšem ne-GPL nemůže poskytnout buď vůbec, nebou pouze "v rámci možností" (tj. způsobem, kdy nelze ovladač považovat za odvozené dílo), což přináší zbytečné reimplementace (a tím nafukování ovladače) a nemožnost používat mnohé zajímavé věci z jádra.

[Kyosuke]

Teď ještě dodělat tu dokumentaci, že jo?

[Jiří (BoodOk) Kadeřávek]

Jako treba, ze ve stored procedure/fci nesmi byt jako odsazovac pouzit tabulator. Za tuto neinformaci bych nekomu uhryzl hlavu. Ale komu, kdyz ji nikdo nepublikoval, ze Ostatne dokumentace u komercnich RDBMS na tom neni o nic lepe, spise hure, mam-li soudit napr. dle dokumentace k IBM DB2/AS400.

[Michal Kubeček]

Zkusil jsem to s 2.0 RC3 a nemá s tím problém. Ještě si zkusím někde nainstalovat 1.5.3 a podívat se, jestli to tam nebude zlobit. U jaké verze se to stalo vám?

[Michal Kubeček]

Takže 1.5.3 také proti tabulátoru neprotestuje. Jedině že bych ještě zkusil vyhrabat něco z řady 1.0.

[Jiří (BoodOk) Kadeřávek]

To bylo zrejme nedorozumeni, ja psal o problemu zapisu stored procedures v MySQL.

[Kyosuke]

Ano, to opravdu bylo nedorozumění, protože já samozřejmě psal o Firebirdu...

[Jiří (BoodOk) Kadeřávek]

Tak to bylo nedorozumeni na druhou, premyslel jsem, zda je dokumentace k MySQL opravdu tak chaba a ac se mi to nezdalo tak mne napadl ten zapeklity pripad se zapisem procedur a nedokumentovanym tabulatorem. I to se stava )

[Michal Kubeček]

Což o to, mne netřeba přesvědčovat, že Firebird je podstatně kvalitnější produkt než MySQL a že má vývojářsky přívětivější licenci. :-)

Na druhou stranu bych nebyl tak skeptický k životaschopnosti GPL-forku MySQL. Přeci jen je dost firem, které mají nad MySQL postavené své projekty (i když ten software je obvykle pouze pro vlastní potřebu a nikam se nešíří). Tyto firmy by asi byly ochotny udržení GPL-forku při životě podporovat. Souhlasím ale s názorem, že otázka dalšího vývoje by v takovém případě byla více než sporná.

[happy barney]

a co tak:
"| igw-disk-writer"
"| igw-mysql-writer"
"| igw-pgsql-writer"
"| igw-sqlite-writer"
"| igw-firebird-writer"
(samozrejme, so specifickymi parametrami) ?

a nebude vobec zalezat na tom, kto a kde si to chce ulozit, jedine, co bude musiet autor specifikovat, je vstup, ktory dostanu tie programceky.

[Milan Horák]

+1

[happy barney]

vstup by teoreticky mohol byt:

<source>:<timestamp>:<name>:<value>\n

kde:
- <source> je identifikacia zdroja
- <timestamp> by mohol byt klasicky unix timestamp
- <name> data-in, data-out, ...
- <value> namerana hodnota

tym padom vzniknu tabulky:

source
  id int (autoincrement/serial/ ...)
  name text

name
  id int
  name text

log
  id int
  source int references source on delete cascade,
  timestamp int
  name int references source on delete cascade,
  value int8/double

[Kyosuke]

Pořád jsem nepochopil, jak to s MySQL je. Tak je pod GPL, nebo není?

[Leoš Literák]

samozrejme ze pod GPL je, zmineny komentar je FUD

[Miloslav Ponkrác]

komentář FUD není, dnes je pod GPL, zítra být nemusí, protože to nikdo nezaručí, to je celé. takže ano, dnes je mysql pod GPL

[pol128]

To, čo je pod GPL dnes už nikdy inak nebude.

[Miloslav Ponkrác]

Oprava: Dnešní GPL verze bude GPL, budoucí verze nemusí.

[Jiří (BoodOk) Kadeřávek]

Dnesni verze MySQL, ktera je pod GPL, bude pod GPL vzdy a vzdy bude otevrena k dalsimu vyvoji. O nejakych hypotetickych budoucich verzich se bavit nemusime, protoze u _JAKEKOLIV_ licence ma autor SW pravo k jeji zmene. Zkuste si to vyslovit nahlas. Neexistuje licence, ktera by Vam zarucovala, ze pro vas autor SW bude vzdy v budoucnu bezplatne GPListicky pracovat. A je to dobre a je to prirozene.

[Miloslav Ponkrác]

Dnešní verze bude GPL, akorát, že dnešní verze může být za pár let k ničemu.

Změna licence je u mysql mnohem pravděpodobnější, než u jakýchkoli jiných GPL projektů, neboť v minulosti již mysql licenci změnilo na restriktivnější.

Existují projekty, kde máte některé věci zaručeny na věky věků. Například pochybuji o tom, zda změna kernelu Linuxu na něco jiného, než GPL je reálně možná. Právě u kernelu Linuxu mám naprosto zaručeno, že bude vždy v budoucnu bezplatně GPListicky pracovat. Takže to zase tak přirozené jak se mi tu snažíte natlačit není.

[Jiří (BoodOk) Kadeřávek]

Tak to nemate pravdu, protoze stejne jako se vyviji MySQL, tak se vyviji kernel. Je spoustu klicovych vyvojaru subsytemu, kteri se rozhodnou, ze pokud jejich budouci prace nebude GPL , pak nebude GPL. A mezitim muze subsystem zoufale zastaravat, tak jako se s mnoha stalo. A to az do okamziku, nez se najde nekdo jiny kdo a) zacne kod opet udrzovat b) napise kod znovu. Ted si to co jsem napsal zamente za MySQL a dojdete sice k rozdilum, ale nikoliv zasadne principialnim. Ochota udrzovat MySQL u zivota bude zcela umerna tomu, nakolik bude komunita a jeji clenova citit, ze je to potreba. S ohledem na miru nasazeni teto databaze bych v tom zas az takovy problem nevidel. Ze existuji lepsi produkty, komfortnejsi, ano mate pravdu, jenze oni existovali vzdy (resp. dlouho do historie) a MySQL stejne ziskavala. Proc? Prave diky sve jednoduchosti a nenarocnosti, a to presne na aplikace typu NetCount, kde neresim ref. integritu, trigery aj. ale potrebuji jednoduchy a transparentni serverovy backend s relativne omezenou funkcnosti, rozumejici SQL a dostatecne rychly i na zastaralem zeleze s omezenym vykonem a pameti.

[Miloslav Ponkrác]

Řekněte mi, jak je pravděpodobné, že naprosto všichni autoři určitého subsystému se prostě rozhodnou, že jejich budoucí práce nebude GPL.

Ochota udržovat něco není zcela úměrná tomu, nakolik komunita bude cítit, že je to potřeba. Pokud bude komunita cítit, že je to potřeba a nenajde se nikdo, kdo by se toho ujal, může komunita cítit co chce.

Navíc mysql používá mnoho začátečníků, na rozdíl od jiných databází. Já si reálně nedokážu představit někoho, kdo je dostatečně machr, tj. dobrý databázista i programátor, který by chtěl mysql udržovat. Každý z nich raději bude participovat na projektu kvalitnější dbms, než je mysql.

proč mysql získává? no hlavně proto, že má jméno a jsou na ní lidi zvyklí. nic jiného v tom nehledejte. nechápu, jaký je problém použít třeba firebird stejně jednoduše, prostě nebudu používat integritu a další věci a bude to úplně stejně primitivní jako v mysql. ze stejného důvodu se na windows používal access, a dnes mssql. v podstatě skoro každá databáze se dá primitivně použít stejně dobře a jednoduše jako mysql.

ano, věřím, že by se mysql začala vyvíjet komunitou, dokonce, že by nějaký čas i fungovalo, ale předpovídám tomu, že po počátečním nadšení by to zašlo na úbytě. podle mě odborníci by nechtěli plýtvat své síly na podprůměrnou mysql a začátečníci to dlouho neudrží.

[Jiří (BoodOk) Kadeřávek]

Je to malo pravdepodobne, stejne jako hypoteticky pripad jednoduche aplikace postavene nad osirelou MySQL, ktera potrebuje nove ficury a autor je neschopen portace na jiny RDBMS i za pravdepodobneho predpokladu, ze v takovem nepravdepodobnem pripade budou existovat portovaci nastroje pro prechod ze siroty MySQL treba na Firebird.

[Miloslav Ponkrác]

Ano, ano, podobné řeči jsem za svůj programátorsko analytický život slyšel už tolikrát a věřte nevěřte, tak často vedly ke krachu projektů i firem.

[Jiří (BoodOk) Kadeřávek]

Spatny projekt a neschopnou firmu nezachrani nic.

[k3]

Do mysql bych to byt tebou necpal.. mel jsem neco obdobneho (id, in, out, timestamp) a po case se to hrozne zpomalovalo. Pomohla optimalizace dotazu + nastaveni indexu trochu lip, ale i tak to bylo strasne pomale. Takze bych to byt tebou cpal do RRD. Prece jen je to rychlejsi, daj se z toho snadno kreslit grafiky a kdyz budes nekdy potrebovat ty data ciselne tak se daji taky vytahnout..

[Miloslav Ponkrác]

u mysql existuje speciální typ úložiště zvaný archive, který spoustu věcí řeší. ale do mysql bych to necpal také, viz licence a můj příspěvek výše.

[DjAARA]

Sam tvorim IP accounting - je postaveny nad StarOS routerem. StarOS jsem nevolil ja, ale sef. Vyhovuje mi, ze kdyz se na siti objevi nova IP adresa, tak bez jakehokoliv meho priceneni zacne dodavat informace o tom kolik prenesla.

Zacinal jsem s ipacct, s kterym mam ted momentalne spolecne akorat stejny nazev skriptu, ktery sbira data z routeru a uklada je do databaze.

Mam 3 tabulky. 2 tabulky jsou velice podobne. Jedna z nich je na 5ti minutove soucty uzivatelu a druha potom na soucty hodinove spocitane z techto 5timinutovych. Tabulka vypada:

ip (inet) | data (bigint) | packets (bigint) | direction (BOOL/NUMERIC(1)) | timestamp (NUMERIC(11))

direction urcuje jestli jsou ty data prichozi ci odchozi. Nad tabulkou s hodinovymi soucty mam udelany pohled, ktery mi spoji prichozi a odchozi data k dane IP v danem case do jednoho radku. Nad timto pohledem mam pak vystavene generovani statistik.

Z nasbiranych 5ti minutovych souctu nacpu data do rrd databaze a z te pak pri pozadavku na informace o dane IP nageneruji graf.

typ numeric na timestamp asi nebude uplne idelani a nejspis snizuje vykon... No snad se dostanu k tomu to zmenit na neco rozumnejsiho.

DjAARA

[DjAARA]

Jo a treti tabulka je:

ip (inet) | name (varchar(30))

[k3]

ipcka bych do tabulky s prenesenyma datama necpal.. duvod je pomerne jednoduchy a ten, ze ip daneho stroje/interface na nem se me muze zmenit a kdybych chtel mit historii pro nej stale dostupnout atk bych musel updatovat vsechny zaznamy v te tabulce kde se vyskytuje.

[DjAARA]

No ono by slo vkladat tam ID uzivatele, kazdy uzivatel by mel prideleno nekolik IP adres svazanych s timto ID, ale myslim, ze by se krapet zkomplikovalo (bylo by casove narocnejsi - mam ip, musim ziskat ID uzivatele) vkladani do databaze.

A Staros dodava data tak, ze doda zdrojova IP, cilova IP, takze pro jednu IP bych zjistoval treba 1000x, kdyby behem 5ti minut komunikoval s 1000 IP.

[Miloslav Ponkrác]

Já bych si s tím problémy nedělal. Všechno byste mohl zvládnout jedním jediným SQL dotazem včetně uložení dat a databáze by to udělala za Vás, když budete mít dobře navržené SQL tabulky. A 1000 dotazů za 5 minut mě přijde jako slušně zvládnutelné bez nějakých větších křečí.

[DjAARA]

Jako jo, slo by to. Ale v HanaFreeNET to zatim staci tak jak to je. I kdyz zacinam nad tim vazne uvazovat.

Oproti tomu z ceho jsem vychazel jsem redukoval mnozstvi sql dotazu na dobrou polovinu. (eliminace select count(*) a podle toho bud update nebo insert na update a pokud ten neprojde, tak provedu insert).

[k3]

spis id toho interface. Uzivateli to pak muzu zgrupovat, ale chtel bych mit data per if (tak jako kdyz jsem to mel per ip).

Dalsi veci je, ze upravit ty data by me mel stejne nejaky "preprocesor", ktery klidne kdyz zjisti, ze jde o verejne ip tak to secte dohromady atp.. dle pozadavku a kdyz to nebude blbe vymysleny/napsany tak to bude pomerne rychle.

1000 dotazu/5min ta db musi zvladat naprosto bez problemu (kdyz to nejsou uchylny dotazy co to cely zamknou a jeste nad neoptimalni tabulkou etc..) a taky to nebezi na nejakem prehistorickem stroji vhodnem spis uz do muzea.

[DjAARA]

Zpusob groupovani/ukladani do databaze si kazdy predstavuje trochu jinak. Ale i to co pisete ma neco do sebe. Nicmene rozhrani z ktereho to jde z logu StarOSu nejspis nepoznam. A paterni router, ktery to pak posila na 2 ruzne linky do internetu je hlidany (monitorovany) samostatne.

Ja osobne potrebuji vedet ktera IP je v ramci HFN nejaktivnejsi a na pripadne zlobily pustit shaping.

No to je 1000dotazu/5 min na _jednu_ IP z vnitrni site, kdyz budete mit v siti 1000 IP (dobre my mame kolem 55 lidi on-line za den, ve spickach kolem 80-90 IP, celkem vedeme 237 IP), tak uz jsme na milionu dotazu za 5 min. Ne ze by to bylo nejak extremne mnoho.

[DjAARA]

... prumerne kolem 55 IP za den ...

[happy barney]

kde nestaci rychlost, treba pouzit pamat

postgresql:

create function get_user_id (cidr) returns int immutable language 'sql'
'select id from user_ip where ip = $1';

insert into log (time, uid, value) values ($1, get_user_id($2), $3)

50 userov/200 ip, 3000 insertov/s na prvy milion

[k3]

Zpusob groupovani/ukladani do databaze si kazdy predstavuje trochu jinak.

Ano, zalezi na pozadavcich co z toho budu potrebovat, k cemu to ma slouzit atp..

Ale i to co pisete ma neco do sebe. Nicmene rozhrani z ktereho to jde z logu StarOSu nejspis nepoznam.

Logy StarOSu neznam. Kazdopadne kdyz jsem se o nej zajimal meli tam hezky backdoor, ktery snad uz odstranili nebo premistili jinam :)

Jako interface jsem spis myslel logicky interface, ktery mam popsany ip adresou + mac adresou (v pripade, ze ji k necemu budu chtit pouzit).

A paterni router, ktery to pak posila na 2 ruzne linky do internetu je hlidany (monitorovany) samostatne.

Pod monitoringem serveru/routeru si predstavuju spis trochu jine veci nez hlidani prutoku dat od jednotlivych uzivatelu.

Ja osobne potrebuji vedet ktera IP je v ramci HFN nejaktivnejsi a na pripadne zlobily pustit shaping.

Melo by stacit znat ip daneho klienta a data in/out (pripadne pocty paketu). Bylo by mozne to jeste rozdelit na traffic uvnitr site, ven a podle nejakych pravidel vypocitat zda uz prekrocil hranici na to aby se jemu zapnul shapping.

Pokud chci vedet s kym komunikoval tak uz holt potrebuju o cilovou ip navic cimz neumerne narusta pocet zaznamu.

No to je 1000dotazu/5 min na _jednu_ IP z vnitrni site, kdyz budete mit v siti 1000 IP (dobre my mame kolem 55 lidi on-line za den, ve spickach kolem 80-90 IP, celkem vedeme 237 IP), tak uz jsme na milionu dotazu za 5 min. Ne ze by to bylo nejak extremne mnoho.

No neni potreba delat takove mnozstvi dotazu na kazdou ip. Jelikoz uz vlastnim log tak si jej preparsuju do svych struktur jak potrebuji, vyberu si z nej vsechny ip a aplikovat filtr, ktery me rika zda je to interni ip, externi[venkovni internetove] (muze pracovat v podstate na znalosti podsiti, ktere jsou uvnitr pouzivany), necht se stanou unikatnimi, provedu jeden dotaz do db, kterym vyberu idcka jim odpovidajci, nahradim ipcka u sebe jejich idckama, jednim/nekolika dotazy to ulozim. (pomerne rychle reseni, melo by to jit resit i na urovni sql dotazu[s trochu jinym prubehem], ale sql zas na tolik neumim :))

takze ve vysledku mam 1 select + 1 nebo nekolik insertu (je rychlejsi ukladat vice hodnot najednou)

[Jiří Němec]

Divné, když jsem dělal redakční systém, tak mi tu všichni doporučovali ať s tím skončím, že tu každý webdesigner dělá svůj vlastní radakční systém. Dnes zas asi každý dělá tenhle měřící systém.

Před rokem jsem tohle dělal pro jednoho málého poskytovatele připojení k internetu (30 zákazníků). Samotné měření byla nejméně důležitá část, bylo to hlavně webové rozhraní na nastavení shapování pomocí htb. Neměl jsem na to ani týden, takže to mělo k dokonalosti daleko.

Teď to předělávám, každý zákazník bude moc mít víc počítačů, bude tam víc serverů/gatewayí. Chcu letos zapracovat na statistikách a mám plány na vylepšení shapování.

Přepisuju to do mysql, protože ten kdo to po mě letos chce ji používá. Měření mi už funguje, sbírá mi to program v c++, takže to jede rychle i na starších komplech.

Zatím přemýšlím jak efektivně seskupit záznamy za hodinu. Zatím to ukládá po 5 minutách a přijde mi to trochu moc jemné, chtělo by to třeba den staré záznamy nějak sečíst a uložit do posledního záznamu vždy po hodině. Zatím to ale není to nejdůležitější, zatím mi jede databáze rychle.

Jo sqlite jsem používal loni a byla to katastrofa, věčně se mi nějak zamykala databáze. Dost jsem přemýšlel nad použitím jiné databáze, nakonec jsem ale radši použil to, s čím mám nejvíce zkušeností - mysql.

Mohl byste mě kdyžtak kontaktovat na jabberu: blupix@njs.netlab.cz? Dám vám kdyžtak kontakt na dalšího, kdo tvoří to samé. Oba to pak plánujeme vydat pod nějakou svobodnou licencí, nebojte se že by se ta práce ztratila.

Jo ukádám to do tabulky:

CREATE TABLE `prenosy` (
  `ip` int(11) unsigned NOT NULL default '0',
  `upload` bigint(20) unsigned default '0',
  `download` bigint(20) unsigned default '0',
  `cas` bigint(20) unsigned NOT NULL default '0',
  `sonda` tinyint(4) unsigned NOT NULL default '0',
  KEY `ip` (`ip`),
  KEY `sonda` (`sonda`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Přičemž ip adresy ukládám ve formátu, který tvoří ip2long().

[Miloslav Ponkrác]

sqlite verze 3 podstatně vylepšila paralelismus a umožňuje paralelní práci procesů, které dřív brutálně zamykaly. už od verze 2.8 se tyto věci vylepšovaly, zatímco verze 3 už to dovedla mnohem dále.

osobně bych nepoužil mysql, ale třeba firebird, kde různé akce tam lze automatizovat. ono procedury, triggery a další věci nejsou vůbec špatná věc. nehledě na to, že propustnost firebird při paralelní práci by měla být vyšší, než mysql díky multigenerační architektuře.

[k3]

Divné, když jsem dělal redakční systém, tak mi tu všichni doporučovali ať s tím skončím, že tu každý webdesigner dělá svůj vlastní radakční systém. Dnes zas asi každý dělá tenhle měřící systém.

Sice je to pravda, ze si to dnes pise skoro kazdy jelikoz nic pouzitelneho a nolne dostupneho neexistuje, ale jak taky ty projekty dopadaji... Vetsinou dalsi kus toho sameho nepouzitelneho software..

[Michal Kubeček]

Přičemž ip adresy ukládám ve formátu, který tvoří ip2long().

Jinak řečeno je konvertujete zpět do jejich skutečné podoby… :-)

[Zdeněk Štěpánek]

Zdravim

Diky za reakce.

Puvodne jsem databazi ani pouzit nechtel. Hlavne proto, ze by to byla dalsi podstatna zavislost. Proto jsem zvolil ukladani do souboru, jenze to se ukazalo jako velmi spatny napad. Ted mam nejakych 17000 souboru v adresaru a rostou rychlosti 60 denne (pocet klientu).

Data potrebuju zobrazovat predevsim ciselne a graf bude jako doplnek. Ale stejne by me zajimalo jakym zpusobem lze z RRD souboru zpetne vytahnout ciselna data a nejlepe nad nimy delat jednoduse vypocty jako by to slo v databazi.

Databaze zaroven za me elegantne vyresi sitovy prenos dat.

MySQL jsem zvolil proto ze ji proste mam na serveru (a ma ji tam skoro kazdy kdo ma nejakou databazi) a s jinou jsem se nesetkal. Navic tam nepredpokladam zadne obskurnosti, takze napasovat to na jinou SQL databazi bude zrejme trivialni. Asi jen search/replace prikazu "mysql" a vytvoreni vhodneho uzivatele s povolenym sitovim pristupem. A propo, MySQL je svobodny soft pod dualni (GPL+komercni) licenci.

Ani nahodou netrvam na tom, ze musim znovu vynalezt kolo. Uplne vklidu bych se s nekym spojil a dame to dokupy spolecne.

Takze neco malo tech: Ja to delam v bashi a mereni jsem si vypujcil z ipaccountingu (... od standuse a bohdyho), to je pomoci iptables. Nejaky inteligentnejsi skriptovaci jazyk bohuzel neumim na realne pouzitelne urovni, tak to bastlim v bashi... A C uz vubec ne...

Ostatne staci si stahnout netcount ve starsi verzi http://netcount.gavanet.org/. Dokumentace a navod jsou uvnitr.

Zdenek

[DjAARA]

Ja bych mohl poskytnout to co jsem spal pro StarOS. Mam i instalace kde to bezi na beznem linuxu. Jen pridavani novych lidi neni automaticke jako u StarOSu.

Funguje mi to tak, ze stroj na kterem bezi databaze a vlastni webove rozhrani k tomu je soucasne i sberac dat.

Na zdroji - pocitaci z ktereho se berou statistiky bezi bud apache ktery spousti skript (tak jsem to mel) ci se ten skript spousti pres xinetd (tak bych to udelal ted). V podstate to udela to, ze vezme vystup iptables a pretransformuje do formatu v kterem dodava StarOS.

Sberac si to rozparsuje a ulozi do databaze.

Momentalne je tam podporovana mysql a postgresql, pricemz od mysql utikam a postgresql pridavam nove vlastnosti .

[Jiří Němec]

Postgresql má lepší výkon? Ukládání přenosů řeším spožděným insertem, takže ukládání je vlastně 1 sql dotaz za 5 minut. Náročné je spíš to generování statistik a to je vše čtení. MySQL by v tom snad mělo podávat lepší výkony.

Jinak to máme dost podobné, jen já ten sběr dat kvůli výkonu přepsal do C++.

[happy barney]

postgresql ma vyssie limity (na rovnakom hw znesie vacsie databazy, vacsie indexy, viac uzivatelov). Su veci (napr nadviazanie konexie), ktore ma oproti mysql vyrazne pomalsie, ale napr take sekvencie su oproti autoincrementu ako ferrari oproti trabantu. Dalo by sa vela diskutovat, no mnoho minulych argumentov nove verzie jednoho i druheho vyvratili. Ale jedno mozem povedat, doteraz mi postgresql "padol" len dva krat, a aj to bolo kvoli zle nastavenemu oom killer-u

[Kyosuke]

Ufff, do C++? Proboha, proč? Byl to sběr údajů z tisíciportového switche?

[Jiří Němec]

To jen ipaccounting sedoval a awkáčkoval informace o 30 uživatelích na 200MHz stroji klidně i 20 sekund. I s nastavenou nejnižší prioritou to brzdilo provoz který tou bránou procházel. Po přepsání do C to byla záležitost desetin vteřin a většinou času zabralo sqlite.

[DjAARA]

Netvrdim, ze PostgreSQL ma lepsi vykon. Jen se mi s nim mnohem lepe pracuje.

[Michal Kubeček]

Porovnání výkonu je komplikovaná věc. Především záleží na tom, co s čím budete porovnávat a v jakém kontextu. O MySQL se traduje, že je v porovnání s ostatními databázemi velmi rychlá, ale to se týká především MyISAM tabulek a aplikací, kde se data prakticky jen čtou, zápisů je málo a konkurence prakticky žádná. Chcete-li konsistenci dat, nezbyde než použít InnoDB, a tam už MySQL tolik nevyčnívá. Firebird i PostgreSQL zase díky MGA dosahují podstatně lepší škálovatelnosti při větším počtu paralelně přistupujících klientů.

[k3]

rrdtool fetch jest to co hledas :)

Jinak mohl bych ti kecat do toho jak by to melo byt navrzene, ale psat to nebudu.. nemam na to cas :) mam nejake sve experimentalni veci, kterym se venuju.

Kazdopadne to bastlit v bashi neni zrovna nejlepsi reseni... to uz bych spis prezil perl :)

[Bubak]

Celkem v pohode, asi bych to resil take tak. Vylepsit by se to dalo tim, ze treba po mesici (nebo tydnu, nebo oboji?) se udelaji soucty za dany interval (asi do jine tabulky?). Pokud bude nekdo chtit zobrazit urcity interval, usetri se tim prace databazi - secist data od zvoleneho pocatku do nejblizsiho predpocitaneho, potom secist predpocitana data na nejvyssi urovni do nejblizsiho nepredpocitaneho (pokud bude vic urovni, tak po jednotlivych urovnich) a pak pricist zbyvajici data do konce pozadovaneho intervalu. Ale jestli se to vyplati, to zalezi na predpokladane zatezi serveru (poctu pozadavku na zobrazeni) a vyberu rozmezi a vubec.

Co se tyka db, ja bych spise sahnul po postgresql, spousta veci se tam da resit elegantne primo v databazi ... Ale mysql znam z rychliku a nove veci uz vubec ne, takze to neber tak vazne.

[zde]

Proč to vůbec strkat do databáze??? RRDtool za vás udělá vše co potřebujete, rrdfetch umí i agregovat. Jeden RRD soubor pro každou IP adresu, a není co řešit.

[happy barney]

no mozno preto, ze niekomu je vyhodnejsie mat to v db. Neexistuje jedine spravne riesenie.

[......]

Vyloženě nevnucuješ svoje řešení

[Michal Kubeček]

Když už je tu o tom řeč, zkoušel jste někdo, jaký je rozdíl mezi čtením dat přímo od jádra (pomocí knihovny libiptc) a parsováním výstupu příkazu iptables? Je jasné, že první varianta bude rychlejší, ale zajímalo by mne, jestli to stojí za to.