University of Business and Technology in Kosovo UBT Knowledge Center

Theses and Dissertations Student Work

Summer 6-2010

The Google search engine

Ganimete Perçuku

Follow this and additional works at: https://knowledgecenter.ubt-uni.net/etd

Part of the Computer Sciences Commons Faculty of Computer Sciences and Engineering

The Google search engine (Bachelor Degree)

Ganimete Perçuku – Hasani

June, 2010 Prishtinë Faculty of Computer Sciences and Engineering

Bachelor Degree Academic Year 2008 – 2009

Student: Ganimete Perçuku – Hasani

The Google search engine

Supervisor: Dr. Bekim Gashi

09/06/2010

This thesis is submitted in partial fulfillment of the requirements for a Bachelor Degree

Abstrakt

Përgjithësisht makina kërkuese Google paraqitet si sistemi i kompjuterëve të projektuar për kërkimin e informatave në ueb. Google mundohet t’i kuptojë kërkesat e njerëzve në mënyrë “njerëzore”, dhe t’iu kthej atyre përgjigjen në formën të qartë. Por, ky synim nuk është as afër ideales dhe realizimi i tij sa vjen e vështirësohet me zgjerimin eksponencial që sot po përjeton ueb-i. Google, paraqitet duke ngërthyer në vetvete shqyrtimin e pjesëve që e përbëjnë, atyre në të cilat sistemi mbështetet, dhe rrethinave tjera që i mundësojnë sistemit të funksionojë pa probleme apo të përtërihet lehtë nga ndonjë dështim eventual. Procesi i grumbullimit të të dhënave ne Google dhe paraqitja e tyre në rezultatet e kërkimit ngërthen në vete regjistrimin e të dhënave nga ueb-faqe të ndryshme dhe vendosjen e tyre në rezervuarin e sistemit, përkatësisht në bazën e të dhënave ku edhe realizohen pyetësorët që kthejnë rezultatet e radhitura në mënyrën e caktuar nga algoritmi i Google. Mbledhja, sistemimi dhe paraqitja e rezultateve nga Google paraqet boshtin e shtjellimit në këtë punim. Me rritjen e Google, përkatësisht, me fuqizimin e Google në ueb, paraqiten edhe problemet e përshtatshmërisë dhe përputhshmërisë së sistemit me teknologjitë aktuale që disponon tregu. Sikur që çdo sistem i veçantë, kërkon zgjidhje të veçantë, edhe Google ka sistemin e saj shumë specifik për funksionalizimin e pjesëve të saj në mënyrat, të cilat janë treguar mjaft optimale, sidomos financiarisht. Përfundimisht, pjesë e këtij punimi janë edhe mashtrimet që i bëhen Google duke shfrytëzuar dobësitë e algoritmit për radhitjen e rezultateve, si dhe studimi i mundësive dhe ideve për zhvillimin e mëtutjeshëm dhe avancimin e teknologjive të kërkimit në ueb.

Fjalët kyçe: Google makina kërkuese, Google klaster arkitektura, PageRank, ueb semantike Abstract

Generally, Google search machine is presented as a projected system of computers that handles the search requests for information on web. Google tries to understand human search requests in a “human” way, as well as it tries to return search results in the most possible clear format. But, this goal is not so close to the ideal case, and its realization is becoming more difficult when we take in consideration webs exponential enlargement.

The process of collecting data and their representation in search results comprises data registration from various web pages and saving of those data into system reservoirs, respectively in the databases, that are used to run queries. These queries returns search results to the users, ordered in the way that is defined by Google algorithm. Data collecting, systematization and result representation from Google engine will be in the center of explication on this paper. Analysis of mega-systems, such as Google, is constructed by inspecting particles from which system is composed, those one in which system lays on, as well as environments that make system work without encountering problems or recover the system from eventual failures.

While web is enlarging, Google’s taking a new role in the web. But, this is also followed by a range of problems, starting from system compatibility with current technologies. As all specific systems does, also this issue needs a specific solution, so Google has its own system for turning its system components work in a particular way, which has been seen more efficient and financially optimal. Finally, in this paper are discussed also the ‘work around’ or ‘cheats’ on Google, through using algorithm weaknesses, which orders the search result. Advanced technologies for web searching are discussed at the very end of this paper.

Keywords: Google search engine, Google cluster architecture, PageRank, web semantics Falënderime

Deshiroj të falënderoj në rend të parë familjen time, babain Mexhitin, nënen Nazlien, motrat, vëllaun, posaqërisht vajzën Ninen si dhe bashkëshortin tim Islamin, për ndihmen dhe përkrahjen e pakursyer që më dhanë gjatë studimeve.

Falënderime të veçanta kam edhe për familjen e gjerë, te cilët me interesimin e tyre, më dhanë shtytje të fortë, që t’i perfundoj studimet me sukses.

Deshiroj t’i falënderoj, gjithashtu shokët e shoqet për përkrahjen që më kanë dhënë, dhe për kujtimet e mira nga koha e studimeve.

Një falënderim të posaçëm kam për profesorin Dr. Bekim Gashin, në radhë të parë për durimin e tij, mbështetjen dhe ndihmën e pakursyer që më ka dhënë gjatë punimit të diplomës. 1. Hyrja dhe motivimi 1.1 Hyrje

Përmbajtja

1 HYRJA DHE MOTIVIMI...... 1

1.1 Hyrje...... 1

1.2 Motivimi...... 2

1.3 Përshkrimi i problemit dhe objektivat ...... 2

2 PARAQITJA E GOOGLE NË UEB ...... 3

2.1 Zhvillimi i makinave kërkuese ...... 3

3 ARKITEKTURA E GOOGLE MAKINËS KËRKUESE ...... 6

3.1 Arkitektura e klasterëve të Google ...... 6

3.2 Sistemi i skedarëve të Google ...... 8

3.3 Struktura e të dhënave...... 13

4 ORGANIZIMI I TË DHËNAVE NË GOOGLE...... 15

4.1 Struktura funksionale e komponentëve të klasterëve të Google ...... 15

4.2 Mbledhja e informative në ueb ...... 18

4.3 Indeksimi i uebit dhe MapReduce modeli...... 21

5 REZULTATET E KËRKIMIT...... 25

5.1 Analiza e pyetësorëve dhe përpilimi i rezultateve preliminare të kërkimit ...... 25

5.2 Renditja e rezultateve të kërkimit përmes algoritmit PageRank...... 27

5.3 Efektshmëria e sistemit...... 31

5.4 Google dhe makinat tjera kërkuese ...... 32

6 SI TË MASHTROHET GOOGLE?...... 35

6.1 Teknikat për manipulimin e rezultateve të kërkimit të Google makinës kërkuese ...... 35

6.2 Teknikat e makinave kërkuese për mbrojtje kundër mashtrimeve...... 36

1 1. Hyrja dhe motivimi 1.1 Hyrje

7 E ARDHMJA E MAKINAVE KËRKUESE ...... 38

7.1 Zhvillimi i vetive semantike te makinat kërkuese ...... 38

8 PËRFUNDIMI ...... 41 REFERENCAT ...... 44

Shtesat

Listae figurave

Figura 1: Grafi i rritjes së numrit të ueb faqeve ...... 4 Figura 2: Klaster arkitektura (stendat) e Google ...... 6 Figura 3: Arkitektura e sistemit të skedarëve të Google ...... 9 Figura 4: Kontrolli i shkrimit dhe rrjedha e të dhënave ...... 11 Figura 5: Një pjesë e tabelës të BigTable, që ruan të dhënat për ueb faqe13 Figura 6: Arkitetktura e nivelit të lartë të Google makinës kërkuese ...... 15 Figura 7: Indekset e avancuara dhe të përmbysura dhe leksikoni ...... 17 Figura 8: Rrjedha e një crawler-i të thjeshtë sekuencial...... 18 Figura 9: Një faqe e bazuar në HTML dhe struktura përkatëse ...... 21 Figura 10: Pseudokodi i funksionit map dhe reduce ...... 22 Figura 11: Pamja e përgjithshme e ekzekutimit të funksionit map dhe reduce...... 23 Figura 12: Relacioni në mes tri dokumenteve të lincuara ndërmjet veti ...... 27 Figura 13: Diagrami i tri dokumenteve me vlerat e rangut sipas algoritmit...... 28 Figura 14: Rrjedha e një manifestimi të bazuar në invencionin ...... 30 Figura 15: Rezultatet e kërkimit të kthyera nga Google për fjalët kyçe bill clinton...... 32 Figura 16: Rezultatet e kërkimit për fjalën kyçe universit, të kthyera nga Google (majtas) dhe Altavista(djathtas)...... 33 Figura 17: Rezultatet e kërkimit për fjalën kyçe qeveria, të kthyera nga Yahoo (lartë-majtas), Google (lartë-djathtas), MSN Search (poshtë-majtas) dhe WebSearch (poshtë-djathtas)...... 34 Figura 18: Modeli i Markov-it për nxjerrjen e informatave nga një punim hulumtues...... 39

Lista e tabelave

Tabela 1: Makinat kërkuese...... 4

2 1. Hyrja dhe motivimi 1.1 Hyrje

Lista e shkurtesave

ASCII American Standard Code for Information Interchange CPU Central Processing Unit FTP File Transfer Protocol GFS Google File System HMM Hidden Markov Model HTML HyperText Markup Language HTTP HyperText Transfer Protocol NCD Normalized Compression Distance NID Normalized Information Distance NGD Normalized Google Distance SEO Search Engine Optimization SSG Sistemi i Skedarëve të Google URL Uniform Resource Locator WWW World Wide Web XML eXtended Markup Language

3 1. Hyrja dhe motivimi 1.1 Hyrje

Kapitulli 1

1 Hyrja dhe motivimi

1.1 Hyrje

Informacioni dhe shpejtësia e arritjes deri te ai, janë bërë esenca e zgjidhjeve, thelbi i çdo ekonomie kapitaliste, baza e çdo kërkimi shkencor ose thjeshtë thënë janë bërë pjesë e përditshmërisë dhe e suksesit të shoqerisë njerëzore.

Me rreth 18.8 miliardë [1] ueb faqe në internet, veshtire mund të thuhet se do të gjenim atë që dëshirojmë pa na ndihmuar ndokush, sikur që nuk do të mund të hulumtonim për një libër të caktuar në një bibliotekë që ka një fond prej miliarda ekzemplarësh, pa ndihmen e një profesionisti që punon aty. Aq më tepër, nëse ato libra nuk janë të sistemuara në mënyrë logjike sikur që është rasti me ueb faqet në internet dhe, të mos përmendim faktin që dyfishimi i numrit të ueb faqeve është çështje vitesh e jo dekadash. Jo shumë vite prapa, ky dyfishim ishte çeshtje muajsh [2, 3]. Sigurisht që epilogu i çdo kërkimi në ueb do të ishte një bredhje poshtë-lartë, me gjasa jashtëzakonisht të vogla për të arritur deri te ndonjë rezultat i kënaqshëm. Në mënyrë të natyrshme lind nevoja për një ‘qender globale të informimit’ lidhur me atë se çfarë gjendet në këtë rezervuar gjigant të informatave. Dhe kjo nuk përfundon këtu. Sfidë e vërtetë është përcaktimi i objektivave që do t’i ketë kjo ‘qenër informuese’, duke filluar nga ato të kërkimit dhe mbledhjes së materialit e deri te paraqitja e kuptueshme e rezultateve dhe shpejtësia e kthimit të rezultatit. Google dhe shumë makina kërkuese i qëndrojnë përballë këtyre problemeve me fanatizëm i qëndrojnë besnik detyrimeve të tyre si qendra informuese dhe drejtuese për popullatën që ka qasje në internet e që po rritet çdo ditë e më shumë.

Kërkimi i materialeve duke u bazuar në strukturën e lidhjeve në mes ueb faqeve paraqitet si mjaft sfidues. Nga kjo edhe rrjedh nevoja për dizajnimin e robotëve softuerik, për të kursyer njerëzit dhe natyrisht edhe për efikasitet më të lartë (nuk lodhen, nuk kanë nevojë të ushqehen, nuk vonohen në punë, nuk hidhërohen dhe nuk japin dorëheqje në momente kyçe).

Analiza e materialeve paraqitet si korrektues ‘gramatikor’ i ueb faqeve, ashtu që i përkthen materialet në forma të standardizuara, por puna e saj nuk përfundon me kaq, jo së paku për Google. Google bën edhe analizen e hollësishme të lidhjeve ndërmjet ueb faqeve, veti kjo që do të ndikoje në formulën për radhitjen e rezultateve [2].

Për të gjetur, gjegjësisht për të kërkuar diçka të veçantë, njerëzit janë të prirur të japin të ashtuquajturat ‘fjalë kyçe’ (nga ang. keywords) që pamohueshmërisht lidhen në një mënyrë a tjetrën me atë që kërkojmë. Mirëpo, shumë makina kërkuese rrallëherë i paraqesin ‘rezultatet e pritura’ në rend të parë. Dhe kush do të kishte durim që të shfletonte mijëra faqe për të arritur deri te rezultati i dëshiruar? — Jo së paku një qenie njerëzore. Kerkimet shkencore [4] kanë bërë të ditur se njerëzit janë të prirur të shikojnë vetëm 10-20 rezultatet e para, para se të mërziten. Fatmirësisht, një qasje më të mirë në këtë drejtim e ofron Google makina kërkuese.

4 1. Hyrja dhe motivimi 1.1 Hyrje

1.2 Motivimi

Nevoja për drejtimin e shfrytëzuesve drejt lokacioneve në ueb, që përmbajnë informacionet që shfrytezuesit i kërkojnë, imponoi paraqitjen dhe përsosjen e makinave kërkuese në internet. Algoritmet që tanimë përdoren nga këto makina kërkuese, për të mbledhur, sistemuar të dhënat si dhe për të renditur rezultatet, përbën një fushë mjaft interesante për studim, dhe mjaft tërheqëse për eksperimentim.

Arsyeja kryesore për të marr në studim këtë teknologji të uebit, rrodhi si rezultatet i rritjes enorme që po pëson uebi sot, dhe nevojës për sistemim të informatave të paraqitura në ueb.

1.3 Përshkrimi i problemit dhe objektivat

Funksionimi i makinës kërkuese Google, duke përfshirë këtu grumbullimin e informatave nga uebi, deponimin e tyre nepër kompjuterët e klasterëve të Google, të dizajnuar me kreativitet të madh, përshkrimi i funksionimit të modeleve klaster, si dhe analiza e sistemit specifik të skedarëve që Google shfrytëzon për të ruajtur të dhënat, përbëjnë vetem njëren nga objektivat e këtij punimi.

Vend të veçantë në këtë punim, zë studimi i formave dhe modaliteteve, të cilat përdoren si për sistemimin e të dhënave të mbledhura në ueb dhe indeksimin e këtyre të dhënave, ashtu edhe për paraqitjen e rezultateve të kërkimit, të cilat përzgjidhen me kujdes, përmes algoritmit që ka zhvilluar Google.

Në përmbushje të synimit, për përshkrimin sa më të thuktë të funksionimit të Google makines kërkuese, si objektiv është paraparë edhe krahasimi i efektshmërisë së Google makinës kërkuese kundruall makinave tjera kërkuese, sikurse edhe shqyrtimi i modeleve dhe ideve të paraqitura për avancimin e efektshmërisë së makinave kërkuese në të ardhmen.

5 2. Paraqitja e Google ne ueb 2.1 Zhvillimi i makinave kerkuese

Kapitulli 2

2 Paraqitja e Google në ueb

2.1 Zhvillimi i makinave kërkuese

Kërkimi për një dokument a informatë në mënyrë elektronike nuk ka lindur me lindjen e uebit, por para saj. Në të 90-tat e hershme ekzistonin hapësirat për diskutime e shkëmbime të informatave apo siç quhen në anglisht bulletin boards, ku universitetet e ndryshme të ndërlidhura ndërmjet veti ofronin dhomat e bashkëbisedimit (ang. Chat) dhe shkembimin e punimeve shkencore në mes profesorëve, pastaj depot elektronike të departamentit amerikan të mbrojtjes që shërbenin për shkëmbimin e skedarëve dhe ruajtjen e bartjen e të dhënave në mes pikave të atëhershme strategjike për deponim elektronik. Të gjitha këto shërbime realizoheshin përmes shërbimeve të atëhershme komunikuese si telnet-i, posta elektronike (ang. e-mail), usenet grupet e FTP faqet. Transferi i këtyre skedarëve ishte detyra e shërbimit FTP, por, leximi apo ekzekutimi i tyre ishte ngushtë i lidhur me pajisjen me softuer që përkrahte tipin specifik të atij skedari (shih tabelen 1).

Makina Paraqitja Projektuesi Profesioni i Mjeshtëria kërkuese projektuesit Archie 1990 Alan Emtage Student - Arkivimi i FTP skedarëve Universiteti McGill Gopher 1991 Mark McCahill Student – Arkivimi i FTP skedarëve Universiteti i Minnesota-s WWW Worm 1993 Martin Koster Ueb direktoriumi i parë

WebCrawler 1994 Brian Pinkerton Student - Indeksimi i tekstit në ueb faqe Universiteti i Washington-it Yahoo! 1994 David Filo & Student - Direktorium Jerry Jang Universiteti i Stanfordit Lycos 1994 Michael Maldin Student - Direktorium Universiteti i Carnegie Mellon MetaCrawler 1995 Eric Selburg & Student - Metakërkuesi i parë Oren Etizioni Universiteti i Washington-it AltaVista 1995 Digital Kërkimi i parë përmes Equipment gjuhës Corp. natyrale dhe operatorëve ‘boolean‘ MSN Search 1998 Microsoft Kërkim dhe direktorium Google 1998 Larry Page & Student - Merret parasysh struktura e Sergey Brin Universiteti I lidhjeve Stanfordit

Tabela 1: Makinat kërkuese 151

6 2. Paraqitja e Google ne ueb 2.1 Zhvillimi i makinave kerkuese

Makina e parë kërkuese që paraqitet në Internet është Archie, më 1990, e dizajnuar nga Alan Emtage, atëbotë student i Universitetit McGill, Montreal, Québec, Kanade. Detyra e Archie-t ishte të indeksonte skedarët e FTP serverëve në rrjetë. Në këtë kohë u paraqit edhe Gopher, apo GopherSpace siç u quajtë sistemi i të gjithë kompjuterëve Gopher që ofrojnë katalogun e FTP qendrave të lidhura në rrjet dhe skedarët qe ato përmbanin [5]. Pas vitit 1993, me paraqitjen e ueb shfletuesit të parë, paraqitet edhe ueb-i (World Wide Web), si një mënyrë universale e leximit të të dhënave, duke lënë qasjen përmes FTP-së vetëm për transfer skedarësh [5].

Zhvillimi i internetit drejt teknologjisë HTML (HyperText Markup Language) bëri të mundur që të gjithë shfrytëzuesit që kanë qasje fizike në internet dhe një shfletues të çfarëdoshem, pa pasur nevojë për ndonjë program shtesë të vizitojnë qendra të ndryshme informative në internet. Ishte e qartë se me paraqitjen e HTML-së një dimension i ri i kërkimit në internet po merrte formë. Makinave kërkuese iu imponua qasja e re që duhet të kishin në internet. Ato tanimë nuk ishin vetëm kërkues të skedarëve por edhe kërkues të informacionit, të vënë përmes HTML-së në formë të materialit tekstual, grafik apo tingullor.

Marr parasysh se kufizimet softuerike/harduerike për komunikim i takonin të kaluarës, shfrytëzuesit e internetit, ku tashmë përfshihen prezantuesit e informatave, si universitet, institucionet, bizneset e të tjerë, dhe vizituesit e tyre apo ueb lundruesit (nga ang. web surfers) filluan të rriten eksponencialisht. Numri i ueb faqeve rritej, shumëfishohej nga viti në vit në mënyre marramendëse [2, 3].

Figura 1: Grafi i rritjes së numrit të ueb faqeve [26]

7 2. Paraqitja e Google në ueb 2.1 Zhvillimi i makinave kërkuese

Numrat e paraqitur në diagramin e sipërm paraqesin sasinë e ueb faqeve që kanë arritur të indeksohen, përderisa kapaciteti i uebit mendohet të jetë 400 deri 500 herë më i madh se vlerat e paraqitura në figurë [6].

Në shtator 1998, Sergey Brin dhe Lawrence Page, studentë në Universitetin e Stanfordit, propozojnë Google, një projekt të tyre për kërkimin e informatave në internet. Ky projekt përfshinte algoritmin për radhitjen e veçantë të rezultateve të kërkimit. Algoritmi PageRank është patentuar në SHBA më 1998 [7]. Ky algoritëm ishte e veçanta më e madhe e Google si makinë kërkuese, dhe arriti që Google ta bënte makinën kërkuese më të shfrytëzueshme në internet.

Sipas statistikave më 2000 [8], një qytetar i rëndomtë i SHBA-ve kalon afërsisht 1 orë e gjysmë gjatë javës duke kërkuar përmes makinave kërkuese, dhe nëse këtu marrim parasysh se përqindja e të gjitha kërkimeve në internet që i takon Google është 43% [9], përllogaritet lehtë, sa i vizituar është Google dhe sa e dobishme do të ishte një reklamë biznesi në këtë ueb faqe.

Me rritjen e frekuentimit, Google fillon me politikat komerciale si Pay-per-click dhe AdWords, të dy këto mundësi për reklamim, nga të cilat Google korr një shumë të jashtëzakonshme parash.

8 3. Arkitektura e Google makinës kërkuese 3.1 Arkitektura e klasterëve të Google

Kapitulli 3

3 Arkitektura e Google makinës kërkuese

3.1 Arkitektura e klasterëve të Google

Google posedon një arkitekturë tërësisht jokonvencionale sa i përket strukturës së sistemit harduerik. Për t’i ikur shpenzimeve të mëdha për blerjen e serverëve të sofistikuar (ang. high-end servers), të cilët posedojnë fuqi të madhe të përpunimit të të dhënave, zënë pak hapësirë e janë të thjeshtë për tu menaxhuar, Google zgjodhi një qasje tjetër e cila doli të jetë mjaft efektive dhe mjaft e volitshme financiarisht [2]. Ideja është që të blihen shumë kompjuterë të klasit të mesëm, të cilët kushtojnë lirë, e që me një ndërlidhje të duhur softuerike do të mundësohej përpunimi paralel, ku si rezultat do të kishim performancën konkurruese me serverët e sofistikuar, të cilët përdoren nga rivalët e pasur [2].

Megjithatë, shumë kompjuterë, përveç që kërkojnë një sistem operativ të veçantë dhe të distribuueshëm, për të siguruar përpunimin paralel të të dhënave në të gjithë kompjuterët, kërkojnë edhe hapësirë të mjaftueshme për vendosje, kapacitet të mjaftueshëm elektrik dhe të ftohjes. Klaster arkitektura e Google lind si zgjidhje mjaft e mirë dhe ajo bëhet njëra nga shumë shtyllat të cilat e bëjnë Google të veçohet nga sistemet tjera në pothuaj të gjitha aspektet. Klaster arkitektura në esencë paraqet vendosjen në një hapësirë të përbashkët dhe jo shumë të madhe, të një sasie të konsiderueshme të kompjuterëve të tipit x86 dhe sigurimin e bashkëveprimit mes tyre [9].

Një grumbull i tillë i kompjuterëve të Google, apo një stendë me kompjuterë, mund të vendoset në një hapsire komforte.

Figura 2: Klaster arkitektura (stendat) e Google [25]

9 3. Arkitektura e Google makinës kërkuese 3.1 Arkitektura e klasterëve të Google

Kjo ka bërë që Google të investoj në krijimin e shumë stendave të kompjuterëve dhe t’i distribuoj ato në shumë vende të botës, ashtu që sistemi si tërësi të mos varet vetëm nga një qendër e përpunimit të të dhënave dhe e reagimit ndaj kërkesave [9]. Stenda të këtilla janë të vendosura në shumë qendra botërore dhe në rast të dështimeve fatale të ndonjërës nga to, ndërlidhja e sistemit përmes rrjetës globale i mundëson Google që të rikuperohet pothuaj pa u vërejtur fare [9].

Stendat e Google klaster arkitekturës përbëhen prej 40 deri 80 kompjuterë të tipit x86. Gjatë projektimit të stendave i kushtohet kujdes diferencës në fuqi në mes kompjuterëve, ashtu që ajo të mos jetë shumë e dallueshme e në dobi të balancimit të ngarkesës në mes pjesëve. Kështu që, nëpër kompjuterët e vendosur në stenda mund të hasim lloje të ndryshme procesorësh që këta kompjuterë përmbajnë, por diferenca e tyre në kuptim të fuqisë përpunuese nuk është e madhe [10].

Në stendë ekziston edhe një ndërmjetës për balancimin e ngarkesës, i cili vepron menjëherë pasi që të pranohet kërkesa, duke i ndarë punët që duhet kryer në mënyrë të barabartë mes kompjuterëve në stendë. Ky ndërmjetësues ka natyrë harduerike [10]. Në këtë mënyrë fitohet edhe paralelizmi i një shkalle të lartë të përpunimit të të dhënave por, edhe sigurohet që në rast të dështimit të ndonjë komponenti në stendë (p.sh. hard disku i ndonjërit nga kompjuterët e stendës), sistemi të reagojë shpejt duke ia ndarë atë detyrë ndonjërës nga makinat tjera në kuadër të stendës.

Shkalla e amortizimit të këtij sistemi, përkatësisht dallimi në vjetërsi i komponentëve në këto stenda vlerësohet të jetë jo mbi tre vjeçar pasi që vendosja e disa komponentëve të kompjuterëve në të njëjtën stendë çfarë janë, procesorët, e që kanë dallim në kohë të prodhimit njëri nga tjetri më shumë se 3 vjet, do të shkaktonte zhbalancimin e fuqisë në stendë, pasi siç e dimë fuqia e përpunimit të procesorëve të sotëm vetëm sa po vjen e rritet, dhe kjo do të ndërlikonte punën e ndërmjetësuesit për balancimin e ngarkesës në stendë, dhe si rezultat do të kishim vonesën e reagimit të sistemit [10]. Ndërmjetësuesi i balancimit të ngarkesës me pranimin e një kërkesë e cila po e zëmë do të kërkonte 10 miliardë operacione procesorike, do ta ndante përpunimin në, të themi 10 procesorë me fuqi përpunimi 1 GHz (1 miliardë operacione për sekondë), në mënyrë që i gjithë procesi të përfundojë për një sekondë. Si rezultat do të kishim reagimin linear dhe të njëkohshëm të të gjithë procesorëve. Por nëse njëri nga këta procesorë nuk ka fuqi 1 GHz, por ta zëmë vetëm 500 MHz, atëherë i tërë sistemi do të ishte në pritje të reagimit të këtij procesorit të fundit dhe kjo do të kishte ndikim jo edhe aq të vogël në kohën e përgjithshme të reagimit të sistemit. Nëse në të parën sistemi i përbërë prej 10 procesorëve do të reagonte brenda një sekonde, në të dytën edhe pse 9 procesorët e parë kanë përfunduar punën për një sekondë, i tërë procesi zvarritet edhe për një sekondë tjetër për shkak të procesorit 500 MHz, të cilit do t’i duhen 2 sekonda për ta përfunduar sasinë e njëjtë të operacioneve. Prandaj, më e dobishme është të kemi serverë me konfigurim të ngjashëm sesa të krijojmë një lloj të dytë ndërmjetësuesi të balancimit të ngarkesës por kësaj here në nivelin softuerik, në mënyrë që ai të kontrollojë se cila pjesë e stendës çfarë mund të kryejë dhe për sa kohë mund ta kryejë.

Sa i përket komponentëve tjera konfigurimi i serverëve dallon varësisht prej natyrës së punës që ka për të kryer serveri. Në kuadër të stendës së klaster arkitekturës ka serverë të cilët kryejnë punë për të cilat kërkohet gjerësi më e madhe e brezit frekuencor në kanalet që bartin të dhënat për te memoria punuese për të evituar të ashtuquajturin ‘fytin e shishes’ (nga ang. bottleneck), përderisa te disa të tjerë qenësore është hapësira në disk, apo fuqia e përpunimit [10].

10 3. Arkitektura e Google makinës kërkuese 3.1 Arkitektura e klasterëve të Google

Në anën tjetër, të gjithë kompjuterët në stendë janë të lidhur ndërmjet veti përmes arkitekturës Ethernet, me shpejtësi të bartjes 100 Mbps. Ethernet switch-i që ndërlidh serverët brenda stendës ka një apo dy lidhje me gigabit switch-in që ndërlidh stendat ndërmjet veti [10].

Klaster arkitektura e Google, ka bërë atë që edhe pritej. Falë saj Google gëzon përparësi ndaj rivalëve që paguajnë rreth 3 herë më shtrenjtë për efektshmëri të njëjtë. Kjo del nga një studim i bërë nga inxhinierët e Google në [10], sipas të cilit në fund të 2002 një stendë me 176 CPU 2- GHz të Xeon-it, 176 GB RAM dhe 7 TB (terabajt) hapësirë në disk kushtonte rreth 278,000 dollarë amerikanë, përderisa një konfiguracion i serverit të sofistikuar me 8 procesorë 2-GHz të Xeon-it, 64 GB RAM dhe 8 TB hapësirë disku mund të blihej për rreth 758,000 dollarë amerikanë. Nga ky përshkrim shihet që jo vetëm financiarisht zgjidhja e Google është më e mirë, por ajo ka 22 herë më shumë fuqi përpunuese dhe rreth 3 herë më shumë hapësirë punuese në RAM, me një disfavor të vogël në hapësirën e diskut.

Google, pasi që filloi me politikat komerciale, ka pasur në posedim rreth 30 stenda me kompjuterë, gjersa tani nuk dihet saktësisht numri i tyre, por vlerësohet të jetë shumë më i madh, ngaqë Google ruan dhjetëra kopje të uebit nëpër kompjuterë [9]. Sipas vlerësimit të Stephen E. Arnold [11], Google posedon rreth 150,000 deri 170,000 serverë dhe është zgjeruar në më se 60 qendra të përpunimit të të dhënave nëpër botë.

Përparësi e veçantë e kësaj arkitekture, është se ajo është shumë e përshtatshme dhe shumë fleksibile ndaj rritjes së sistemit me kohë. Thjeshtë, me rritjen e vëllimit të uebit, mund të shtohen serverë nëpër stenda dhe me kaq zgjidhet problemi. Pa formula matematikore! Pra, zgjidhja le që është lineare, por është edhe e volitshme financiarisht dhe lejon parashikimin e të ardhmes së sistemit. Natyrisht, ky përfundim rrjedh duke mos marr parasysh problemet e konsumit të energjisë dhe kapacitetet e ftohjes brenda stendës.

3.2 Sistemi i skedarëve të Google

Nevojat praktike në shumë raste nuk përkojnë me teknologjitë standarde, dhe si rezultat ne bëjmë modifikimin e sistemeve tona, duke i përshtatur sistemet me teknologjitë që disponon tregu, ose në raste të rralla, çfarë është Google, projektuesit ndërmarrin projekte të përmasave të mëdha si projektimi i teknologjive të veçanta të cilat përkojnë me sistemet tashmë të zhvilluara në kompani. Google ka dizajnuar sistemin e vet të skedarëve, që ndryshon mjaft nga sistemet e popullarizuara të skedarëve, e të cilat përkrahen nga sistemet moderne operative si Windoës e Linux.

Sistemi i skedarëve të Google SSG (nga ang. GFS — Google File System), parimisht është dizajnuar për përkrahjen e skedarëve të mëdhenj shumë megabajtësh apo shumë gigabajtësh, dhe kjo është njëra prej arsyeve kryesore për projektimin e këtij sistemi, krahas edhe nevoja të tjera si qasja më e shpejtë në të dhëna në disk për kohë minimale, apo sistemi që do të toleronte gabimet [12].

SSG i konsideron të gjitha disqet, përkatësisht pajisjet për regjistrim brenda një stende si një njësi e vetme për ruajtjen e të dhënave, mirëpo ekziston një ndarje logjike e sistemit e cila mundëson funksionimin e një rregullimi të tillë. Sipas kësaj ndarje SSG paraqitet si sistem i nyjave Master dhe Chunkserver-ëve. Ky grumbullim i hapësirave deponuese në një mega depo, na jep idenë për analogjinë me stendat e Google. Tek stendat kishim grumbullimin e shumë makinave të cilat funksionojnë si një sistem unik për përpunimin e të dhënave, derisa te SSG kemi grumbullimin e

11 3. Arkitektura e Google makines kerkuese 3.2 Sistemi i skedareve te Google disqeve të cilat funksionojnë si një hapësirë unike për regjistrimin e të dhënave. Përfundojmë se edhe te SSG, Google ka përdorur një lloj të klaster arkitekturës, por këtu në anen softuerike [12]. Sa i përket operacioneve themelore të sistemeve të skedarëve, SSG posedon pothuaj të gjitha operacionet standarde si create, delete, open, close, read dhe write, por po ashtu përmban operacione shtesë si snapshot dhe record append [12].

SSG përmban një Master dhe shumë Chunkserver-ë, dhe këtij rregullimi mund t’i qasen shumë klientë njëkohësisht. Skema funksionale e këtij sistemi jepet me figurën 3 te mëposhtme, të cilën e kemi huazuar nga [12].

Figura 3: Arkitektura e sistemit të skedarëve te Google [12]

Master-i i SSG bën kontrollin e përgjithshëm të sistemit, por disa nga detyrat e tij i delegohen edhe chunkserver-ëve. Master ka të gjitha informatat për sistemimin e chunkserver-ëve dhe skedarëve në to.

Skedarët bazë ose më mirë thënë pjesët fundamentale të skedareve quhen chunk (shqip: copëzë), dhe janë te madhësise fikse 64 MB, që ë shtë format vërejtshëm më i madh në krahasim me formatet e skedarëve të sistemeve operative Linux e Windows . Secili chunk identifikohet me një numër 64-bitësh, i cili quhet chunk handle. Të drejtën ekskluzive për ndarjen e chunk handles-ve e ka Master-i, dhe kjo e drejtë i jepet klientit-shfrytëzuesit për një kohë të caktuar, të fundme [12].

Duke pasur parasysh se stendat e Google përbëhen nga kompjuterë të kualitetit të dobet, pra ketu s’kemi të bëjmë me serverë të sofistikuar, kuptojmë që besueshmëria se skedarët do të jenë të sigurt me vetëm një kopje të regjistruar, bie, sidomos duke e ditur se mundësitë që komponentet e stendës të dështojnë papritur, janë mjaft të mëdha. Kështu që, Google, ruan së paku tre kopje të secilit chunk, në disqe të ndryshme, duke përfshirë këtu edhe ruajtjen e chunk-eve edhe në stenda të tjera përpos asaj burimore. Veprimi i fundit kryhet me qellim të sigurise sa më të madhe të të dhënave dhe për qasje në të dhëna edhe nëse e tërë stenda del nga sistemi, si rezultat i dështimeve në rrjete, apo për shkak të lidhjeve të shkurta në qarqet e rrymës elektrike [12]. Si funksion te Master-it te SSG, do të definojmë edhe një koncept, metadata, apo në shqip të dhënat për të dhënat — meta të dhënat, me çka kuptojmë ruajtjen e të dhënave të cilat na çojnë tek të dhëna të tjera, sigurisht më të dobishme. Meta të dhënat mirëmbahen si nga Master-i ashtu edhe nga chunkserver-ët, dhe kanë qëllim informimin e klientëve lidhur me vendndodhjen e skedarëve, përkatësisht në nivel më të ulët, chunk-ëve. Meta të dhënat, meqë nuk zënë vend të madh, ruhen në memorien e Master serverit, duke e bërë të mundshme qasjen e shpejtë në to me rastin e kthimit te pergjigjes, klientëve.

12 3. Arkitektura e Google makinës kërkuese 3.2 Sistemi i skedarëve të Google

Meta të dhënat janë të tri llojeve: ato që kanë të bëjnë me skedarët dhe me domenet e chunk-ëve, lidhjet në mes të skedarëve dhe chunk-ëve, dhe vendndodhjen e secilës kopje të chunk-ëve. Këto të llojit të fundit, ruhen në mënyrë të përhershme vetëm nga chunkserver-ët, dhe në rast se Master-i nuk posedon ndonjë informatë të atij lloji, ia kërkon atë chunkserver-it përkatës [12]. Meta të dhënat nuk i jepen shfrytëzuesit në secilin operacion që ai kërkon/ndërmerr meqë kjo do të shkaktonte ngarkesë të madhe në linjat e komunikimit, sikurse edhe do ta ngarkonte pamasë Master-in, duke shkaktuar kaos në sistem, ku Master-i në pjesën më të madhe të kohës do të merrej me identifikimin e vendndodhjes së të dhënave dhe me kthimin e përgjigjeve shfrytëzuesve, gjë që do ta bënte thuaja të papërdorshëm Master-in për operacionet si krijimi i chunk-ëve ndryshimi i emrave të skedarëve e të tjera. Si zgjidhje për këtë problem, është pranuar zgjidhja që ofrohet përmes ruajtjes së të dhënave në anën e klientit — peshimi (cache). Kështu që, fillimisht shfrytëzuesi kërkon informata për një skedar të caktuar, Master-i ia jep ato informata, të cilat shfrytëzuesi i keshon dhe i shfrytëzon për inicimin e operacioneve, duke kontaktuar chunkserver-ët drejtpërdrejtë pa e munduar Master-in [12].

Master-i, me rastin e startimit apo ristartimit të sistemit komunikon me të gjithë chunkserver-ët, me qëllim marrjen e informatave për secilin prej tyre, informata këto që kanë të bëjnë me gjendjen e chunkserver-ëve (a është në funksion chunkserver-i, a mund t’i pranoj urdhrat etj.). Mirëpo, edhe në gjendje stabile, Master-i komunikon me chunkserver-ët në intervale të kohëpaskohshme përmes porosive që quhen porositë ‘rrahja e zemrës’ (nga ang. Heart-beat messages), për të verifikuar rënien eventuale nga sistemi të ndonjë chunkserver-i, dhe me këtë vërtetimin nëse chunkserver-i është duke i kryer punët e parapara [12].

SSG gjithashtu mirëmban edhe një ‘ditar të operacioneve’ apo operation log, ku regjistron të gjitha veprat e ndërmarra nga Master-i dhe në rast të dështimit të Master serverit, Master-i jo që startohet pothuaj menjëherë por edhe do t’i kaloj pikat verifikuese sipas këtij ditari. Me këtë sistemi, do t’i kthehet punës aty ku është ndërprerë, apo me fjalë të tjera do të rikuperohet plotësisht, me mundësi gabimi shumë të vogël. Në rast dështimi, Master-i lexon ditarin e azhurnuar më së fundi (nga ang. most up-to-date operation log) dhe nëse ai është me gabime atëherë merr ndonjë version më të hershëm të tij [12] .

Gjithsesi, edhe pse Master serveri ka fjalën kryesore, në çdo klaster të SSG-së përvec Master-it, veprojnë edhe ‘masterët në hije’ (nga ang. shadow masters), të cilët e mirëmbajnë sistemin njëkohësisht dhe bashkërisht me Master-in kryesor, por edhe në raste kur ai ka rënë nga sistemi. Mirëpo, Master-ët në hije nuk i kanë të gjitha kompetencat për të vepruar, ata kanë të drejtë të japin doreza (nga ang. handle) për lexim të skedarëve, por jo edhe për shkrim apo bashkëngjitje. Regjistrimi (incizimi) i skedarëve në disqe kryhet në njërën nga dy mënyrat e parapara me SSG, përmes të shkruarit apo përmes bashkëngjitjes (nga ang. record append). Përveç kësaj, të shkruarit apo bashkëngjitja është e lejuar për më shumë se një klient. Të shkruarit vazhdon në fund të pjesës tashmë të mbushur të skedarit apo fillon në pjesën e parë të skedarit të sapokrijuar, dhe dallojmë shkrime të gjata të vazhdueshme, dhe të shkurta e të rastësishme. Me të parën nënkuptohet mundësia e një shfrytëzuesi për të shkruar në sekuencë për një kohë më të gjatë, ndërsa me të dytën synohet arritja e paralelizmit në të shkruar, duke i dhënë secilit shfrytëzues mundësinë që të shkruaj nga pak, dhe quhet e rastësishme, për shkak se shfrytëzuesi i parë nuk do të vazhdojë shkrimin aty ku e ka lënë por pas pjesës të cilën e kanë shkruar shfrytëzuesit tjerë. Ky regjistrim është i nivelit të pak kilobajtëve, dhe mirëmbajtja e të shkruarave (çfarë u shkrua, nga kush, dhe si të lidhen pjesët që i ka shkruar i njëjti shfrytëzues) është mjaft sfiduese, andaj jo rastësisht quhet regjistrim atomik. Të gjitha shkrimet drejtohen ekskluzivisht nga Master-i, gjë që e bën më të besueshëm sistemin. Mirëpo, duke marr parasysh se mund të ndodhin gabime edhe në këtë nivel, Google ka zhvilluar një model me të cilin përcaktohet niveli i konsistencës së skedarëve. Sipas këtij modeli, i cili aplikohet si për të shkruar ashtu edhe për bashkëngjitje, apo

13 3. Arkitektura e Google makinës kërkuese 3.2 Sistemi i skedarëve të Google përgjithësisht për çfarëdo mutacioni të skedarëve, një pjesë e skedarit mund të quhet konsistente, nëse të gjithë shfrytëzuesit gjithmonë shohin të njëjtat të dhëna në të gjitha kopjet. Nëse gjatë të shkruarit, nuk ndërhyn asnjë shfrytëzues, dhe me këtë azhurnimi bëhet vetëm nga një shfrytëzues, ajo pjesë quhet e definuar, meqë shfrytëzuesit gjithnjë do të shohin të njëjtat të dhëna, gjë që implikon edhe konsistencën e asaj pjese. Nëse mutacionet janë konkurruese (shumë shfrytëzues shkruajnë në pothuaj të njëjtën kohë) dhe të suksesshme, pjesa e azhurnuar do të jetë konsistente por e padefinuar. Ndërsa, nëse mutacionet dështojnë për arsye të ndërprerjes së energjisë elektrike gjatë të shkruarit, apo për ndonjë arsye tjetër, kjo e lë atë pjesë të skedarit jokonsistente dhe me këtë edhe të padefinuar [12].

Ndërprerja e befasishme e të shkruarit jo që mund të ndodhë në të gjitha kopjet, por mund të ndodhë edhe vetëm në ndonjërën prej këtyre kopjeve, duke e bërë edhe më të vështirë detektimin e gabimeve. Kështu krijohen të ashtuquajturat ‘kopje bajate’ (stale replicas). Fatmirësisht, Master-i ruan edhe numrat e versioneve të chunk-ëve, ashtu që në rast të thirrjes së ndonjë kopjeje, Master-i verifikon numrin e versionit, dhe në rast se detektohet ndonjë ‘kopje bajate’, ajo fshihet [12]. Si siguri shtesë, secili chunkserver shfrytëzon checksum-in (vlerë e cila derivohet nga të dhëna të caktuara), për të detektuar të dhënat e korruptuara. Secili chunk ndahet në blloqe 64 KB, dhe secilit prej tyre i ndahet një checksum 32-bitësh, i derivuar nga të dhënat në bllok, i cili ruhet bashkë me meta të dhënat tjera të chunkserver-it.

Mjaft esenciale dhe mirë të rregulluara janë edhe bashkëveprimet në kuadër të sistemit. qe paraqitet ne figuren 4 sipas [12] ku një mutacion kryhet në shtatë etapa.

Figura 4: Kontrolli i shkrimit dhe rrjedha e të dhënave [12]

Shfrytëzuesi (klienti) i kërkon Master serverit t’i raportojë nëse ndonjëri nga chunkserver-ët që i interesojnë e posedon të drejtën e shfrytëzimit ekskluziv të ndonjë chunk-u dhe vendndodhjen e kopjeve të tij (1). Master-i i kthen përgjigjen se cili prej tyre e ka këtë të drejtë, ose nëse jo, ia jep të drejtën e shfrytëzimit, shfrytëzuesit të parë që e kërkon (2). Chunk-u i cili shfrytëzohet ekskluzivisht quhet parësor (primary replica), ndërsa kopjet tjera quhen dytësore (secondary replica). Në këtë sekuencë, shfrytëzuesi pasi të merr të drejtën e shfrytëzimit ekskluziv, iu dërgon të gjitha kopjeve të dhënat për mutacion (3). Pasi që të gjitha kopjet t’i kenë marrë të dhënat, shfrytëzuesi i dërgon kopjes parësore kërkesën për regjistrim (4), dhe ajo e pason atë në kopjet dytësore (5). Të gjitha kopjet dytësore i raportojnë kopjes parësore për kryerjen e operacioneve (6). Dhe në fund kopja parësore lajmëron klientin për zhvillimin e operacioneve, dhe për dështimet eventuale (7) [12].

14 3. Arkitektura e Google makines kerkuese 3.2 Sistemi i skedareve te Google

Rrymimi apo rrjedhja e të dhënave në rrjet, nuk bëhet sipas topologjive si ajo e degëzimit, ku paketat e të dhënave i dërgohen veç e veç të gjithë chunkserver-ëve sipas nevojave/kërkesave, por shfrytëzohet i tërë brezi frekuencor i rrjetës, ashtu që të gjitha të dhënat i dërgohen chunkserver-it më të afërt, e pastaj ai i bart ato tek chunkserver-i tjetër më i afërt dhe kështu me radhë.

SSG ofron edhe një operacion jo të zakonshëm që bën kopjimin e skedarit apo të tërë direktoriumit (snapshot operation), pothuaj njëkohësisht me mutacionet që mund të bëhen në atë skedar apo në skedarët e atij direktoriumi. Mirëpo, nëse snapshot-i ka filluar para se në ndonjë chunk të fillojë ndonjë mutacion, atëherë kërkesa për mutacion në atë chunk dhe në të gjitha kopjet e tij refuzohet. Por, situata nuk është edhe gjithaq e pashpresë. Nëse arrihet në këtë gjendje, SSG urdhëron ndonjërin nga chunkserver-ët që përmbajnë një kopje të chunk-ut në fjalë që të krijojë një chunk të ri identik në të cilin mund të bëhen mutacionet [12].

Siç mund të kuptohet nga pjesa e mësipërme Master-i e rezervon të drejtën për bllokuar një chunk, apo një numër të tyre, apo edhe ndonjë direktorium të tërë, në rastet kur i jep të drejtën e shfrytëzimit mbi te, ndonjërit prej shfrytëzuesve. Nëse i përmbahemi sistemit të skedarëve të Linux nëse në shtegun /me/docs/professional/thesis (Google shfrytëzon Linux-in si sistem operativ me disa modifikime në kernel), një shfrytëzues ka të drejtën ekskluzive të shfrytëzimit për thesis, atëherë asnjë shfrytëzues nuk mund të ketë të drejtat e shfrytëzimit (shkrimit) për me, docs, professional, thesis apo për çfarëdo skedari që mund të gjendet në kuadër të këtyre direktoriumeve, pasi që sistemi operativ vënë bllokadë të leximit mbi me, docs, professional, dhe bllokadë të shkrimit apo leximit mbi thesis, varësisht nëse thesis është skedar apo direktorium. Master-i përveç që i krijon kopjet e chunk-ëve, ai po ashtu edhe i rikopjon ato nëse numri i kopjeve të tyre është më i vogël se ai i planifikuar. Gjithashtu, SSG përcakton prioritetin e kopjimit të chunk-ëve, ashtu që prioritet më i madh i jepet kopjimit të chunk-ëve që kanë më së paku kopje të regjistruara në krahasim me ato të planifikuara. Për shembull, nëse për dy chunk-ë të ndryshëm janë paraparë që të ruhen nga tri kopje (tri kopje është edhe numri i nënkuptueshëm i kopjeve që ruan sistemi) për secilin, dhe nëse i pari ka humbur dy nga tri kopjet e tjetri vetëm një, atëherë prioritet i jepet të parit.

Rebalancimi i hapësirës dhe ngarkesës, është gjithashtu pjesë e punës së Master-it. Master-i gjithnjë kërkon nëse ndonjëri nga chunkserver-ët është shumë i ngarkuar, pra, hapësira deponuese i është konsumuar mjaft, dhe në anën tjetër ka chunksever-ë të tillë që janë të pashfrytëzueshëm apo pak të shfrytëzueshëm, atëherë Master-i bënë zhvendosjen e chunk-ëve për të balancuar hapësirën dhe me këtë edhe ngarkesën në stendë [12]. Kur një skedar fshihet, ky operacion nuk e imponon drejtpërdrejtë largimin e përhershëm të këtij skedari nga disqet, por si fazë e parë bëhet ndërrimi i emrit të skedarit dhe fshehja e skedarit nga shfrytëzuesit. Pastaj nis procesi i ashtuquajtur i mbledhjes së mbeturinave, kur bëhet largimi i përhershëm. Fshirja zakonisht ndodh për ‘kopjet bajate’, chunk- ët e korruptuar apo chunk-ët jetimë, siç quhen chunk-ët të cilat pas disa mutacioneve apo modifikimeve të skedarëve, nuk janë të lidhura më me asnjë skedar [12]. E veçantë e këtij sistemi të skedarëve, është se shfrytëzuesit i jepet mundësia që të lexojë mbi pjesët të cilat njëkohësisht janë duke u modifikuar dhe kjo nuk i shkakton sistemit gabime në shkrim mu për shkak të përsosmërisë së lartë të kontrollit të operacioneve. Ky sistem i skedarëve, edhe pse duke mjaft i përsosur, është më shumë i orientuar në shërbim të makinave kërkuese, dhe si i tillë nuk është një zgjidhje e mirë për tu aplikuar edhe në sistemet tjera. Vetë fakti se ky sistem është projektuar kryesisht për përpunimin e skedarëve të mëdhenj, e bën të mundimshëm aplikimin e tij në kompjuterët për shfrytëzim personal apo për biznese tjera.

15 3. Arkitektura e Google makinës kërkuese 3.3 Struktura e të dhënave

3.3 Struktura e të dhënave

Strukturimi dhe ruajtja e të dhënave bëhet përmes BigTable, sistem ky i zhvilluar nga Google. BigTable, me paraqitjen e saj ka arritur një zgjerim jashtëzakonisht të madh, duke u përdorur në më se 60 aplikacione/shërbime të Google [13]. BigTable është e ngjashme me një bazë të të dhënave jorelacionale, duke mos përkrahur modelet relacionale të të dhënave, respektivisht i jep më shumë mundësi klientit që në mënyrë dinamike të kontrolloj formatimin e të dhënave dhe dukjen e jashtme të tyre [13].

BigTable paraqitet në formë shumë-dimensionale, përderisa të dhënat janë të renditura sipas një çelësi të caktuar. Të dhënat indeksohen përmes tri vlerave, çelësit të rreshtit, çelësit të kolonës dhe vulës që përmban kohën reale të futjes së të dhënave. Pra, për të arritur deri tek një e dhënë e caktuar duhet t’i kemi që të tri këto indekse:

(rreshti: string, kolona: string, time: int64) - Vlera (E dhëna)

çelësat e rreshtave dhe kolonave, mund të jenë vargje shkronjash e jo domosdoshmërish numra, ndërsa indeksi i tretë që paraqet kohën, jepet si një vlerë 64-bitëshe e numrave të plotë ne fig.5 [13].

Figura 5: Një pjesë e tabelës të BigTable, që ruan të dhënat për ueb faqe [13]

Do të marrim që tabela jonë përmban të dhëna të ueb-faqeve të ndryshme. Kështu që, URL-të e ueb-faqeve do të jenë çelësat e rreshtave. Çelësat e rreshtave mund të jenë të gjatë deri 64 KB. Të dhënat janë të renditura në mënyrë leksikografike sipas rreshtit. Çdo tabelë ndahet sipas një rangu vlerash duke krijuar tabelzat e quajtura tablets, të cilat përmbajnë në vetvete një pjesë të të dhënave të tabelës së caktuar. Ndarja nëpër tableta bëhet, në mënyrë që të mundësohet ngarkimi i balancuar nëpër komponentet e klasterëve, ndërsa përfitojmë edhe në shfrytëzimin efikas të rrjetit, pasi që leximet do të jenë më të rralla dhe të dhënat e bartura më të pakta (nuk do ta bartim tërë tabelën, por vetëm një pjesë të saj: tabletën). Meqë, www do të ishte e përbashkët për të gjithë çelësat e rreshtave, Google bën rigrupimin e pjesëve të URLs dhe rivendosjen e tyre, ashtu si është paraqitur në figurë e mësipërme (në vend të ‘www.cnn.com’, ruhet ‘com.cnn.www’) [13]. Kolonat, përkatësisht, çelësat e kolonave, për dallim nga rreshtat, grupohen nëpër sete të quajtura familje kolonash. Zakonisht të gjitha të dhënat e tipit të njëjtë janë të grupuara në një familje të caktuar. çelësat e kolonave, sikurse edhe familjet krijohen para se të futen të dhënat, ashtu që, me rastin e futjes së të dhënave mund të përdoret cilido çelës i familjes. Kolonat paraqiten në formën: family:qualifier, ku së pari paraqitet emri i familjes, e pastaj çelësi. Një rast konkret do të ishte familja language, e cila ruan numrat identifikues të gjuhëve në të cilat paraqitet përmbajtja e ueb- faqes [13]. Timestamp, apo vula e kohës reale, shërben për të bërë të mundshëm vendosjen e të dhënave në formën e matricave shumë-dimensionale. Përderisa, me rresht dhe kolonë, paraqitnim të dhënat përmes matricave dy-dimensionale, timestamp, na mundëson shtimin e dimensioneve tjera. Në

16 3. Arkitektura e Google makinës kërkuese 3.3 Struktura e të dhënave një rast konkret, një qeli e tabelës mund të ketë të dhëna të ndryshme, për shembull përmbajtja e një ueb-faqeje mund të ndryshohet në intervale të caktuara kohore. Atëherë, në mënyrë që t’i ikim shtimit të një rreshti të ri vetëm e vetëm për një qeli ne krijojmë faqet e matricave, ashtu që një qeli e caktuar mund të ketë më shumë se një version, dhe indeksimin e këtyre versioneve do ta bëjë timestamp. Me hapjen e tabletës të dhënat e para që do të na paraqiten do të jenë celulat me të dhënat e azhurnuara më së fundi, e pastaj versionet e mëhershme të renditura në mënyrë kronologjike [13].

BigTable mbështet në SSG (Sistemin e Skedarëve të Google), për ruajtjen e të dhënave në disk, ashtu që formati i skedarëve SSTable, përdoret për ruajtjen e këtyre të dhënave nëpër serverët e klasterëve. SSTable paraqitet si një hartë e të dhënave të renditura e të lidhura përmes logjikës çelës-vlerë. Ato janë të ndërtuara nga blloqet sekuenciale (zakonisht këto blloqe kanë madhësi të përcaktuar 64 KB, por trajta e tyre mund të ndryshohet). Në kuadër të SSTable gjendet edhe një hartë e blloqeve, në të cilën ndodhen indekset e blloqeve, të cilat, rrjedhimisht, janë të indeksuara në mënyrë që të ofrojnë kërkim efikas. Kjo zvogëlon kohën, për të cilën të dhënat do të arrinin për përpunim, pasi që do të duhej vetëm të gjenim bllokun në hartë dhe pastaj përmes vetëm një kërkimi në disk do të gjenim të dhënat e kërkuara, ose edhe më mirë, SSTable është e mundur që e tëra të vendoset në memorien punuese, me çka do të evitonim kërkimin nëpër disk [13].

Për t’i evituar mutacionet e padëshirueshme të të dhënave BigTable mbështet në një shërbim mjaft efikas për bllokimin (lock) e të dhënave Chubby [13]. Chubby krijon 5 kopje, nga të cilat njëra zgjidhet master. Çdo klient mban një sesion me Chubby shërbimin, ashtu që çdo ndryshim eventual, do të ndodhte vetëm me bekimin e Chubby master kopjes. Nëse, klienti nuk arrin që ta mbaj sesionin të gjallë apo nëse e humbet bllokimin mbi skedarët në ndonjë mënyrë tjetër, atëherë ai klient nuk mund të bëjë ndryshime të mëtutjeshme pa marrë përsëri të drejtën mbi to [13]. BigTable është e implementuar në atë mënyrë që përmban një librari, në të cilën janë të lidhur të gjithë klientët, një master server, si dhe disa tablet servera. Master serveri bën ndarjen e tabletave, tablet serverëve, të cilët pastaj menaxhojnë me to. Master serveri po ashtu është përgjegjës për detektimin gjendjes së tablet serverëve, balancimin e ngarkesës nëpër tablet serverë, si dhe për pastrimin e diskut nga skedarët e panevojshëm [13].

Çdo tablet server menaxhon një set me tableta, duke përfshirë leximin dhe shkrimin nëpër ato tableta, sikurse edhe ndarjen e tyre në rastet kur ato rriten shumë. Eshtë e rëndësishme të potencohet se klientët nuk komunikojnë me master serverin për ndryshimet nëpër tablet-a, por direkt me tablet serverin, gjë që mundëson një efikasitet më të madh të master serverit [13].

Hierarkia e vendosjes së tabletave paraqitet në tri nivele. Në nivelin e parë është skedari i Chubby-t, i cili ruan të dhënat për tabletën kryesore (rrënjë) [13]. Tableta kryesore përmban të dhënat për tableta e tjera përmes një metadata tabele. Çdo metadata tabletë, përmban vendndodhjen e një seti të tabletave të shfrytëzuesve. Një gjendje persistente e SSTable skedarëve ruhet në disk, përderisa azhurnimet e fundit që bëhen nëpër tabela ruhen në të ashtuquajturën memtable. Pasi kemi azhurnime të vazhdueshme, BigTable posedon edhe dy metodat e saja për kompaktizimin e tabletave. Dallojmë minor compation, e cila shërben për krijimin e SSTable, ashtu që minimizon të dhënat që do të duhej të rikuperoheshin nga ndonjë dështim eventual, dhe ma]or compaction, që shërben për bashkimin e SSTable të krijuara gjatë kompaktizimit të mëparshëm [13].

17 4. Organizimi i të dhënave në Google 4.1 Struktura funksionale e komponentëve

Kapitulli 4

4 Organizimi i të dhënave në Google

4.1 Struktura funksionale e komponentëve të klasterëve të Google

Sistemi i grumbullimit dhe i manipulimit me të dhëna është po aq kompleks sa edhe ai renditjes së rezultateve, apo shpërndarjes së ngarkesës nëpër kompjuterët e klasterëve. Për grumbullimin e të dhënave përdoren të ashtuquajturit ueb crawler (nga ang. crawler - zvarritës) apo siç preferojnë t’i quajnë disa autorë të tjerë, merimanga. Google makina kërkuese, lëshon në qarkullim shumë crawler në të njëjtën kohë, të cilët luajnë rolin e agjentit duke grumbulluar të dhëna nga ueb faqet e prezantuara në ueb siq shifet ne fig. 6 [2].

Figura 6: Arkitetktura e nivelit të lartë të Google makinës kërkuese [2]

Njëri nga serverët e klaster arkitekturës është i paraparë që të shërbej vetëm si furnizues i crawler- ëve me URL, do të thotë që t’i orientojë ata fillimisht se cilave ueb faqe t’i referohen për t’i grumbulluar të dhënat dhe quhet URL Server [2]. Të gjitha të dhënat e mbledhura nga crawler-ët destinacion primar e kanë serverin, i cili shërben për ruajtjen e përkohshme të të dhënave, e i cili quhet Store Server. Hapi i ardhshëm në organizimin dhe përpunimin e të dhënave, i takon përsëri Store Server-it, i cili bën ngjeshjen e të dhënave, kompresimin, në mënyrë që të përfitojmë sa më shumë në hapësirën e diskut. Pasi që të kompresohen të dhënat, ato i dorëzohen rezervuarit, përkatësisht depos së të dhënave që në figurë paraqitet me emrin Repository [2].

18 4. Organizimi i te dhenave ne Google 4.1 Struktura funksionale e komponenteve

Me këtë rast secilës ueb faqe të analizuar, i jepet një ID unike e cila quhet docID [2]. Ky element identifikues është unik për secilën ueb faqe pasi nxirret si hash funksion i secilës URL të ueb faqeve të përpunuara.

Pasi që të dhënat të jenë të deponuara në rezervuarin e sistemit, fillon funksioni i indeksimit, që siç e dimë parimisht mundëson kërkimin më të shpejtë nëpër depot e të dhënave. Indeksimin e të dhënave e kryejnë komponentët e destinuara për këtë punë si Indexer dhe Sorter. Indeksuesi (Indexer) përveç tjerash bën leximin e të dhënave nga rezervuari, i dekompreson ato, dhe fillon me analizën e këtyre dokumenteve. Çdo dokument i analizuar, tashmë shndërrohet në një set fjalësh të cilat paraqiten më së shpeshti në dokument, e që quhen hits. Një shënim (hit) regjistron fjalën, pozitën e saj në dokument, madhësinë e shkronjave të përdorura për këtë fjalë në dokument dhe formën në të cilën është shkruar (me shkronja të mëdha, të vogla apo të përziera) [2]. Indeksuesi, pasi që t’i kryen të gjitha këto manipulime me dokumentin përkatës i shpërndan rezultatet e analizave (hits) nëpër fuqitë (barelët) e të dhënave. Mirëpo, puna e indeksuesit nuk përfundon me kaq. Ai po ashtu i analizon të gjitha linçet nga ueb faqet e shqyrtuara, dhe i regjistron të gjitha të dhënat relevante lidhur me ato linçe, në një skedar të dizajnuar vetëm për to, Anchors. Në Anchor, ka informata të mjaftueshme, për secilën lidhje (linç), nga ku dhe për ku është i drejtuar, sikurse edhe teksti që i është shoqëruar atij linçi.

Pjesa e ardhshme e përpunimit i takon komponentit URL Resolver, i cili lexon skedarin e linçeve, dhe i konverton të gjitha URL-të e linçeve në URL absolute, e po ashtu edhe në docID. URL Resolver-i, kryen edhe një funksion tjetër. Ai vendos tekstin përreth linçit në indeksin e avancuar, duke ia shoqëruar atij edhe docID-në, në të cilën ai linç është i drejtuar. Si rezultat final, URL Resolver-i gjeneron një bazë të të dhënave, të përbërë vetëm nga linçet, e në formë të docID-ve. Kjo bazë e të dhënave shërben më vonë për të llogaritur rëndësinë e secilës ueb faqe, përmes algoritmit të Google, PageRank [2]. Indeksuesi i dokumenteve shërben për të ruajtur të dhënat relevante për të gjitha dokumentet, të cilat nëpër barela janë të radhitura sipas docID elementit. Ndër informatat relevante që ruhen për dokumentet janë statusi i dokumentit, treguesi se ku gjendet dokumenti në rezervuarin e sistemit (Repository), numri i gjeneruar nga docID (checksum), i cili siguron se nuk është bërë asnjë ndryshim i rastësishëm në përmbajtjen e docID, si dhe statistika tjera. Nëse dokumenti në fjalë është përpunuar nga crawler-ët, atëherë do të gjendet edhe informata se ku gjendet docinfo, variabël kjo që përmban URL-në e dokumentit dhe titullin e tij [2].

Leksikoni, si pjesë e sistemit, shërben për ruajtjen e të gjitha fjalëve të cilat janë hasur gjatë përpunimit të dokumenteve (ueb faqeve). Fjalët identifikohen përmes wordID-së, e cila është unike për secilën fjalë. Leksikoni është i implementuar në atë mënyrë, që ruan në njërën anë të gjithë wordID-të dhe në anën tjetër ju shoqëron atyre hash tabelat me tregues, se ku janë hasur ato fjalë nëpër dokumente[2].

Radhitësi apo Sorter, merr të dhënat e radhitura sipas docID-ve nëpër barela dhe i riradhitë ato në bazë të wordID elementit, për të gjeneruar indeksin e përmbysur (inverted index).

Hit listat apo listat e shënimeve, shërbejnë për të ruajtur numrin e paraqitjeve të fjalëve të veçanta nëpër secilin dokument veç e veç. Aty ruhen edhe të dhënat që kanë të bëjnë me pozitën e fjalës në dokument, fontin që është përdorur, dhe informata lidhur me formën në të cilën është shkruar fjala (me shkronja të mëdha, të vogla apo të përziera)[2]. Hit listat zënë hapësirën më të madhe në indekset e avancuara dhe të përmbysura. Kështu që, për të përfituar sa më shumë hapësirë është përdorur një lloj kodimi i informatave, i cili mundëson shfrytëzimin optimal të hapësirës në disk.

19 4. Organizimi i te dhenave ne Google 4.1 Struktura funksionale e komponenteve

Sipas këtij kodimi, përdoren 2 bajt për çdo shënim (hit). Ekzistojnë dy lloje të shënimeve: shënimet e përfytyruara dhe ato të dukshme (fancy hits and plain hits). Shënimet e përfytyruara paraqesin shënimet të cilat hasen në kuadër të URL-së, titullit të ueb faqes, tekstit përreth linçeve, ose në etiketave (tag) meta. Ndërsa shënimet e dukshme paraqesin tërë pjesën tjetër, duke përfshirë këtu bitin e formës së shkronjave, madhësinë e fontit, dhe 12 bit për pozitën e fjalës në dokument (të gjitha pozitat të cilat e kalojnë shifrimin mbi 4095, shënohen si 4096) si ne fig. 7.

Figura 7: lndekset e avancuara dhe të përmbysura dhe leksikoni [2]

Madhësia e fontit paraqitet me tre bit, por vetëm 7 nga mundësitë e permutacionit shfrytëzohen për të koduar atë, pasi që permutacioni 111, lajmëron se kemi të bëjmë me shënim të përfytyruar. Në anën tjetër, shënimet e përfytyruara përmbajnë bitin e formës së shkronjave, 3 bit për të sinjalizuar se kemi të bëjmë më shënim të përfytyruar, 4 bit për kodimin e llojit të shënimit të përfytyruar, dhe 8 bitët e mbetur për pozitën e fjalës. Për shënimet që kanë të bëjnë me tekstin e linçeve 8 bitëshi i fundit ndahet në dy pjesë, ku 4 bitët e parë përdoren për hashin e docID-së të cilit i referohet linçi dhe 4 të tjerët për pozitën e fjalës në tekstin e linçit [2].

Indeksi i avancuar është i radhitur pjesërisht me rastin e indeksimit të dokumenteve nga ana e indeksuesit dhe si i tillë është i vendosur në barelat e sistemit. Meqë nevojitet hapësirë e madhe për t’i vendosur të gjitha të dhënat, numri i barelave në sistem është gjithnjë më i madh se një. Secili prej barelave përmban në vete një rang të vlerave të wordID-së. Fjalët e regjistruara nëpër barele, përmbajnë në listat e tyre edhe referencën në dokumentin përkatës nga i cili burojnë. Dhe, sigurisht, duke pasur parasysh se qëllimi i sistemit është që të ruhet sa më shumë hapësirë e diskut, wordID-të nuk regjistrohen me numrat e tyre përkatës, me ç’rast do të na duheshin 32 bit, por, me një teknikë tjetër, ku wordID-të paraqiten vetëm si diferencë relative nga numri minimal i wordID-së në atë barelë [2].

Indeksi i përmbysur përdor të njëjtat hapësira për të deponuar të dhënat sikurse indeksi i avancuar (barelat), përveçse indeksi i përmbysur paraqet të dhënat e përpunuara tanimë nga radhitësi Sorter. Për çdo wordID, leksikoni përmban informatën se në cilën barelë gjendet ajo fjalë dhe referencën e saj në listën e dokumenteve, përkatësisht në dokumentet, të cilave ajo fjalë iu referohet.

20 4. Organizimi i të dhënave në Google 4.2 Mbledhja e informatave në ueb

Një çështje për të cilën, është menduar mjaftë, është se në çfarë radhitje duhet të paraqiten dokumentet në listën e dokumenteve. Prej tyre, ideja e parë ishte të paraqiten të radhitura sipas doclD-së, ndërsa tjetra sipas numrit të përsëritjes së fjalës përkatëse në atë dokument. Si zgjidhje, u morr një kompromis në mes këtyre ideve, sipas të cilit do të gjeneroheshin dy sete barelash, njëri me informata nga teksti përreth linçeve (anchor) dhe titujt e dokumenteve, e tjetri me të gjitha të dhënat tjera, ashtu që, me rastin e kërkimit së pari do të kërkohej nëpër setin e parë, dhe nëse nuk do të ktheheshin mjaft informata, atëherë do të fillonte kërkimi në setin e dytë [2].

4.2 Mbledhja e informatave në ueb

Grumbullimi i të dhënave nga tashmë më shumë se 10 miliardë dokumente [3], nuk është punë që do të mund të kryhej nga një proces i paautomatizuar. Vështirë mund të mendohen qindra punëtorë fizikë që do të regjistronin materialet nga ueb-i. Kjo jo që do të ishte e shtrenjtë dhe e mërzitshme, por edhe do të merrte aq shumë kohë, sa që do të mund të vinte deri te dështimi i projektit, sidomos duke pasur parasysh se ueb-i i është drejtuar një dinamike të ndryshimit të të dhënave, sa që të dhënat e mbledhura sot, nesër do të ishin të vjetruara. Si zgjidhje për këtë problem vjen në konsiderim zhvillimi aplikacioneve të cilat do të bënin mbledhjen e këtij materiali si ne fig 8. Mu këtu edhe fillon historia e programeve të njohura sot si crawlers (zvarritësit), që më parë quheshin edhe me emrat si wanderer (endacak), robotë, merimanga, peshq, krimba etj. [14].

Figura 8: Rrjedha e një crawler-i të thjeshtë sekuencial [14]

Në formën e tyre më të thjeshtë crawler-ët fillojnë me një faqe bërthamë, e pastaj vazhdojnë me linçet e jashtme të cilat i hasin në kuadër të dokumentit, të cilin janë duke e ekzaminuar. Procesi vazhdon me ekzaminimin e dokumenteve të cilat buronin nga linçet e faqes bërthamë dhe vazhdon me dokumentet të cilat vijnë si rezultat i linçeve të jashtme në këto dokumente. Pak a shumë kjo paraqet jetën e një crawler-i, e cila përfundon kur ai të ndalet nga personi që e mbikëqyr, pasi që t’i harxhohen të gjitha linçet e nxjerra nga analiza e dokumenteve, apo pasi që të jetë arritur ndonjë objektiv tjetër [14].

Crawler-ët mund të jenë selektivë sa i përket natyrës së ueb faqeve që ata marrin në shqyrtim. Këta të fundit quhen crawler preferencial.

Crawler-i mirëmban një listë me URL të cilat nuk i ka vizituar, e cila quhet frontier (nga ang. frontier - zona të pashkelura) [14].

21 4. Organizimi i të dhënave në Google 4.2 Mbledhja e informatave në ueb

Frontier-i paraqet listën e detyrave që duhet t’i kryejë crawler-i. Mirëpo, gjatë ekzaminimit të dokumenteve paraqiten edhe linçe të tjera, kështu që lista nuk përfundon me detyrat e parapara në fillim. Sipas [14], është shumë e zakonshme që një frontier me 10.000 URL të ueb faqeve të futura në fillim të rritet në një listë prej më se 60.000 URL-ve.

Procesi i mbledhjes së informatave nga ueb faqet, i rikthehet pikës fillestare pasi që të jetë ekzaminuar dokumenti përkatës, duke kërkuar URL-në e ardhshme në listë dhe për të marr në shqyrtim dokumentin, të cilit ajo i referohet. Procesi, në mënyrë të zakonshme përfundon kur nuk mbetet asnjë URL në frontier për tu ekzaminuar [14].

Në disa raste, mund të ndodh që crawler-i të hyjë në të ashtuquajturën spider trap (kurthin e merimangës). Kjo paraqitet atëherë, kur crawler-i has në shumë URL të ndryshme të cilat i referohen të njëjtës ueb faqe. Rastet më të shpeshta janë ato kur ueb faqet në kuadër të një ueb sajti i referohen njëra tjetrës, ashtu që pas ekzaminimit të njërës prej tyre përmes linçeve të jashtme (eksterne) crawler-i kalon në faqen tjetër, e cila përmes linçeve të saja eksterne (por të formuluara ndryshe), e kthen përsëri në faqen paraprake, dhe kështu crawler-i hyn në një rreth vicioz. Po ashtu URL-të të cilat përmbajnë ndryshore (variabla) si : http://www.cfaredodomeni.com/index.php?moduli=FaqjaKryesore&Pjesa=I http://www.cfaredodomeni.com/index.php?moduli=FaqjaKryesore&Pjesa=4 mund të jenë linçe të cilat i referohen të njëjtës faqe. Për t’i evituar këto kurthe Google ka vendosur politika, me të cilat i dekurajon shfrytëzuesit që të përdorin URL në forma të tilla, natyrisht, nëse ata dëshirojnë që Google t’i vizitojë faqet e tyre.

Një qasje tjetër, është ofruar nga [14], ku thuhet se ky problem mund të zgjidhet edhe me kufizimin e numrit të faqeve që do të merren në shqyrtim nga një domen i caktuar.

Crawler-ët e avancuar, përdorin edhe metoda të tjera për t’iu ikur kurtheve. Ndër to është edhe kthimi i URL-ve në formë kanonike [14]. Procesi fillon me kthimin e të gjitha shkronjave në URL në shkronja të vogla, ashtu që crawler-i të mos bëjë dallimin në mes të: http://www.CFAREDODOMENI.com dhe http://www.cfaredodomeni.com.

Pastaj, vjen kodimi i URL-ve në formë standarde, ashtu që crawler-i të mos bëjë dallimin mes të: http://www.cfaredodomeni.com/Faqja e pare.html dhe http://www.cfaredodomeni.com/Faqja%20e%20pare.html

Sikurse edhe standardizimi i formës së paraqitjes së URL-ve si në rastin: http:// www.cfaredodomeni.com/modulet/shitja/pagesat/keshi.html dhe http:// www.cfaredodomeni.com/modulet/shitja/pagesat/transaksionet/../keshi.html

Po ashtu, edhe rregulla të tjera për kthim në formën kanonike të URL-ve mund të aplikohen, duke filluar nga numri i portit që vendoset ose nuk vendoset në URL e deri tek ato që kanë të bëjnë me kufizimin e shkronjave të mara në shqyrtim nga një URL.

22 4. Organizimi i të dhënave në Google 4.2 Mbledhja e informatave në ueb

Crawler-ët kanë për detyrë, përveç mbledhjes së materialit, edhe ta bëjnë analizën e të dhënave nëpër dokumente. Në mënyrë që ky qëllim të arrihet atëherë do të na duhej një HTTP klient, i cili do të na mundësonte dërgimin e HTTP kërkesave dhe shqyrtimin e përgjigjeve të kthyera. Këta klient zakonisht janë të konfiguruar ashtu që të presin përgjigjen për një kohë të caktuar, dhe jo përjetësisht, pasi që kjo do ta bllokonte tërë procesin, pasi që tek Google, një crawler mund të mbajë deri 300 lidhje të hapura me serverët nëpër botë, në të njëjtën kohë [2].

Gjithashtu, crawler-ët zakonisht janë të konfiguruar që të lexojnë ueb faqet më të vogla se 20 KB, përderisa ato më të mëdha se 20 KB, ose nuk i lexojnë fare, e ose e lexojnë vetëm pjesën fillestare të tyre [14]. Një problem i paraqitur me rastin e mbledhjes së informatave, ka të bëjë me faqet për të cilat autorët nuk dëshirojnë që informatat e publikuara në to, të regjistrohen diku tjetër, disa për shkak të të drejtave autoriale, e të tjerat edhe për shkak se në to mund të kishte informata të fshehta, si numrat e kredit kartelave të klientëve etj. Google, është ballafaquar që në ditët e para me këtë problem. Si përgjigje ndaj kësaj u krijua i ashtuquajturi Robot Exclusion Protocol, sipas të cilit në të gjitha dosjet (folders) në të cilat crawler-i nuk do të duhej të hynte të gjurmonte, përkatësisht të mblidhte material, duhet të kenë një skedar të vogël të shkruar, e të emëruar si robots.txt [2, 14]. E tëra që duhet të shkruhet në këtë skedar është përcaktimi i crawler-ëve që dëshirojmë apo nuk dëshirojmë t’i lejojmë të vizitojnë pjesë të caktuara të ueb sajtit. Për shembull,

User-agent: BadBot Disallow: I

Do t’ia ndalonte qasjen crawler-it me emrin BadBot [15] në gjithë skedarët e ueb sajtit, përderisa me

User-agent: * Disallow: IadministrataI Disallow: IpagesatI

Do t’i ndalonim të gjithë crawler-ët që të gjurmonin në dosjet (folders) administrata dhe pagesat. Mënyra e punës së crawler-ëve përcaktohet me algoritmin mbi të cilin ato janë zhvilluar. Duke iu referuar literaturës gjejmë një numër të konsiderueshëm të algoritmeve mbi të cilat janë zhvilluar këto programe [15].

Naive Best-First crawler algoritmi mbështet në krijimin e një vektori me fjalë të paraqitura në dokumentin e shqyrtuar, e të renditura sipas frekuencës së paraqitjes së atyre fjalëve në dokument. Pas kësaj, crawler-i bën llogaritjen e ngjashmërisë në bazë të kosinusit, të ueb faqes me pyetësin apo përshkrimin e formuluar nga iniciuesi i crawler-it, dhe në bazë të saj i jep vlera të caktuara URL-ve të pavizituara që rrjedhin nga kjo ueb faqe, duke përcaktuar kështu rëndësinë e tyre në formë artificiale [14].

SharkSearch crawler algoritmi përdor të njëjtat masa për përcaktimin e ngjashmërisë sikurse edhe Naive Best-First algoritmi. Mirëpo, për dallim, SharkSearch, iu jep vlerat URL-ve të pavizituara edhe duke marr parasysh vlerat që kanë pasur URL-të paraardhëse dhe tekstet përreth linçeve [14].

Focused crawler algoritmi i klasifikon faqet e mbledhura sipas kategorive përmes taksonomisë së përmbajtjes së tyre [14, 16]. Në fillim ky crawler kërkon të përcaktohet taksonomia e përmbajtjes së faqeve. Iniciuesi mund që të kyçet në proces duke krijuar kategori të reja, apo të heq ato që

23 4. Organizimi i te dhenave ne Google 4.2 Mbledhja e informatave ne ueb mendon se nuk munt të cilësohen si të mira. Se cila faqe, cilës kategori do t’i takojë, përkatësisht në cilën kategori do të futet përcaktohet përmes të ashtuquajturit Bayesian classifier, i cili shfrytëzon probabilitetin për të përcaktuar se një faqe e caktuar f i takon një kategorie te caktuar k.

Context Focused crawler algoritmi gjithashtu përdor klasifikuesit Bayesian, për t’i drejtuar crawler-ët. Por, për dallim nga algoritmit e tjera, ky algoritëm shfrytëzon edhe vlerësimin e distancës mes faqeve për të arritur te rezultatet e dëshiruara [14].

Crawler-ët të cilët nuk janë të dizajnuar mirë mund të hasin në shumë probleme, sidomos duke pasur parasysh atë sasi marramendëse të të dhënave në ueb. Sipas [2], Google crawler-ët duke provuar që të mbledhin të dhënat nëpër ueb faqet e një domeni, kishin filluar të mbledhin të dhënat e disa skedarëve që ishin pjesë e një online loje, me ç’rast nëpër ekranet e shfrytëzuesve të kësaj online loje kishin filluar të paraqiteshin gabime të ndryshme. Andaj, çdo crawler, i cili mendohet të futet në përdorim në ueb, duhet të përgatitet në atë formë, që të tejkalojë edhe objektivat shoqërore. Të marrësh informata, por të mos shkaktosh probleme.

4.3 Indeksimi i uebit dhe MapReduce modeli

Çdo indeksimi i paraprinë analiza e dokumenteve të mbledhura. Meqë, çdokush mund të zhvillojë ueb faqe përkatësisht ueb aplikacione, duhet pritur që do të na paraqiten standarde të llojllojshme dhe gabime të llojllojshme gjatë analizës së tyre. Përveç problemeve si ballafaqimi me karaktere të cilat nuk janë në listën ASCII, që paraqet standardin amerikan të shkrimit, ballafaqimit me shkronjat jo latine, si cirilike, arabe, kineze etj., një problem të madh paraqet edhe shqyrtimi i kodimit të dokumentit sipas gjuhës HTML. Shumë shfrytëzues i shkruajnë dokumentet e tyre pa pasur fare kujdes në vendosjen e etiketave (tags) [2]. Janë të shumta dokumentet të cilat as që i kanë etiketat mbyllëse, gjithë kjo në saje të fleksibilitetit të gjuhës HTML. Si pasojë e kësaj, shqyrtuesit të ueb faqeve si ne fig. 9 do t’i duhej që t’i bëj këto punë, në mënyrë që të kemi një pasqyrë të mirë të dokumenteve, dhe natyrisht, edhe për t’i evituar problemet e mundshme.

Figura 9: Një faqe e bazuar ne HTML dhe struktura përkatëse [16]

24 4. Organizimi i të dhënave në Google 4.3 Indeksimi i uebit dhe MapReduce modeli

Në Figurën 9 është paraqitur një dokument i rregullt i shkruar në gjuhën HTML së bashku me grafin përkatës të etiketave (tags).

etiketa paraqet kreun e dokumentit dhe tregon se një dokument i bazuar në gjuhën HTML pason. Pastaj kemi pjesën e cila nuk iu paraqitet vizitorëve, mirëpo kjo pjesë është jashtëzakonisht e shfrytëzueshme për crawler-ët, pasi që në këtë pjesë vendosen titulli i dokumentit, në kuadër të etiketës