abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 0
včera 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
včera 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 3
7.12. 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
7.12. 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 2
7.12. 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 6
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 27
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 798 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci

23.3.2012 01:49 u-rob-o-ros
Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Přečteno: 567×
Ahoj. Potřebuju vyhledávat v obrovské tabulce záznamy, které obsahují třeba na 3. pozici ve sloupci písmeno x, tj.
sl1 sl2
1   --xDas
2   a-xas
3   --x--
Udělat to pomocí LIKE trvá strašně dlouho, proto bych rád věděl, zda to jde udělat indexovaně? Je mi víceméně jedno jestli se bude hledat třeba podle sloupce typu VARCHAR či např. podle INTu, kde by se hledalo binární operací AND, ale potřebuju na to vytvořit a používat indexy. Jak na to?

Odpovědi

okbob avatar 23.3.2012 05:39 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
v 9.1 lze pouzit trigramy a indexovat i like, kde je zolik vlevo.

Jinak asi by bylo mozne navrhnout i neco efektivnejsiho, ale vyzadovalo by to vlastni typ indexu - a vicemene psani v C. Pak by to asi mohlo byt opravdu efektivni

Pripadne si pro kazdou pozici muzete udelat index - ale nejde to tak jak si predstavujete.
CREATE TABLE foo(s text);
CREATE INDEX ON foo USING GIN ((substring(s FROM 1 FOR 1));
CREATE INDEX ON foo USING GIN ((substring(s FROM 2 FOR 1));
CREATE INDEX ON foo USING GIN ((substring(s FROM 3 FOR 1));

SELECT * FROM foo WHERE substring(s FROM 3 FOR 1) = 'x';
tahle podminka bude mit dost mizernou selectivitu - dost mozna ze problem je jenom v like a stacilo by nepouzivat like
SELECT * FROM foo WHERE substring(s FROM 3 FOR 1) = 'x';
Jeste by slo pouzit hstore:
postgres=# create or replace function pack(text)
returns hstore as $$
SELECT string_agg(i || '=>' || substring($1 FROM i FOR 1),',')::hstore 
FROM generate_series(1,length($1)) g(i); $$ 
LANGUAGE sql IMMUTABLE;
CREATE FUNCTION
postgres=# select pack('Pavel');
                       pack                       
--------------------------------------------------
 "1"=>"P", "2"=>"a", "3"=>"v", "4"=>"e", "5"=>"l"
(1 row)

postgres=# select * from xx;
   a   
-------
 Pavel
(1 row)

postgres=# CREATE INDEX ON xx USING GIN((pack(a)));
CREATE INDEX

postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v';
   a   
-------
 Pavel
(1 row)

postgres=# set enable_seqscan to off;
SET
postgres=# explain SELECT * FROM xx WHERE pack(a) @> '3=>v';
                                QUERY PLAN                                 
---------------------------------------------------------------------------
 Bitmap Heap Scan on xx  (cost=12.25..16.51 rows=1 width=32)
   Recheck Cond: (pack(a) @> '"3"=>"v"'::hstore)
   ->  Bitmap Index Scan on xx_pack_idx  (cost=0.00..12.25 rows=1 width=0)
         Index Cond: (pack(a) @> '"3"=>"v"'::hstore)
(4 rows)

postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v, 4=>e';
   a   
-------
 Pavel
(1 row)

postgres=# SELECT * FROM xx WHERE pack(a) @> '3=>v, 4=>x';
 a 
---
(0 rows)
Ale co bude rychlejsi netusim - hstore je hodne genericky, takze pokud by tam byla nizka selectivita, tak by to nemuselo byt efektivni
23.3.2012 09:19 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
To vypadá, že v tom textu jsou zakódovaná nějaká data. Databázově nejčistší by bylo ta data rozkódovat a uložit samostatně – třeba i pravidlem při insertu a updatu. Pak už si můžete udělat indexy na ta rozdělená data.
23.3.2012 09:36 camel1cz | skóre: 23
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci

Souhlas... a nebo jít cestou oindexování volání funkce - viz CREATE INDEX, je tam příklad na vytvoření indexu nad lower()

23.3.2012 10:21 u-rob-o-ros
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Víceméně se snažím vyhnout použití 2 tabulek a časově náročnému spojování po každém dotazu nebo částečné redundanci. Abych upřesnil co to má dělat: mám N měřících stanic, jejichž počet se občas mění. Každá stanice ukládá do tabulky každou vteřinu měření. Měření jsou často naprosto identická a proto se snažím uspořit data tím, že místo 10 skoro identických řádků uložím jeden, který bude mít speciální rozlišovací sloupec určující jednotlivé stanice. Ten sloupec by byl třeba znakový "xxx-xxx-" (data jsou stejná pro 1. 2. 3. 5. 6. a 7. stanici) nebo celočíselný používající k rozlišení boolovskou algrebru (1 or 2 or 4 or 16 or 32 or 64). Tímto ukládáním se totiž rapidně sníží množství ukládaných dat.
23.3.2012 10:36 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
K tomu by se lépe hodil bitový řetězec, ale nevím, jak jej PostgreSQL umí indexovat. Spíš bych ale použil normální spojení dvou tabulek. Nevím, co je to za mýtus o časově náročném spojování – to spojení žádnou zátěž nepřidá, podstatné je to hledání podle indexu. A tomu se stejně nevyhnete, naopak při použití 2 tabulek můžete použít standardní indexy a operace, na které je ta databáze už desítky let optimalizována.
23.3.2012 11:19 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Tak spojeni velkych tabulek muze byt vypocetne velice narocne, to neni zadny mytus, zalezi na konkretni situaci. K optimalizacim je treba pristupovat vzdy s ohledem na ocekavane scenare. Jestlize napriklad tech stanic je 10 a ocekava se, ze dotaz tedy vybere zhruba desetinu zaznamu z tabulky, tak je prinos pristupu pres index sam o sobe diskutabilni a vetsina databazi rychleji provede full scan. Like bude typicky mnohem pomalejsi nez substr nebo bitova operace nad ciselnym priznakem, coz muze byt u velkych objemu take hodne videt. Neznam samozrejme konkretni scenar, ale obecne databaze byvaji dobre v praci s velkym poctem radku (a maji na to prostredky - partitiong, komprese...) a slabsi v nejake vnejsi logice (jako zde ten priznakovy retezec). Pomerne caste je ukladani aktualnich dat v neoptimalizovane "pruzne" strukture (napr. okamzite lze pridat dalsi stanici) a konsolidace starsich dat vice nebo mene "natvrdo" podle ruznych kriterii (uspora mista, rychlost konkretnich dotazu, moznost drilovani v EUL atd.)
23.3.2012 12:01 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Tak spojeni velkych tabulek muze byt vypocetne velice narocne, to neni zadny mytus, zalezi na konkretni situaci.
Je to mýtus. Spojení velkých tabulek nic nestojí. Nákladné je vyhledávání. Zkuste si to. Udělejte si SELECT na spojení tabulek, a pak soustavu SELECTů, která vybere ta samá data bez spojení v databázi (spojení uděláte v aplikaci). To druhé bude pomalejší – hledání použije stejné indexy, ale v druhém případě bude víc režie se spojením, parsováním dotazů apod.
23.3.2012 14:43 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Databaze zvoli pro vyhodnoceni dotazu nejaky plan a podle nej potom postupuje - nacita data do pameti, provadi joiny, sorty, agregaci... Kazda z techto operaci ma svou cenu z hlediska spotreby pameti a vypocetniho casu. Jestlize je zvolenou operaci napr. hash join tabulek o radove milionech zaznamu, trva takova operace i na hodne nabusenem zeleze nekolik desitek vterin. Pokud mam data rovnou v jedne tabulce, je cena jejich "spojeni" nulova, je to treba jeden ze scenaru pouziti materializovanych views. O jakesi "aplikacni nahrade" nebylo reci, v aplikaci samozrejme nelze dosahnout vykonu, jaky ma pro tento typ operaci databaze, ktera je na to roky optimalizovana a ma k datum pristup na nizke urovni.
23.3.2012 15:11 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Spojení se dělá vždy hledáním nějaké hodnoty. Přičemž když si to rozdělíte a podíváte se na ty náklady zvlášť, ono spojení má nulový náklad a hledání má nenulový náklad. Takže jestli přidáte to spojení nebo ho odeberete, nemá to na výkon vliv. Následující dva dotazy jsou pro databázi stejně náročné, přestože první používá spojení tabulek a druhý ne.
SELECT A.*
FROM
  table1 A
  JOIN table2 B ON (A.id = B.a_id)
WHERE
  A.id = 1

SELECT A.*
FROM
  table1 A
WHERE
  A.id = 1
23.3.2012 15:39 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
K čemu tam to B je, být DBE, tak na celý JOIN kašlu, a rozdíl nákladů bude to kroucení hlavou nad B.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
23.3.2012 15:42 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
No právě.
23.3.2012 15:45 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Hledáte tedy prvotní příčinu zvýšení náročnosti?
Tedy něco jako, že spojení tabulek nic nestojí, protože to co něco stojí, jsou ty operace nutné proto spojení? :-)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
23.3.2012 16:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Ta operace nutná pro spojení je vyhledávání. A když tu operaci vyhledávání vyvolám jinak, než při spojování tabulek, bude stát úplně stejně.
23.3.2012 15:51 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Ne ze by na tom z hlediska teto diskuse zalezelo (ucel toho prikladu nechapu), ale ty dotazy nejsou ekvivalentni a na tabulku B se vykaslat nelze.
23.3.2012 15:55 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Hm, jo, to mi ujelo (ale třeba někdy jo :-))…
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
23.3.2012 15:47 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Striktne vzato nejsou stejne narocne, protoze v prvnim pripade se cte tabulka B (nebo jeji index), coz nema nulovou cenu. Nicmene bavit se o takovych prikladech nema v zasade smysl - samozrejme ze join jednoho zaznamu za pouziti indexu nema vysoke naroky na vykon. Neco jineho ovsem uz ovsem muze byt join vsech zaznamu mezi velkymi tabulkami. Nejde o to, jak se napise dotaz, ale jak se navrhne datovy model. Jestlize se napriklad rozhodnu pro nejakou formu redundance, mohu si joiny proste zcela usetrit. Pri analytickych dotazech se casto pracuje s velkym objemem dat, nezajima me napriklad jeden konkretni klient, ale top x klientu s nejvetsim objemem obchodu. V principu musim v takovem pripade projit vsechny zaznamy o obchodech a pokud je mam v nekolika tabulkach, tak tyto musim spojit a vysledek pak mohu agregovat. Pokud mam data v jedne tabulce, tak nic nespojuju a nektere dotazy jsou i radove rychlejsi. Samozrejme ne vsechny, pokud se ptam na jednoho konkretniho klienta, tak zadne meritelne zrychleni nepocitim a pritom mam starosti s udrzenim konzistence vzhledem k redundanci, data maji o neco vetsi fyzicky objem atd. Typicky se takto konsoliduji data, u kterych uz nedochazi ke zmenam a datovy model se dela na miru ocekavanym typum dotazu.
23.3.2012 16:22 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Já už to asi jinak napsat nedokážu. Ta drahá operace je vyhledávání. V joinu je vždy skryté vyhledávání. Ale to spojení nepřidává žádné náklady navíc, nad to vyhledávání. Takže myslet si, že když místo spojení použiju vyhledávání, něco tím ušetřím, je to nesmysl. Můžu ušetřit tím, že jinak postavím dotaz, udělám jiné indexy, jinak rozvrhnu data. Ale pokud dva dotazy povedou na použití stejných indexů ve stejném pořadí a se stejnými daty, a v jednom případě půjde o spojení a v druhém o čisté hledání, nebude v tom z hlediska náročnosti operace žádný rozdíl, to spojení nepřidá žádnou složitost navíc k tomu vyhledávání.
23.3.2012 16:39 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Ja vubec nechapu, co je podle tebe spojeni a co vyhledavani a proc na tom zalezi. Dotazem snad vzdycky neco hledam, proc bych ho jinak delal? Zda je k takovemu hledani treba join konkretnich tabulek zalezi na datovem modelu. Co rikam je, ze kdyz dam data do jedne tabulky, tak nemusim delat join. Kdyz je mam ve dvou, tak musim delat join (lepe receno databze ho musi udelat). Napriklad pokud mam v tabulce klient priznak, zda ma kreditku, a chci zjistit sumu operaci klientu bez kreditky, tak musim klienty spojit s operacemi, jinak nepoznam, zda mam danou operaci zapocitat. Pokud je klientu bez kreditky milion a operaci sto milionu, tak takove spojeni pobezi docela dlouho. Pokud budu mit priznak o kreditce rovnou v operacich, tak zadne spojeni neprovadim a rovnou agreguju v ramci fullscanu tabulky operaci (ktery musi probehnout v obou scenarich).
23.3.2012 19:34 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Jenže tady řešíme jiný případ. Buď budu mít data ve dvou tabulkách a indexy, přes které je dokážu propojit. Nebo budu mít data v jedné tabulce a nad ní takový index/indexy, které budou to propojení dvou tabulek simulovat. Já tvrdím, že to spojení dvou tabulek nepřináší žádnou zátěž navíc a principiálně bude obojí stejně rychlé, protože se bude používat stejný typ indexů nad stejnými daty.
23.3.2012 23:28 kuka
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
V mnou uvadenem prikladu se v zadne rozumne databazi indexy nebudou pri spojeni pouzivat, to by trvalo pul dne. Kdyz mam data v jedne tabulce, tak proc bych simuloval nejake spojeni, to je blabol. Evidentne neznas zakladni algoritmy pouzivane v databazovych strojich. Na tom neni nic spatneho a pro radu aplikaci transakcniho typu, jako jsou ruzne eshopy apod., to nemusi vubec vadit, take jsem to prilis neznal, dokud jsem to nezacal potrebovat. Ale nesir prosim bludy typu ze spojeni velkych tabulek nic nestoji.
24.3.2012 09:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Proč se k tomu pořád vyjadřujete, když jste nepochopil, o čem se bavíme? Tak se prostě smiřte s tím, že to píšu nesrozumitelně a vám není dáno to z mého textu pochopit. Já jsem nikdy nenapsal, že spojení tabulek nic nestojí, takže celé vaše komentáře na tom postavené jsou k ničemu.
okbob avatar 23.3.2012 20:24 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: Jak v postgresu na indexované vyhledávání podle n-tého znaku ve sloupci
Pro časové řady jsou v PostgreSQL pole - pro každou stanici a hodinu můžete mít pole o 3600 prvcích a nemusíte provádět ručně takovéhle ošklivosti - když už používáte relační db, tak není ani praktické snažit se do db ukládat závislé magické konstanty - to už pak je lepší cpát data do souboru jelikož na takhle deformovaných datech se stejně dost špatně píší dotazy.

Pole v PostgreSQL jsou docela vychytávka - navíc pro Vás transparentně se komprimuje obsah. A pokud nebudete extrémně často měnit konfiguraci, tak tím snížíte počet záznamů v tabulkách, cca o 3600/počet stanic - jestli jsem to pochopil, což při režii, kterou má pg, ke každému záznamu může být významná úspora.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.