Inleiding: 2-tal minuten (introductie, niet abstract) 2 slides korte uitleg semantisch web Sectie 2: Architectuur en Methodologie 3 slides veel schema'sSectie 5: FGMT 3 slides Slot (met als basis sectie 8) 1 slideALGEMEEN veel schema's ende foto's, weinig tekst
Wat is powerset? Powerset bouwt aan een zoekmachine voor natuurlijke taal die specifieke antwoorden kan geven op vragen van gebruikers (in tegenstelling tot keyword-gebaseerde zoekmachines zoals google of bing). Bijvoorbeeld bij de vraag (maar dan in het engels) “Welke staat van de VS heeft de hoogste inkomensbelasting” zou een conventionele zoekmachine de vraag an sich negeren en zoeken op staat, hoogste, en inkomensbelasting. Powerset probeert het verwerken van natuurlijke taal te gebruiken om documenten terug te geven die de vraag antwoorden. Moeilikheden semantic search: zeer zwaar op processoren internet wordt groter => data die verwerkt moet worden ook
Werking van een doorsnee zoekmachine: wanneer we iets op internet opzoeken, typen we onze zoekterm in en hop, we krijgen bijna meteen een antwoord. De gehele zoekterm is 1 query die naar de servers van de zoekmachineëigenaar verstuurd wordt. Deze wordt opgesplitst in verschillende deelopdrachten. Zo'n deelopdracht noemen we ook een thread. Zoals hier al te zien is, wordt zo'n query opgesplitst in deeltjes die dan afzonderlijk zullen worden behandeld. Hun resultaten worden dan later weer samengevoegd. Dit parallellisme heeft vooral als doel meer resultaten te kunnen teruggeven. Wat dit onderzoek echter wil uitzoeken is of het niet mogelijk is te parallelliseren in functie van de snelheid waarmee de resultaten geretourneerd worden. Dit willen we uitzoeken met in het achterhoofd de toepassing van het semantische web.
Dit is de werking van de zoekmachine zoals we ze nu kennen. Verschillende queries worden aan verschillende query-integration servers toegekend en elke query wordt in threads opgesplitst. De index van de server is ook in een paar delen opgesplitst, zodat threads van verschillende query's gelijktijdig kunnen werken in de index. (gekleurde pijltjes). Nadat alle threads van een query voltooid zijn, worden de top hits van elk onderdeel van de index teruggegeven aan de query-integration server die dan de top hits samenvoegt en nog opmaak toevoegt om het geheel uiteindelijk aan de gebruiker terug te geven. Op deze slide is de interne structuur van een zoekmachine te zien. Elke query wordt naar één server gestuurd en zal daarna onderverdeeld worden in enkele threads. Rechts staan 3 kopieën van de gehele index. Deze index bevat alle informatie van de webpagina's die zullen doorzocht worden. Zo'n index bezit een soort van sleutelwoordencatalogus. De verschillende woorden van een query zullen in de index worden opgezocht en voor elke thread worden alle hits (de resultaten) geretourneerd aan de query-integratieserver. Deze maakt dan een selectie van de beste hits naargelang de query, voegt nog wat opmaak toe en zal uiteindelijk via de Front-end server de zoekresultaten teruggeven aan de gebruiker.
Beste granulariteit voor parallellisme? Evaluatie van verschillende modellen We deden alle experimenten met de code van Powerset’s zoekmachine, een index van Wikipedia-artikels en willekeurige queries uit onze logs. Elk experiment bestond uit het verwijderen van de cache van het besturingssysteem, het herstarten van de zoekprocessen en het afvuren van 12000 queries vanop een client-machine. We tellen de eerste 2000 queries van het experiment niet mee om de file-cache te laten opwarmen. Met deze methode verkregen we resultaten met een variabiliteit van minder dan 1%. Wanneer we de resultaten bekeken waren we vooral bezig met de wachttijd en in mindere maten met de efficientie van cpu en geheugengebruik. En we introduceren een subjectievere manier om ons resultaat te meten: het percentage van queries die terugkomen in minder dan een bepaalde tijdsspanne. Die tijdspanne is, misschien wat arbitrair geplaatst, één seconde
De structuur die in dit onderzoek wordt bekeken, is FGMT(Fine Grained Multi Thread). Een query zal niet meteen in threads onderverdeeld worden. Je moet weten dat er een index van de index is, deze slaat op voor elke term in welke documenten deze voorkomt. Eerst worden alle read-operaties dus klaargezet en daarna worden deze over de threads verdeeld. Dit heeft als voordeel dat de threads zich niet meer moeten bezighouden met het opzoeken van de relevante documenten. Een ander verschil, dat niet op de afbeelding te zien is, is dat er slechts 1 query terzelfdertijd behandeld wordt per core, omdat de index niet opgesplitst is. Het proces is dus niet meer zo afhankelijk van de andere queries als bij de voorgaande methode.
Deze grafiek laat zien na hoeveel tijd 5, 25, 50, 75 en 95% van de 10.000 queries uit het experiment hun antwoord gaven. De grafiek toont duidelijk dat FGMT de snelste methode van de 3 gebruikte is wanneer we queries parallelliseren. Een minder positieve bemerking is dat de snelste queries, de 5% die het eerst klaar waren met hun taak, trager zijn in geparallelliseerde werking dan in sequentiële werking, deze tijd gaat van 14 millis naar 24 millis. FGMT zal dus niet altijd de zoektijd verminderen. Nu kunnen we ons de vraag stellen voor welke queries dit wel gebeurt, en voor welke niet. Na verder onderzoek is gebleken dat sommige korte queries beter gebaat zijn met een lineaire aanpak dan met een parallelle. Daarom zullen we proberen een heuristiek te ontwerpen die enkel deze queries sequentieel laat verwerken.
Heuristiek 1: query wordt sequentieel op 1000 documenten losgelaten, dit geeft goed beeld of query al dan niet veel hits zal hebben. Indien aantal hits onder voorafbepaalde grens zit, sequentieel verdergaan met query. Indien boven deze grens, de rest van de index in parallelle threads verwerken. Deze grens, is een interactiegrens van 1% van de documenten, 10 documenten dus. Concreet wil dit zeggen dat wanneer een query gelinkt wordt aan meer dan 10 documenten in die 'proefperiode', het een query is die genoeg resultaten zal teruggeven om parallellisme te rechtvaardigen. Daarom wordt de query voor de rest van de index dus parallel verdergezet. In deze heuristiek wordt geen rekening gehouden met het aantal threads waarin de verdere verwerking van de index moet gebeuren. Te veel onderverdelingen maken, maakt de threads zodanig klein dat de tijdswinst verloren gaat. Daarom 2e heuristiek, die meet hoe lang het duurt om de 1000 documenten te verwerken, en aan de hand daarvan bepaalt hoeveel threads optimaal zou zijn voor de beste prestatie.
Zoals we hier kunnen zien geeft parallellisme hoe dan ook een sterke performantiewinst. In zijn niet-geoptimaliseerde vorm echter worden de snelle queries ietwat benadeeld. Dit wordt opgelost door heuristiek 1 dat bepaalt of een query al dan niet beter parallel verwerkt wordt door een hit-ratio van 1%. Op het eerste gezicht lijkt heuristiek 2 geen verbetering te zijn, integendeel zelfs, het is een fractie trager, maar wat deze figuur niet laat zien is dat het CPU-verbruik met deze heuristiek ruim 20% lager lag. Dit is dus een belangrijk uitgangspunt naar de toekomst toe om 'groenere' zoekmachines te bewerkstelligen.
![P arallellisme in Zoekmachines ,[object Object],1 Frederik Galle & Robin Ramael](https://image.slidesharecdn.com/cvt33final-091217100200-phpapp01/85/Communicatievaardigheden-parallelisme-in-zoekmachines-1-320.jpg)
![Inleiding: Het Semantisch Web ,[object Object],[object Object],[object Object],[object Object],2 Frederik Galle & Robin Ramael](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)