Querying the Internet with PIER TDT2 Avanserte distribuerte systemer 17.10.2005 Truls Jørgensen Disposisjon 2
Hva er PIER? (1) Peer-to-Peer Information Exchange and Retrieval Paring av tradisjonell prosessering av databasequeries med ny p2pteknologi En distribuert query processor (QP) Bygd over en Distributed Hash Table (DHT) CAN, men har også blitt portet til Chord 3 Hva er PIER? (2) (Internett-) data prosesseres der de er lagret (in situ) uten noen intermediate database PIER ønsker å vise at query processing kan bli gjort i en massively distributed scale Krever ikke noen ekstensjon til underliggende DHT- APIet. PIER benytter wrappere til å aksessere til å aksessere data in situ (f.eks rene filer eller streams) Antar at alle peers bruker samme scheme for lagring av data 4
Relaxed Consistency ACID-egenskapene er ikke implementert i noe massivt distribuert system i dag Brewer: Et distribuert datasystem kan bare ha to av følgende egenskaper: Konsistens Tilgjengelighet Toleranse for nettverkspartisjoner. Distribuerte databaser velger konsistens fremfor tilgjengelighet PIER må ha høy tilgjengelighet, og ofrer derfor konsistens. Best effort på tilgjengelig subnett 5 Arkitektur Lag 1 - Applikasjoner Network monitoring Other user apps Lag 2 - PIER Query optimizer Catalog Manager Core Relational Execution Engine Lag 3 - DHT Overlay Routing Provider Storage Manager 6
Distribuerte hashtabeller Abstraksjon over flere distribuerte noder Hver node kan lagre data Hvert data item identifiseres med en unik nøkkel 7 CAN Content Adressable Network Basert på et d-dimensjonalt koordinatsystem. Hver node holder en routingtabell for sine naboer To noder er naboer hvis de deler et hyperplan med dimensjon d-1 Delt inn i soner. Hver node er ansvarlig for en sone En nøkkel hashes til et punkt i koordinatsystemet og lagres hos den ansvarlige noden 8
CAN - lookup (16,0) (16,12) (16,16) (12,12) (12,16) Key = (15,14) Data (0,0) (0,16) 9 DHT detaljer Overlay Routing Overlay Routing Provider Mapper en nøkkel til ipadressen til den noden som for øyeblikket er ansvarlig for nøkkelen Leverer et API for Lookup Å bli med i og forlate nettverket Sende notify når mappingen mellom noder og nøkler endres Lag 3 DHT Storage Manager 10
DHT detaljer Storage Manager Overlay Routing Provider Leverer så god ytelse at den ikke blir flaskehalsen i systemet. I PIER brukes en main memory storage manager. Leverer et API for Store(key, item) Retrieve(key) -> item Remove (key) Lag 3 DHT Storage Manager 11 DHT detaljer Provider Binder routing layer og storage manager sammen og tilbyr et interface til applikasjoner for begge Hvert objekt har et Namespace identifiserer applikasjonen den tilhører resourceid gir en semantisk mening til objektet eller primærnøkkel instanceid Overlay Routing tilfeldig tall satt av applikasjonen (skiller objekter med likt navnerom og resourceid, noe som kan oppstå dersom objektet ikke er lagret på primærnøkkel) API get(namespace, resourceid) -> item put(namespace,resouceid, instanceid, item, lifetime) renew(namespace,resourceid, instanceid,item, lifetime) -> bool multicast(namespace, resourceid, item) lscan(namespace) -> iterator newdata(namespace) -> item Lag 3 DHT Provider Storage Manager 12
Query Processor Støtter samtidig utførelse av operatorer som kan bli pipelinet Støtter seleksjon, projeksjon, gruppering, agreggering og distribuert join 13 Basert på eksisterende læreboklærdom om parallell join. To tabeller, R og S Lagret i henholdsvis navnerom N R og N S PIER lager midlertidige tabeller i navnerommet N Q 14
Symmetrisk Hash Join Hver node i N R og N S utfører en scan i sitt lokale navnerom for å finne alle R og S-tupler Hvert tuppel som tilfredstiller lokale seleksjonspredikater legges til N Q. I parallell på hver node Verdiene for for joinattributtene konkateneres slik at de danner resourceid (primærnøkkel) Matchende noder legges til og sendes oppover til den initierende prosessen 15 Fetch Matches Variant av Symmetrisk Hash Join Brukes når den ene tabellen, S, allerede er hashet på join-attributt(ene). N R scannes, og for hver R-tuppel sendes et getkall for å finne sammenfallende S-verdi. 16
Symmetrisk Semi-Join Forsøk på å redusere kommunikasjon (og båndbredde!) Projiserer bare ResourceID og join-nøklene Utfører en Symmetrisk Hash Join på resultatet Utfører deretter en Fetch Matches Join for å få hele tuppelet fra tabellen 17 Bloom Joins Bloomfiltre benyttes for å hente ut bare den de viktige delene av identifikatoren, og sparer båndbredde: Bloomfiltre opprettes for hvert fragment av S og R som finnes hos en node Filtrene publiseres i et temporært navnerom, før de blir multicastet til alle noder som har den motsatte tabellen Noden skanner sitt tilsvarende fragment, men rehasher kun de tuplene som matcher Bloomfilteret. 18
(1) Simulering over 10000 noder Ble testet på Full Mesh og Transit Stub-topologi Full Mesh topologi: Alle endepunkter kan nå alle andre direkte Ideal Enkel å simulere Transit Stub topologi: Typisk Internett Hierarkisk Vanskeligere å simulere Ingen stor forskjell ble funnet -> Full Mesh.. 19 (2) Transit stub Vs Full Mesh 20
(3) Mye avhenger av den underliggende DHT PIER skalerer bra så lenge antall noder er stort nok til å hindre network cognestion. Hver joinalgoritme ble testet med Uendelig båndbredde Begrenset båndbredde Tiden det tok til å motta det siste tuppelet ble valgt som metrikk 21 (4) Uendelig båndbredde Symmetrisk Hash Join raskest Begrenset båndbredde, høy selektivitetsfaktor Fetch Matches-join Symmetrisk Semi-Join Begrenset båndbredde, lav selektivitetsfaktor Symmetrisk Semi-join Bloom-join 22
(5) Fixed båndbredde -10Mbs SHJ bruker mest båndbredde rehashing av begge tabeller FM bruker omtrent konstant båndbredde- S-tuppelet må uansett hentes og evalueres, uansett hvor selektiv predikatet er I SSJ overfører den andre joinoperasjonen tuplene i S og R som matcher Trafikken øker linært med selektiviteten av S BF er god på lav selektivtet minsker rehashing av R Mange R-tupler har ikke noen S-tupler å joine med. 23