Diskuze: Potrebujem poradit pri hladani stringu
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 19 zpráv z 19.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
je docela dobrá praktika ho po nějaké době vzít, přejmenovat třeba na
log_x a pokračovat v zapisování do čistého logu, pak se bude hledat lépe
No ale tak mal by som potom zbytocne vela suborov narobenych a malych a podla mna je to zbytocne
Podle mě je zbytečné mít 200mb texťák. :-/
Stejně to jinak než přes pole nepřečteš od konce... a do statiky bych se
moc nepouštěl.
A co je podla teba priatelskejsie ako 200 MB textovy subor ? potrebujem aby sa tie data zapisovali do nejakeho textoveho suboru aby si to vedel stale hoci kto otovorit a precitat
Proč to vlastně nedáváš do databáze? To by bylo mnohem elegantnější.
No tak to mas pravdu ale zas by tam bolo velmi velke mnoztvo dat a ja potrebujem rychlejsi sposob zapisu a to je to textoveho suboru lepsie... ked ja ten textovi subor skomprimujem do .rar tak 200MB sa zmensi iba na 4MB a to by sa uz do operacnej pamate dalo nacitat... alebo pouzit iny format suboru pre zapis dat
Zápis do databáze má obvykle mnohem vyšší režii právě proto, aby čtení bylo rychlejší. Logy se zapisují často, ale čtou jen občas. Proto je výhodnější optimalizovat zápis, tedy logovat do textového souboru.
Pokud ty logy chceš nějak zpracovávat, tak bych použil databázi.
200 MB už mi nepřijde jako moc optimální velikost pro "aby si to vedel stale hoci kto otovorit a precitat".
200MB na log je docela hodně, typicky má log soubor pár KB, max pár
MB.
Co tam loguješ? Potřebuješ všechno co loguješ opravdu logovat? A pokud DB
opravdu nevyhovuje, tak bych taky preferoval ty logy nějak logicky rozdělovat
do více souborů.
Vždyzky záleží na tom, jak často do toho logu leze. Pokud několikrát za minutu, tak by textový soubor skutečně nebyl ideální, ale čtení 200 MB souboru trvá na mém Atomu 0,3 s, což není taková hrůza.
Máš disk s rychlostí čtení 666,666... MB/s? Pěkné
Mě šlo spíš o to zpracování dat, když je to v DB, tak zavolám jeden select, tady si to bude muset parsovat...
EDIT: Co to máš za disk? Mé SSD čte max 450 cca MB/s
prosím tě co to máš za SSD? Taky bych si ho koupil, jestliže reálná přenosová rychlost je opravdu tak vysoká
To bylo z diskové cache, ten soubor měl jen 1 GB a četl ho 1,3 s.
Co máš za disk, že máš diskovou cache velkou 1GB? Můj 2TB Seagate
plotňák má diskovou cache jen 64MB
Disková cache v RAM. Mám 2 GB a systém 1 GB využil jako mezipaměť s diskem, protože ji v tu chvíli nepotřeboval.
Ale tam ten soubor běžně nemáš, pokud ho nepoužíváš nějak často
No jo, napoprvé to z disku četlo jen 100 MB/s, ale snad jsme se bavili o častém prohledávání, ne?
aby som to vysvetlil... Linux v skutocnosti vyuziva iba cast pamate RAM,
zvysok vyuzitelnej RAM tvori CACHE disku, kam si nacitava otvarane subory, ale
akonahle potrebuje viac pamate tak si pozicia potrebne mnozstvo z CACHE disku v
RAM
to vsetko prebieha v ramci kernelu transparentne, uzivatel, si nicoho
nevsimne
Zobrazeno 19 zpráv z 19.