Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Diplomová práce SaaS na technickou a obsahovou analýzu webu Bc. Ján Januška Vedoucí práce: Ing. Jaroslav Vidím 29. května 2012

4

5 Poděkování Rád bych poděkoval Ing. Jaroslavovi Vidímovi za odborné konzultace během práce na diplomové práci a při jejím dalším rozvoji.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 29. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Ján Januška. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Ján Januška. SaaS na technickou a obsahovou analýzu webu: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

9 Abstract The graduation theses deal with a design of application for technical and content web analysis with primary direction to search engine optimization and web accessibility. There is performed detailed retrieval of competitive tools before particular design. Those are fundamental elements for elaboration of analysis and aims, which must be executed by application because of fairly big competition. The design consist of several different resolutions from which is chosen the most effective one. For final design is implemented prototype to confirm the design legitimacy. Keywords content analysis, technical analysis, search engine optimization, accessibility, web crawler, software as a service, Google App Engine Abstrakt Diplomová práce se zabývá návrhem aplikace pro technickou a obsahovou analýzu webu, s primárním zaměřením na optimalizaci pro vyhledávače a přístupnost webových stránek. Před samotným návrhem je provedena detailní rešerše konkurenčních nástrojů. Ta byla stěžejním prvkem pro vypracování analýzy a cílů, které musí aplikace splnit, aby mohla uspět v nemalé konkurenci. 9

10 Návrh sestává z několika různých řešení, ze kterých bylo vybráno to nejefektivnější. Pro výsledný návrh byl implementován prototyp, aby se potvrdila správnost návrhu. Klíčová slova obsahová analýza webu, technická analýza webu, optimalizace pro vyhledávače, přístupnost, vyhledávací robot, software jako služba, Google App Engine 10

11 Obsah Úvod 17 1 Uvedení do problematiky a vymezení pojmů Fulltextové vyhledávače Optimalizace pro vyhledávače (SEO) Přístupnost Rešerše existujících nástrojů Hodnotící kritéria Výběr konkurenčních nástrojů Analýza konkurenčních nástrojů Analýza a požadavky na aplikaci Cíle aplikace Funkční požadavky Nefunkční požadavky Omezení Návrh High-level architektura Prvotní návrh Zefektivnění návrhu Výsledný návrh Implementace prototypu Použité technologie Implementace Zhodnocení a další vývoj 69 11

12 Závěr 71 A Seznam použitých zkratek 73 B Seznam funkcí pro technickou analýzu 75 C Obsah přiloženého CD 79 12

13 Seznam obrázků 1.1 Ukázka struktury fulltextového vyhledávače Ukázka rozhraní vyhledávače Google Ukázka vyhledávače Seznam, který na rozdíl od Google používá ve výsledcích vyhledávání i přímé náhledy nalezených stránek Proces tvorby webu a související SEO praktiky SEO metody využívané během provozu webu Screenshot z programu XENU Vizualizace link grafu(? ), s využitím nástroje Gephi Screenshot z programu Screaming Frog SEO Spider Tool Screenshot z programu IIS SEO Toolkit Screenshot aplikace Analytics SEO Screenshot aplikace Bing Webmaster Tools Screenshot aplikace SEO Servis High-level architektura aplikace Diagram analytických tříd Ukázka link grafu: Uzly tvoří URL adresy, resp. entity třídy Url- Data. Hrany jsou odkazy, resp. entity třídy Link Activity diagram životního cyklu entity z Queue Activity diagram pro nalezení nových odkazů pro Queue Diagram analytických tříd Activity diagram jednoho Task procesu Activity diagram pro nalezení nových odkazů pro TaskQueue Ukázka metody Sharding Counters - uložení dat Ukázka metody Sharding Counters - načtení dat Výsledný diagram analytických tříd Activity diagram úkolu, který zpracovává URL Activity diagram úkolu TaskControl Průběh od HTTPServletRequest až po HTTPServletResponse (? )

14 5.2 Ukázka úvodní stránky prototypu. Je na ní zobrazen přehled analýz Ukázka detailu analýzovaného webu

15 Seznam tabulek 1.1 (X)HTML tagy posuzované vyhledávači Souhrnné hodnocení XENU s Link Sleuth Souhrnné hodnocení Screaming Frog SEO Spider Tool Souhrnné hodnocení IIS SEO Toolkit Souhrnné hodnocení Analytics SEO Souhrnné hodnocení Bing Webmaster Tools Cílové hodnotící kritéria Příklady technických nedostatků. Kompletní přehled se nachází v příloze B

16

17 Úvod K běžným návštěvníkům webových stránek nepatří jenom lidi, ale taky vyhledávací roboti a další software. Stroj si zřejmě neobjedná zboží, služby a ani jiným způsobem nebude zdrojem přímých příjmů. Ale i tak může být jeho návštěva prospěšná, protože má často schopnost zprostředkovat web jiným, živým návštěvníkům. Například hendikepovaní uživatelé jsou v mnohých případech zcela odkázáni na pomoc asistivního softwaru, který přečte obsah webových stránek namísto nich. Velmi důležití jsou taky vyhledávací roboti, kteří navštěvují stránky napříč webem a shromažďují informace, které skrz vyhledávač najdou živí uživatelé. Proto je důležité, aby software dokázal najít, zpracovat a následně i správně interpretovat obsah na webu. Existují různé překážky, které mohou robotům zkomplikovat, nebo úplně zmařit zpracování obsahu. Tyto překážky dokáže odhalit software na technickou analýzu webu. Simuluje robota a informuje o všech problémech, které mu způsobují potíže. Ale i v případě, že si vyhledávací robot dokáže se stránkami na webu poradit, neznamená to, že bude přivádět mnoho návštěvníků z vyhledávání. Je totiž nutné, aby se na webu nacházel obsah, který uživatelé vyhledávají. Nejdůležitější obsahové prvky (titulky, nadpisy) je vhodné upravit takovým způsobem, aby obsahovaly klíčová slova, která uživatelé vyhledají. Během kontroly správnosti obsahových prvků, značně pomůže obsahová analýza webu. Původním cílem práce bylo navrhnout a implementovat webovou aplikaci na technickou a obsahovou analýzu webu, která dokáže uspět mezi nemalou konkurencí. Bohužel jsme zpočátku nedostatečně odhadli náročnost aplikace jak pro fázi návrhu, tak i implementace. V případě, že bychom pracovali na všech fázích projektu, výsledná služba by jako celek nemohla být dostatečně kvalitní. A s nekvalitní službou se jen velmi těžce uspěje. Z toho důvodu jsme se rozhodli zaměřit především na návrh náročnějších částí aplikace. S kvalitním návrhem úzce souvisí i důkladná analýza a rešerše konkurence. Výsledný návrh pak implementujeme do podoby prototypu, abychom mohli ověřit, jestli je návrh správný. 17

18

19 Kapitola 1 Uvedení do problematiky a vymezení pojmů 1.1 Fulltextové vyhledávače Fulltextový vyhledávač (dále jen vyhledávač) je program, který na základě zadaného dotazu vygeneruje seznam webových dokumentů, které jsou pro vyhledávač (a v ideálním případě taky uživatele) nejvíce relevantní. Ve světě je nejrozšířenějším vyhledávačem Google 1. V české republice má kromě Google významný podíl na trhu i vyhledávač Seznam 2. Obrázek 1.1: Ukázka struktury fulltextového vyhledávače

20 1. Uvedení do problematiky a vymezení pojmů Vyhledávač obvykle tvoří 4 hlavní komponenty, které zajišťují: Sběr dat Indexaci Zpracování dotazu a vyhodnocení výsledků Zobrazení výsledků Sběr dat Sběr dat neboli crawling zajišťuje vyhledávací robot (crawler, spider). Jeho primárním úkolem je prohledávání webových dokumentů. Strukturu webu prochází prostřednictvím hypertextových odkazů 3. V rámci sběru dat se robot zaměřuje především na: Nalezení nových dokumentů Aktualizace stávajících dokumentů V současnosti nemají vyhledávače dostatečnou výpočtovou kapacitu na to, aby crawleři neustále pokrývali veškerý obsah na webu. Z toho důvodu se musí vyhledávací roboti rozhodnout, které webové dokumenty budou prohlížet a v jakém intervalu budou kontrolovat, jestli nebyly aktualizované Indexace Množství dat, které je indexováno, resp. ukládáno do databáze je velmi vysoké. Vyhledávače s celosvětovým zaměřením indexují webové dokumenty v řádu bilionů (10 12 ). Velikost indexu vyhledávače Google tvoří podle odhadů(? ) více než stránek. Kromě ukládání samotného obsahu je potřeba udržovat informace taky o tom, v jaké části stránky se jednotlivé složky obsahu nacházejí (např. jaký obsah se nachází v titulku, nadpisech apod.) Tyto informace patří k tzv. hodnotícím faktorům, které jsou důležité při výsledném seřazení výsledků vyhledávání. Pro každou stránku se zaznamenávají i další data, která při zpracování dotazu budou sloužit jako hodnotící faktory, které se nevztahují přímo k obsahu, ale ke kvalitě stránky. K nim patří různé ranky, v případě Google je to například PageRank 4. 3 Odkazy vedoucí na url adresy v rámci hypertextu, typicky World Wide Webu. Nacházejí se zejména v (X)HTML dokumentech, ale můžou se vyskytovat i v dalších typech souborů, jako například PDF, nebo DOC. 4 Algoritmus pro hodnocení hypertextových stránek, který vychází ze struktury odkazů. Přesná podoba PageRank algoritmu, který využívá Google není známá, ale vychází z výzkumné práce(? ) zakladatelů Google, Lawrence Page a Sergey Brina. 20

21 1.1. Fulltextové vyhledávače Zpracování dotazu a vyhodnocení výsledků Po zpracování dotazu se vyhledá odpovídající množina dat z indexu. Ta je následně zpracována a pomocí hodnotících faktorů se jednotlivé webové dokumenty seřadí podle vypočítané hodnoty relevance. Hodnotící algoritmy a vhodné nastavení vah jednotlivých faktorů jsou nejdůležitější součástí vyhledávačů Zobrazení výsledků Zobrazování výsledků je ve většině fulltextových vyhledávačů velmi podobné. Mezi typicky zobrazované informace patří: Titulek - Obsah (X)HTML tagu <title> Popisek - Popis stránky generovaný z textového obsahu, nebo tagu <meta>, s atributem name="description" URL adresa nalezené stránky Obrázek 1.2: Ukázka rozhraní vyhledávače Google Obrázek 1.3: Ukázka vyhledávače Seznam, který na rozdíl od Google používá ve výsledcích vyhledávání i přímé náhledy nalezených stránek. 21

22 1. Uvedení do problematiky a vymezení pojmů 1.2 Optimalizace pro vyhledávače (SEO) Optimalizace pro vyhledávače je proces, během kterého se zvyšuje popularita webových stránek takovým způsobem, aby se za pomoci neplacených výsledků vyhledávání zvýšil počet relevantních návštěvníků. Cílem je přivést na web návštěvníky, kteří hledají nabízený obsah, resp. informace, zboží nebo služby. Konkrétními cíli může být například: Zvýšení relevantní návštěvnosti Prodej produktů a služeb Budování značky Zlepšování v oblasti reputačního managementu Na rozdíl od většiny marketingových metod (např. televizní reklamy nebo display 5 reklamy), je SEO nenucený způsob propagace. Uživateli je obsah na webu nabízen jenom ve chvíli, když má o něj přímý zájem. Optimalizace pro vyhledávače by měla doprovázet web od jeho počáteční fáze (plánování) až po realizaci a následně taky během provozu. Obrázek 1.4: Proces tvorby webu a související SEO praktiky 5 Druh reklamy, který přiláká pozornost svým vzhledem. V prostředí internetu je to např. bannerová reklama. 22

23 1.2. Optimalizace pro vyhledávače (SEO) Obrázek 1.5: SEO metody využívané během provozu webu. Realizaci jednotlivých metod optimalizace pro vyhledávače můžeme zařadit do 2 hlavních kategorií: On-page SEO Off-page SEO On-page SEO Jak naznačují obrázky 1.4 a 1.5, k on-page SEO patří veškeré faktory, které se nacházejí na optimalizovaném webu. Můžeme je tedy přímo ovlivňovat. Patří k nim obsah na stránce a jeho správná interpretace. On-page SEO se skládá z technických a obsahových aspektů. Tato problematika, resp. detekce technických nedostatků a výpomoc při optimalizaci obsahu, je hlavním předmětem diplomové práce Technické aspekty Slouží k tomu, aby vyhledávač neměl problém s přecházením webu (1.1.1), indexací (1.1.2) a následně se správnou interpretací, resp. pochopením obsahu. Vyhledávací robot může mít mnoho problémů, které mu zcela zabrání, nebo zkomplikují sběr dat: Nepřístupnost navigace nebo obsahu, dlouhá odezva, duplicitní obsah a podobně. Crawler by měl rozpoznat strukturu a důležitost každé části textu. Měla by mu být podána informace o tom, která část obsahu je titulek, nadpis, jestli 23

24 1. Uvedení do problematiky a vymezení pojmů se jedná o důležitý text a podobně. Obsah je interpretován prostřednictvím (X)HTML tagů. Na základě struktury tagů jednotlivých podstránek robot dokáže odhadnout i to, ve které části se nachází hlavička stránky, hlavní obsah a pod.. K nejdůležitějším (X)HTML tagům, které vyhledávače posuzují patří(? ): Název Tag Popis Titulek <title> Nejdůležitější on-page faktor. Zobrazuje se i jako nadpis ve výsledcích vyhledávání a ovlivňuje míru prokliku z výsledků vyhledávání. Nadpisy <h1> až <h6> Největší vliv má pochopitelně nadpis 1. úrovně. Popis stránky <meta name="description"> Nemá vliv na hodnocení. Ale často se zobrazuje ve výsledcích vyhledávání jako popis stránky. Když není tag vyplněný, vyhledávače vygenerují popisek z obsahu stránky, což nemusí být vždy žádoucí. Zvýšený přínos je nízký, případně žádný. Zvýrazněný text <strong>, <em>, resp. <b>, <i> Popis obrázků <img>, atribut "alt" Alternativní popisek obrázků by měl být definován pro každý obrázek, který není jenom dekoračního charakteru. Tabulka 1.1: (X)HTML tagy posuzované vyhledávači Bezproblémové zpracování dat a jejich správná interpretace je nutná podmínka, bez které nelze SEO realizovat vůbec, nebo jen se značným omezením. Je to tedy základ, který by měl splňovat každý web Technická analýza webu Technická analýza webu se zaměřuje na kontrolu veškerých technických aspektů. Může být prováděná takřka ručně, což je časově velmi náročné a nespolehlivé, nebo pomocí specializovaných nástrojů. Simulací vyhledávacího robota lze automaticky najít většinu problémů Obsahové faktory K tomu, aby webová stránka přiváděla návštěvnost z neplaceného vyhledávání, musí obsahovat text a klíčová slova, která jsou pro uživatele přínosná a 24

25 1.3. Přístupnost vyhledávají je. Z toho důvodu je velmi důležitá analýza klíčových slov, tvorba obsahu a následná aplikace obsahu do titulku, nadpisů apod Obsahová analýza webu Zabývá se kontrolou obsahu na webu. Automatická kontrola má velmi omezené možnosti, protože kvalitu obsahu nedokáže software spolehlivě rozpoznat. Hlavní přínos nástrojů určených pro obsahovou analýzu není v automatickém vyhodnocování, ale zejména ve vhodné agregaci dat (např. přehledné zobrazení titulků na webu apod.) Off-page SEO Off-page činitele se nacházejí mimo stránky. Z toho důvodu je není možné přímo ovlivnit. Vyjadřují popularitu web stránky, resp. její hodnocení. Každá stránka na internetu má možnost "hlasovat"za jiné stránky. Když jedna stránka odkazuje na jinou, dává ji svůj "hlas", doporučuje jí a zvyšuje tak její popularitu. Čím vyšší počet externích odkazů stránka obsahuje, tím slabší hlas odevzdává odkazovaným stránkám. Hodnota hlasu nezávisí jenom na celkové popularitě stránky, ale taky například na zaměření stránek, resp. tematické podobnosti odkazující a odkazované stránky. 1.3 Přístupnost Ve všeobecnosti pojem přístupnost znamená přístup bez bariér, bez jakýchkoliv překážek. Přístupnost webových stránek charakterizuje bezproblémový přístup k obsahu na webu pro hendikepované uživatele. Mezi tyto uživatele internetu patří každý, kdo má specifické požadavky na prohlížení webových stránek. Do této skupiny patří například: Nevidomí, nebo jinak zrakově postihnutí Neslyšící Uživatelé s pohybovým postižením Návštěvníci s poruchami soustředění Uživatelé s jiným fyzickým nebo psychickým postižením (epileptici apod.) Uživatelé používající nestandardní software (např. textový prohlížeč), nebo zařízení (zastaralé CRT monitory apod.) Hendikepovaní uživatelé při prohlížení webu často využívají asistivní zařízení nebo software (Braillský řádek(? ), odečítač obrazovky(? ) apod.). Asistivní 25

26 1. Uvedení do problematiky a vymezení pojmů software interpretuje obsah obdobně jako web crawler, resp. vyhledávacího robota můžeme taky považovat za "hendikepovaného uživatele". Technické prvky ( ) SEO a přístupnosti jsou v mnohých ohledech totožné. Když je stránka přístupná pro uživatele, s velkou pravděpodobností jsou v pořádku i technické prvky SEO. Ale naopak to nemusí až tak často platit, protože člověk web nejenom prohlíží, ale je s ním v přímé interakci. Pro hendikepovaného uživatele je např. často důležité ovládání pomocí klávesnice, potřebuje se orientovat ve webových formulářích atd. Z toho důvodu je problematika uživatelské přístupnosti značně komplikovanější, než přístupnost pro vyhledávací roboty. 26

27 Kapitola 2 Rešerše existujících nástrojů Cílem práce je navrhnout aplikaci, která co nejvíce usnadní práci s technickou a obsahovou analýzou webu. Měla by mít vlastnosti a funkce, které budou pro potenciální uživatele větším přínosem, než konkurenční software. Rešerším existujících nástrojů jsme věnovali značné úsilí. Snažili jsme se najít všechny přímé i nepřímé konkurenty, které jsme následně analyzovali z 2 hlavních důvodů: V případě, že již kvalitní software existuje a není dostatečný prostor na zlepšení, nemá velmi smysl zabývat se návrhem nástroje, o který nebude dostatečný zájem. Některé existující řešení můžou být velmi dobrou inspirací. A naopak, jiný konkurenční systém může být varovným signálem v tom, jakou cestou návrhu se nemáme vybrat a čemu se máme vyvarovat. 2.1 Hodnotící kritéria Ještě před samotnou analýzou konkurenčních projektů je potřebné stanovit základní hodnotící kritéria: Přístupnost k systému Typ aplikace Dostupné operační systémy Funkcionalita Kvalita obsahové analýzy Kvalita technické analýzy 27

28 2. Rešerše existujících nástrojů Další funkční kritéria Schopnost zpracování vysokého objemu dat Rychlost zpracování URL adres webu Chybovost aplikace Uživatelská přívětivost (User experience) Správa uživatelů Cena Typ aplikace Jestli se jedná o desktopovou, webovou, případně mobilní aplikaci. Nejvhodnějším typem jsou webové aplikace, jelikož fungují na každém zařízení podporujícím používání internetu. U desktopových aplikací je často nevyhnutná i instalace a jsou s nimi spojeny i další nevýhody. Jednou z mála výhod oproti webovým aplikacím může být nezávislost na používání externích serverů, což snižuje náklady. Ale na druhou stranu výkon osobního počítače nemusí být vždy dostačující. Dostupné operační systémy Operační systémy seřazené podle důležitosti: MS Windows, Mac OS, Linux. Kvalita technické a obsahové analýzy Funkcionalita je nejdůležitější hodnotící kritérium. Škála ohodnocení je 1-5, přičemž 1 znamená výbornou kvalitu, 5 je nevyhovující kvalita. Schopnost zpracování vysokého objemu dat Důležité kritérium, které informuje o tom, jak velký web dokáže aplikace zpracovat. Škála hodnocení podle bezproblémového zpracování webu (na základě počtu stránek): 28 Velmi nízká - do 1000 stránek Nízká až stránek Střední až stránek Vysoká až stránek Velmi vysoká - více jako stránek

29 2.2. Výběr konkurenčních nástrojů Rychlost zpracování URL adres webu Rychlost zpracování je shora omezená, na základě možností a nastavení serverů, ze kterých jsou data získávána. Proto budeme hodnotit rychlost vzhledem k existujícím možnostem. V tomto případě zanedbáme možnost nastavení rychlosti sběru dat a předpokládáme, že nastavení bude provedeno správně. Tj. maximální rychlost nebude překročena a cílový server nezačne další žádosti o načítání stránek odmítat. Rychlost může být: nízká, střední a vysoká. Chybovost aplikace Na základě množství a důležitosti programových chyb, rozdělíme chybovost na: nízkou, střední, vysokou. User experience Bez hlubšího testování se UX špatně hodnotí. Budeme vycházet především z best practices 6 a našich zkušeností. Škála hodnocení je 1-5, přičemž 1 znamená výborné UX, 5 je nevyhovující. Správa uživatelů Hodnotí, jestli lze projekty sdílet mezi více uživateli, s klientem apod. Možností přístupu může být mnoho, z toho důvodu bude správa uživatelů hodnocená slovně. Cena Uvedení ceny nástroje. 2.2 Výběr konkurenčních nástrojů Celkově jsme analyzovali více jako 20 různých nástrojů. V následujícím seznamu uvádíme výběr 15 softwarových aplikací, které jsme seřadili do několika skupin: Desktopové aplikace XENU s Link Sleuth Screaming Frog SEO Spider Tool IIS SEO Toolkit Integrity 6 Známé postupy, které vycházejí z běžných, případně modelových problémů. 29

30 2. Rešerše existujících nástrojů Link Examiner WebSite Auditor Web Link Validator Systémy na komplexní správu SEO Seomoz PRO Analytics SEO 80 Legs AnalyticsSEO Web SEO Analytics Nastroje poskytované vyhledávači Google Webmaster Tools Bing Webmaster Tools Miniaplikace SEO Servis 2.3 Analýza konkurenčních nástrojů Nebudeme vyhodnocovat všechny konkurenty. Zaměříme se na nejpopulárnější a nejlepší nástroje a na aplikace, které jsou nějakým způsobem zajímavé. Vybrali jsme nástroje: XENU s Link Sleuth Screaming Frog SEO Spider Tool IIS SEO Toolkit Analytics SEO Bing Webmaster Tools SEO Servis XENU s Link Sleuth XENU 7 patří k nejpopulárnějším (a zdarma dostupným) nástrojům na technickou analýzu. Není používán jenom pro účely SEO. Populárním se stal

31 2.3. Analýza konkurenčních nástrojů hlavně kvůli jednoduché kontrole nefunkčních odkazů 8. Pro tento účel je to velmi dobrý a lehce použitelný nástroj. XENU je potřeba brát hlavně jako nástroj na dolování dat z webových stránek. Jejich zpracování je již na uživateli. Velmi často se využívá např. export do tabulkového procesoru (Microsoft Excel apod.), kde se data agregují do požadované formy. Tento postup obvykle není problémem pro webmastery. Ale optimalizace pro vyhledávače je marketingový obor a nemalá část SEO konzultantů nemá s "technickými"postupy mnoho zkušeností. Nemusí být pro každého snadné, naučit se agregovat data podle různých pravidel. Z obsahových faktorů, XENU poskytuje u (X)HTML stránek tvar url, titulku a popisku stránky. Při obsahové analýze to velmi pomůže, ale ještě chybí informace o nadpisech. Taky nelze analyzovat texty interních odkazů, což značně komplikuje analýzu interního prolinkování. Kromě (X)HTML stránek je možné kontrolovat taky obrázky, u kterých se zobrazuje alternativní popisek. Obrázek 2.1: Screenshot z programu XENU Z pohledu technických faktorů nástroj neposkytuje některé důležité informace, jako například zamezení pro vyhledávací roboty - Zákaz indexace nebo zákaz následování odkazů. Odhalování technických chyb často závisí od schopnosti uživatele agregovat data. Na vhodnou agregaci existují různé návody 9, 8 Za nefunkční odkaz je považován odkaz na URL, která vrací stavový kód 404, nebo jiný chybový stav (kódy 4xx, 5xx)

32 2. Rešerše existujících nástrojů ale i s jejich pomocí se technická analýza značně prodlužuje. Kromě výpisů dat o jednotlivých stránkách, XENU poskytuje i možnost exportu dat pro tzv. link graf, tj. graf který zobrazuje vztahy mezi odkazy celého webu. Soubor je možné zpracovat v některém ze specializovaných softwarů (např. Gephi 10 ). Je tak možno vizualizovat odkazovou strukturu, ze které se dají často vyvozovat další důležité informace. Ale vzhledem k náročnosti není tento způsob práce s nástrojem XENU rozšířený. Obrázek 2.2: Vizualizace link grafu(? ), s využitím nástroje Gephi

33 2.3. Analýza konkurenčních nástrojů Souhrnné hodnocení XENU s Link Sleuth Kritérium Hodnota Typ aplikace Desktopová Dostupné operační systémy MS Windows Kvalita obsahové analýzy 3 Kvalita technické analýzy 3 Schopnost zpracování vysokého objemu dat Střední Rychlost zpracování analýzy Vysoká Chybovost aplikace Nízká User experience 4 Správa uživatelů Žádná Cena Zdarma Tabulka 2.1: Souhrnné hodnocení XENU s Link Sleuth Největší problém XENU je v User experience a nemožnosti zpracovat vysoký počet URL. Kvalita analýz taky není oslnivá. Ale i vzhledem k tomu je XENU užitečným nástrojem a zdarma poskytuje širokou škálu funkcí Screaming Frog SEO Spider Tool Tento nástroj je označován jako "Software pro SEO konzultanty od SEO konzultantů"(? ). Je to komerční desktopová aplikace, která je podobná XENU(2.3.1), ale vyvaruje se jeho mnohým problémům. Obrázek 2.3: Screenshot z programu Screaming Frog SEO Spider Tool 33

34 2. Rešerše existujících nástrojů Pro obsahovou analýzu poskytuje i kontrolu nadpisů 1. a 2. úrovně. Taky je možné analyzovat anchor texty 11 příchozích interních odkazů. Během technické analýzy hodně pomůžou nejrůznější způsoby agregace dat, které jsou přímo součástí uživatelského rozhraní. I když vhodné zobrazení dat má ještě výrazné rezervy, např. oproti XENU je to mnohem lepší. Jak jsme uvedli na začátku, nástroj je určen pro SEO konzultanty, tj. osoby, které velmi dobře rozumí problematice optimalizace pro vyhledávače. Nástroj tedy není vhodný pro méně pokročilé uživatele Souhrnné hodnocení Screaming Frog SEO Spider Tool Kritérium Hodnota Typ aplikace Desktopová Dostupné operační systémy MS Windows, Mac OS Kvalita obsahové analýzy 2 Kvalita technické analýzy 2 Schopnost zpracování vysokého objemu dat Střední Rychlost zpracování analýzy Vysoká Chybovost aplikace Nízká User experience 3 Správa uživatelů Žádná Cena 99/ročně, 1 licence. (tj. cca kč/ročně) Tabulka 2.2: Souhrnné hodnocení Screaming Frog SEO Spider Tool Software nabízí kvalitní technickou i obsahovou analýzu. Nicméně prostor pro vylepšování je stále nezanedbatelný. GUI se při analýzách větších webů stává nepřehledným. Jinak je používání nástroje bezproblémové a z veškerých komerčních řešení nabízí nejvíc funkcí. Pro SEO konzultanty, kteří pracují samostatně a nepotřebují často analyzovat rozsáhlé weby, je Screaming Frog velmi dobrá volba. Komplikace nastávají až při kooperaci většího počtu konzultantů, kdy je potřeba zakoupit licenci každému z nich. Vzhledem k chybějící správě uživatelů je i případná kooperace problémem. 11 Anchor text je text odkazu. Např. v <a href="/url.html">seo</a>, je anchor textem slovo "SEO". 34

35 2.3. Analýza konkurenčních nástrojů IIS SEO Toolkit IIS SEO Toolkit 12 je zdarma dostupný produkt od Microsoftu. Ke zpracování dat přistupuje odlišným způsobem jako XENU a Screaming Frog. Nezobrazuje jenom URL adresy (a jejich vlastnosti), ale vytváří tzv. reporty, které obsahují i popisy problémů a způsoby jak je odstranit. Takže nástroj už nemusí být určen jenom profesionálům z oboru SEO. Kromě toho nástroj nabízí rozhraní na filtrování a agregaci dat, které lze využít při pokročilých analýzách. Obrázek 2.4: Screenshot z programu IIS SEO Toolkit Nástroj neumožňuje práci jenom s URL adresami, ale dokáže agregovat i informace o odkazech, včetně anchor textů. To poskytuje nové možnosti v analýze interního prolinkování. Bohužel Microsoft hází sám sobě "klacky pod nohy". Nástroj má problémy se stabilitou a poradí si jenom se znakovou sadou UTF-8. Veškerou manipulaci s daty si ukládá do operační paměti a při analýze rozsáhlejšího webu je práce s aplikací pomalá

36 2. Rešerše existujících nástrojů Souhrnné hodnocení IIS SEO Toolkit Kritérium Hodnota Typ aplikace Desktopová Dostupné operační systémy MS Windows Vista, MS Windows 7, MS Windows Server Kvalita obsahové analýzy 1 Kvalita technické analýzy 2 Schopnost zpracování vysokého objemu dat Střední Rychlost zpracování analýzy Vysoká Chybovost aplikace Vysoká User experience 2 Správa uživatelů Žádná Cena Zdarma Tabulka 2.3: Souhrnné hodnocení IIS SEO Toolkit IIS SEO Toolkit nabízí nejlepší funkčnost jak technické, tak i obsahové analýzy. Z toho ohledu ho nepředčí ani zpoplatněné nástroje. Ale velké problémy s chybovostí a nízká dostupnost pro operační systémy, dělají nástroj často nepoužitelným Analytics SEO Analytics SEO 13 je placená webová aplikace na komplexní správu SEO. Námi hodnocená kritéria jsou součástí balíčku nabízených nástrojů. Obrázek 2.5: Screenshot aplikace Analytics SEO

37 2.3. Analýza konkurenčních nástrojů Ze všech hodnocených komerčních aplikací je Analytics SEO nejpřínosnější. GUI je velmi intuitivní a veškeré informace jsou podány formou, které porozumí i méně zkušený uživatel, např. majitel kontrolovaného webu, pracovníci marketingu apod. Z pohledu kvality obsahové a technické analýzy webu Analytics SEO nenabízí tolik možností jako např. IIS SEO Toolkit Tento komplexní nástroj je vhodný pro marketingové pracovníky, kteří nejsou úzce specializovaní jenom na optimalizaci pro vyhledávače, ale potřebují vývoj SEO nějakým způsobem monitorovat Souhrnné hodnocení Analytics SEO Kritérium Hodnota Typ aplikace Webová Dostupné operační systémy Všechny (s dostupným prohlížečem) Kvalita obsahové analýzy 3 Kvalita technické analýzy 2 Schopnost zpracování vysokého objemu dat Vysoká Rychlost zpracování analýzy Střední Chybovost aplikace Nízká User experience 2 Správa uživatelů Žádná Cena Začíná na 99/měsíčně (tj. cca kč/měsíčně) Tabulka 2.4: Souhrnné hodnocení Analytics SEO Cena Analytics SEO je velmi vysoká, vzhledem k přínosům technické a obsahové analýzy webu. Za uvedených 99/měsíčně lze analyzovat max. 5 domén, s počtem stránek nižším jako Ale je potřeba brát do úvahy, že tato webová aplikace nabízí mnohem více funkcí, které nejsou předmětem rešerše Bing Webmaster Tools Nástroj 14 poskytuje přímo vyhledávač Bing. Není to standardní typ nástroje jako ostatní analyzované aplikace. Uživatel se nemusí vůbec zabývat zahájením sběru dat, vše zajistí Bing. Jelikož informace pocházejí "přímo od zdroje", poskytované informace jsou zcela přesné. Můžeme tak přímo monitorovat, s čím má vyhledávač problémy. Taky poskytuje mnoho dalších informací, které lze externími nástroji zjistit

38 2. Rešerše existujících nástrojů jen těžko (např. počet zaindexovaných stránek v Bingu). Webmaster Tools od Bingu si bez problémů poradí taky s obrovskými weby (což je pochopitelné). Obrázek 2.6: Screenshot aplikace Bing Webmaster Tools Nástroj poskytuje informace jenom o pár nejzásadnějších technických nedostatcích. Obsahová analýza není s Bing Webmaster Tools vůbec možná Souhrnné hodnocení Bing Webmaster Tools Kritérium Hodnota Typ aplikace Webová Dostupné operační systémy Všechny (s dostupným prohlížečem) Kvalita obsahové analýzy 5 Kvalita technické analýzy 3 Schopnost zpracování vysokého objemu dat Velmi vysoká Rychlost zpracování analýzy Nízká Chybovost aplikace Nízká User experience 1 Správa uživatelů Možnost sdílet účet s více uživateli, přičemž je možné dát přístup jenom "ke čtení". Cena Zdarma Tabulka 2.5: Souhrnné hodnocení Bing Webmaster Tools 38

39 2.3. Analýza konkurenčních nástrojů Bing Webmaster Tools kontroluje každé 2 týdny nejzásadnější technické nedostatky. Ale momentálně neposkytuje plnohodnotné možnosti pro obsahovou a technickou analýzu webu. Nástroj zpracuje i velmi rozsáhlé weby. Používání nástroje je jednoduché a intuitivní. Vytvořit pro Bing komplexnější nástroj nemusí být problém. Obdobně jako IIS SEO Toolkit, společnost Microsoft vlastní taky Bing. V případě, že se k tomuto kroku Bing odhodlá, bude se mu jen těžce konkurovat SEO Servis Podobných mini aplikací existují desítky. Nástroj analyzuje jenom jednu URL a pro hlubší analýzu není vhodný. Při nesprávné interpretaci může být dokonce zavádějící(? ). Obrázek 2.7: Screenshot aplikace SEO Servis Do rešerší jsme tento nástroj zahrnuli z toho důvodu, že jednoduchým (i když diskutabilním) rozborem dokáže zaujmout laiky, kteří SEO nerozumí. Z programátorského hlediska je tedy nástroj nepodstatný, ale z byznys hlediska je inspirativní. 39

40

41 Kapitola 3 Analýza a požadavky na aplikaci Před stanovením cílů si musíme položit otázku V čem může být technická a obsahová analýza prospěšná, jaký má přínos? Technická analýza by měla poskytnout rychlý přehled o tom, jestli web nemá nějaké technické potíže a jeho obsah dokáže zpracovat software. Tj., upozorní nás, když můžou mít s webem problém vyhledávací roboti, asistivní software apod. Uživatel se tedy ihned dozví, jestli web: Zbytečně přichází o návštěvnost z vyhledávačů Zabraňuje hendikepovaným, nebo jinak indisponovaným v přístupu k informacím Má jiné nedostatky, které komplikují jeho používání Technická analýza by měla taky poskytnout rozhraní, které usnadní nalezení konkrétních chyb a v ideálním případě taky poskytne možnosti, jak chyby odstranit. Její přínos v odstraňování nedostatků je: Minimalizuje riziko "přehlédnutí"problému (které je při manuální kontrole vysoké) Výrazně šetří čas Obsahová analýza může automaticky vyhodnotit jen několik typických chyb v obsahu. Její hlavní přínos je ve vhodné agregaci dat takovým způsobem, aby uživatel mohl rychle analyzovat mnoho stránek najednou a následně tak detekoval nedostatky v obsahu. Vhodná úprava obsahu pomůže v optimalizaci pro vyhledávače. Přínosy obsahové analýzy: Výrazně šetří čas Minimalizuje riziko "přehlédnutí"problému 41

42 3. Analýza a požadavky na aplikaci 3.1 Cíle aplikace Požadavky z uživatelského hlediska Bezproblémový a rychlý přístup k aplikaci s pomocí jakéhokoliv zařízení, které má přístup k internetu Poskytnutí nejvyšší kvality analýz Důraz na množství ušetřeného času Jednoduché a intuitivní ovládání Možnost sdílet přístup k analýzám i dalším lidem Bezplatný systém, případně za přijatelnou cenu Cíle na základě hodnotících kritérií Na základě rešerší můžeme lépe stanovit cíle, které by měla aplikace splňovat, aby se dokázala prosadit vůči existující konkurenci: Kritérium Hodnota Typ aplikace Webová Dostupné operační systémy Všechny (s dostupným prohlížečem) Kvalita obsahové analýzy 1 Kvalita technické analýzy 1 Schopnost zpracování vysokého objemu dat Velmi vysoká Rychlost zpracování analýzy Vysoká Chybovost aplikace Nízká User experience 1 Správa uživatelů Musí nabízet možnosti sdílení přístupu k analýzám, včetně nastavení uživatelských pravomocí Cena Přijatelná, ideálně nižší než má konkurence Tabulka 3.1: Cílové hodnotící kritéria Byznys požadavky Platební systém bude vytvořený na základě měsíčních plateb, v kombinaci s Pay Per Use 15 systémem. 15 Výše platby se odvíjí od množství využívaných služeb, výkonu apod. 42

43 3.2. Funkční požadavky U neplatících uživatelů bude kladen důraz na maximalizaci konverzních schopností aplikace v podobě objednání placeného tarifu. Další typy konverzí: Registrace uživatele, provedení bezplatné analýzy webu. Důraz na spokojenost zákazníků (platících i neplatících) Cílové skupiny Amatérští tvůrci webů Cíl: Informování o službě dalším potenciálním zájemcům Majitelé malých firemních webů Cíl: Informování o službě dalším potenciálním zájemcům Malé firmy a živnostníci Cíl: Objednávka základního tarifu Středně velké firmy: Agentury,... Cíl: Objednávka vyššího tarifu Velké firmy: Rozsáhlé e-shopy, velké agentury, zpravodajské weby,.. Cíl: Objednávka nejvyššího tarifu 3.2 Funkční požadavky Aplikace se bude skládat ze 3 hlavních funkčních celků Technická analýza (více v sekci 3.2.1) Obsahová analýza Analýza interního prolinkování Aplikace umožní přístup k datům získaným z kontrolovaného webu i během analýzy Budou existovat 3 typy uživatelských účtů Owner - majitel účtu může změnit objednaný tarif, má plný přístup k aplikaci a může spravovat uživatelské účty. Admin - má plný přístup k aplikaci, ale nemůže zrušit, nebo změnit tarif. Může spravovat uživatelské účty, kromě typu owner. User - má přístup k analýzám, ale nemůže je žádným způsobem upravovat. 43

44 3. Analýza a požadavky na aplikaci Požadavky pro technickou analýzu Všechny technické nedostatky budou vyhodnoceny automaticky Každý nedostatek bude obsahovat podrobnosti problému, včetně návrhů na jeho řešení Každý nedostatek může patřit do kategorií: SEO - Nedostatek omezující optimalizaci pro vyhledávače Přístupnost - Problém v přístupnosti stránky Technická - Jiný technický nedostatek Každý nedostatek bude patřit do jedné z 3 kategorií: Chyba Upozornění Informace Ukázka funkcí pro technické nedostatky Funkce Kategorie Status Dlouhý titulek SEO Upozornění Duplicitní stránky SEO Chyba Zacyklené přesměrování 2 a více SEO, Technická Chyba stránek Neexistující (404) stránka SEO, Technická Chyba Stránka obsahuje odkaz s nerelevantním SEO, Přístupnost Upozornění anchor textem Na stránce se nacházejí obrázky s SEO, Přístupnost Upozornění nedefinovaným atributem alt Stránky se zakázanou indexací v SEO Informace meta robots Na stránce se nachází prvky technologie SEO, Přístup- Informace FLASH nost, Technická Na stránku vedou odkazy s prázdným SEO, Přístupnost Upozornění nebo nerelevantním anchor tex- tem Na stránce se nachází tag <blink> Přístupnost Chyba Tabulka 3.2: Příklady technických nedostatků. Kompletní přehled se nachází v příloze B. 44

45 3.3. Nefunkční požadavky Požadavky pro obsahovou analýzu Výsledky bude možné agregovat dle následujících obsahových prvků: U (X)HTML stránek: Tag title Tag meta, s atributem name="description" První Tag h1. U obrázků: Atribut alt v tagu img Požadavky pro analýzu interního prolinkování Odkazy bude možné agregovat dle anchor textů O každém odkazu budou dostupné informace: Anchor text 100 znaků před odkazem 100 znaků za odkazem Jestli vyhledávače nemají zákaz následování odkazu Jestli odkaz vede na interní nebo externí stránku Pořadí odkazu 3.3 Nefunkční požadavky Aplikace bude vyvíjená na platformě Google App Engine 16 Uživatelé budou pro přístup k aplikaci využívat Google účet 3.4 Omezení Omezení aplikace: Navrhovaný typ služeb není velmi známý Aplikace konkuruje i bezplatným nástrojům Úzká cílová skupina Vzhledem k rozsahu problematiky, se práce nezabývá:

46 3. Analýza a požadavky na aplikaci Návrhem a realizací uživatelského rozhraní Implementací všech funkčních požadavků. Implementace bude zaměřená především na stěžejní problémy, jako je sběr dat a jejich vhodné zpracování. Nezabýváme se byznys procesy, jako například stanovení cen pro tarifní pásma, marketingová strategie apod. 46

47 Kapitola 4 Návrh Jak jsme již uvedli v úvodu, návrhu programové části jsme původně neplánovali věnovat velkou pozornost. Aplikace se do značné míry skládá z obecně známých problémů. Problematice web crawlerů se již taky zabývalo mnoho výzkumních prací (např. (? ), (? )). Bohužel, v tomto ohledu jsme naše počínání podcenili. Navrhli jsme architekturu web crawlera, včetně modelu analytických tříd a bez hlubší analýzy návrhu jsme začali s implementací. Výsledkem testování implementace byla velmi vysoká zátěž na zápisy a čtení dat z databáze. Proto bylo potřeba změnit návrh crawlera, což mělo za následek kompletní přepracování implementační části aplikace. Ještě před návrhem samotného crawlera se na architekturu aplikace podíváme ze vzdálenější perspektivy. Následně se zaměříme na několik návrhů modelů analytických tříd a crawlera, od počátečního (neefektivního) až po výsledný návrh. 4.1 High-level architektura Aplikaci bude tvořit: Prezentační vrstva - GUI Aplikační vrstva - Vyhledávací robot a tzv. procesor Datová vrstva - Databáze a konfigurační soubory 47

48 4. Návrh Jednotlivé vztahy mezi funkčními celky aplikace naznačuje obrázek 4.1: Obrázek 4.1: High-level architektura aplikace Funkční celek nazvaný Procesor zajišťuje zejména součinnost GUI s datovou vrstvou. Má na starosti veškerou logiku, kromě dolování a následného ukládání dat z webových dokumentů. To zajistí vyhledávací robot, včetně syntaktické analýzy. Konfigurační soubory v datové vrstvě slouží k prvotní inicializaci databáze. Potom už do fungování aplikace nezasahují. Uživatelské rozhraní zajišťuje komunikaci uživatele s ostatními částmi aplikace. 48

49 4.2. Prvotní návrh 4.2 Prvotní návrh Návrh analytických tříd Obrázek 4.2: Diagram analytických tříd Slovní popis analytických tříd User - Třída obsahující data o uživatelích Project - Projektová data, včetně nastavení projektů UrlData - Třída uchovávající data o jednotlivých URL adresách, entity tvoří uzly link grafu4.3. Link - Třída uchovávající data o jednotlivých odkazech, entity tvoří hrany link grafu. Recommend - Seznam možných doporučení 49

50 4. Návrh Queue - Třída uchovává data o aktuálním stavu fronty url adres určených pro robota Obrázek 4.3: Ukázka link grafu: Uzly tvoří URL adresy, resp. entity třídy UrlData. Hrany jsou odkazy, resp. entity třídy Link Návrh řešení sběru dat Fronta URL adres, které čekají na zpracování, je reprezentována v podobě entit, v analytické třídě Queue. V 1. kroku se do fronty uloží počáteční URL adresa, kterou definoval uživatel. Tento krok kvůli přehlednosti zanedbáme. Předpokládejme, že ve frontě se již alespoň jedna URL nachází. Zpracování entity z Queue je následovné: 50

51 4.2. Prvotní návrh Obrázek 4.4: Activity diagram životního cyklu entity z Queue. Aktivitu Nalezení nových odkazů pro Queue pro přehlednost uvedeme do dalšího acitivty diagramu: Obrázek 4.5: Activity diagram pro nalezení nových odkazů pro Queue. 51

52 4. Návrh Modré znaky R, resp. W na obrázcích 4.4 a 4.5 charakterizují Read, resp. Write 17 databázové operace. Znak S charakterizuje tzv. Small operaci. Výše poplatků za využívání Google App Engine závisí do znační míry od počtu databázových operací. Zejména od Write operací, které jsou nejdražší. Z toho důvodu je potřeba navrhnout aplikaci takovým způsobem, aby byl počet databázových operací co nejnižší. Zároveň je potřeba dbát na to, aby se značně nezvýšila náročnost na výpočetní výkon a přitom se zachovala taky požadovaná funkčnost Rozbor návrhu Počet databázových operací 18 (Read, Write) bude pro jednotlivé složky návrhu: Výběr 1. volné URL z Queue = 1*R Nastavit aktuální entitu na "zpracovávám" = 1*W Vložení entity do UrlData = 2*W + 2*<iv 19 -UrlData> Vložení entit do Link = (2*W+2*<iv-UrlData>)*<poc-odkazu> Nachází se URL odkazu v Queue? = (R+R)*<poc-odkazu> Nachází se URL odkazu v UrlData? = (R+R)*<poc-odkazu> Vlož seznam do Queue = 2*W*<poc-prvku-seznamu> Odstranění URL z Queue = 2*W Zanedbali jsme operace Small, protože je jich velmi nízký počet a jejich využívání je výrazně levnější, než Read a Write operace. Počty databázových operací jsme odvodili z definicí na požadavky jednotlivých operací V Google App Engine terminologii, je i odstranění entity považováno za součet Write operací, jelikož si vyžadují úpravy v databázi. 18 V tomto případě o počtu databázových operací, uvádíme počty pro jednu URL. 19 Konstanta obsahující iv, charakterizuje počet indexovatelných položek. Podrobnosti o indexovatelných položkách:

53 4.3. Zefektivnění návrhu Vkládání každého odkazu jako novou entitu, je extrémně drahá operace. Příklad: Potřebujeme analyzovat web, který má stránek, přičemž na každé stránce se nachází v průměru 100 odkazů. Použijeme 3 indexovatelné položky pro odkazy (příchozí URL, odchozí URL, anchor text) a 5 indexovatelných položek pro URL adresy. Počet Write operací do analytické třídy Link bude tedy: (2*W+2*3) * * 100 = W. Udržování aktuálního stavu fronty v databázi je taky náročné na počet operací. Počet operací spravující Queue následovný: (1R+1W+2W) * R*(10 000*100) + 2W* = R W. Náročné je především neustálé čtení z databáze kvůli každému odkazu. Poslední databázové operace obsluhují vkládání URL do UrlData a kontrolu existence URL každého odkazu v UrlData: (2W+2*5) * R*(10 000*100) = W R. Celkový počet operací: W + ( R W) + ( W R) = W R. Dle aktuálních finančních sazeb 21 za databázové operace, je cena 12$ + (1,47$ + 0,05$) + (0,12$ + 1,4$) = 15,04$. To je velmi vysoká cena a nelze tak splnit cíl cenové přijatelnosti (3.1.2) Shrnutí návrhu Současný návrh je extrémně náročný na počet databázových operací. Při optimalizaci se zaměřime především na: Ukládání odkazových dat - nelze každý odkaz ukládat do nové entity Zjednodušení správy fronty za pomoci databáze Minimalizaci čtení odkazů, které vedou na stejné URL adresy. 4.3 Zefektivnění návrhu Každý odkaz nebudeme ukládat do nové entity a třídu Link odstraníme. Data o odkazech přidáme do UrlData, kde každá entita, resp. URL adresa bude obsahovat seznam odchozích odkazů, včetně doplňkových informací (anchor text apod.). Další úsporu počtu databázových operací získáme převedením správy fronty na UrlData a úkoly, resp. Tasks. Každý Task již nebude zpracovávat první volnou URL ve frontě. Task dostane informaci o URL, kterou má zpracovat při jeho vzniku. To umožňuje zrušit i třídu Queue

54 4. Návrh Obrázek 4.6: Diagram analytických tříd. Obrázek 4.7: Activity diagram jednoho Task procesu. Zpracovávaná URL nevytvoří v UrlData novou entitu, ale aktualizuje již existující. Entity se vytvářejí během zavádění nových úkolů??. Je to z toho důvodu, aby se v databázi nenacházely jenom zpracované URL adresy, ale i ty nezpracované. Protože jinak by nebylo možné zjistit, které URL se nacházejí ve frontě úkolů. 54

55 4.4. Výsledný návrh Obrázek 4.8: Activity diagram pro nalezení nových odkazů pro TaskQueue. Tento návrh výrazně sníží počet databázových operací. Ale ještě stále je kontrolován každý odkaz, jestli se jeho cílová URL nachází v UrlData. Hodně odkazů má přitom duplicitní cílovou URL. V následující sekci 4.4 si představíme návrh, který je v náročnosti na počet databázových operací šetrnější. 4.4 Výsledný návrh Abychom nemuseli neustále kontrolovat duplicitní odkazy, které vedou na stejnou cílovou stránku, můžeme je ukládat do množiny (duplicitní URL budou odstraněny). Jakmile se skončí poslední Task z TaskQueue, zkontrolujeme které URL adresy z množiny se nenacházejí v UrlData. Ty následně přidáme do TaskQueue a inicializujeme je v UrlData. V případě zápisu všech odkazů do množiny ale vzniká problém: Jednu entitu (v tomto případě množinu), lze aktualizovat jenom několikrát za sekundu. 55

56 4. Návrh Aplikace by měla umožňovat i zpracování několika desítek URL za sekundu. To nám umožní využití metody Sharding Counters(? ). Ta spočívá v tom, že nebudeme využívat jenom jednu entitu, ale zátěž rozložíme na větší počet entit (tzv. Shards). Před realizací zápisu do databáze, se náhodně vybere jeden z předem definovaných Shards, resp. množin, do které se nové odkazy přidají (viz. obrázek 4.9). Obrázek 4.9: Ukázka metody Sharding Counters - uložení dat Když budeme potřebovat data ze Sharding Counters načíst, Shards sjednotíme a vytvoříme tak výslednou množinu (viz obrázek 4.10). Obrázek 4.10: Ukázka metody Sharding Counters - načtení dat 56

57 4.4. Výsledný návrh Návrh analytických tříd Diagram analytických tříd (viz. 4.11) se tedy vzhledem k předchozímu návrhu téměř nezměnil. Obrázek 4.11: Výsledný diagram analytických tříd Správu fronty úkolů, tzv. TaskQueue nemůže databáze vůbec ovlivnit. Jednotlivé úkoly o sobě navzájem nevědí. To znamená, že úkol zpracovávající nějakou URL adresu nemá žádnou informaci o tom, jestli se ve frontě nacházejí ještě další úkoly. Taky nezná, jakou URL bude zpracovávat další úkol. V navrženém diagramu analytických tříd se nacházejí jenom informace o celkovém počtu nalezených URL (zpracované URL + URL v TaskQueue). To klade vyšší nároky na složitost implementace TaskQueue. 57

58 4. Návrh Návrh sběru dat Na rozdíl od předchozích návrhů, využijeme pro sběr dat více typů úkolů, které se nacházejí v TaskQueue. Obrázek 4.12: Activity diagram úkolu, který zpracovává URL. Průběh úkolu na zpracování URL (4.12) neslouží na inicializaci dalších úkolů stejného typu. Na to využijeme jiný typ úkolu (4.13), který jsme nazvali TaskControl. 58

59 4.4. Výsledný návrh Obrázek 4.13: Activity diagram úkolu TaskControl. Aby mohl byl úkol TaskControl úspěšně ukončen, musí být předtím zpracovány všechny úkoly na zpracování URL. V případě, že během zpracování URL došlo k nějaké chybě, kterou lze očekávat, je úkol přesunutý až za Task- Control. To zapříčiní, že TaskControl nebude úspěšně ukončen a přesune se na konec fronty. 59