I detta dokument presenterar vi BlinkDB, en massivt parallell, ungefärlig frågemotor för att köra interaktiva SQL-frågor på stora volymer data. BlinkDB tillåter användare att handlao frågenoggrannhet för svarstid, vilket möjliggör interaktiva frågor över massiva data genom att köra frågor om dataprover och presentera resultat kommenterade med meningsfulla fel bars. För att uppnå detta använder BlinkDB två nyckelidéer: ( ) en adaptiv optimeringsram som bygger och upprätthåller en uppsättning multidimensionella strati ed prover från ursprungliga data över tid, och ( ) en dynamisk urvalsstrategi som väljer en lämplig storlek prov baserat på en fråga noggrannhet eller svarstiden krav. Vi utvärderar BlinkDB mot de välkända TPC-H-riktmärkena och en verklig analytisk arbetsbörda från Conviva Inc., ett företag som hanterar videodistribution över Internet. Våra experiment på en nod kluster visar att BlinkDB kan svara på frågor om upp till TBs data på mindre än sekunder (över × snabbare än Hive), inom ett fel av -. Moderna data analytics applikationer innebär att beräkna aggregat över ett stort antal poster för att rulla upp webbklick, online-transaktioner, innehåll nedladdningar, och andra funktioner längs en mängd olika olika dimensioner, inklusive demografi, innehållstyp, region, och så vidare. Traditionellt har sådana frågor utförts med hjälp av sekventiella genomsökningar över en stor del av en databas. I allt högre grad kräver nya tillämpningar nästan svarsfrekvenser i realtid. Exempel kan vara program som (i) uppdaterar annonser på en webbplats baserat på trender i sociala nätverk som Facebook och Twitter, eller (ii) bestämmer undergruppen av användare som upplever dålig prestanda baserat på deras tjänsteleverantör och / eller geografisk plats. Under de senaste två decennierna har ett stort antal approximativa tekniker föreslagits, som gör det möjligt för snabbt pro-Permission att göra digitala eller hårda kopior av hela eller delar av detta arbete för personligt eller klassrum användning beviljas utan avgift, förutsatt att kopior inte görs eller distribueras för vinst eller kommersiella fördelar och att kopior är märkta med detta meddelande och den fullständiga citeringen på första sidan. För att kopiera på annat sätt, för att återpublicera, för att posta på servrar eller för att omfördela till listor, krävs tidigare specifik behörighet och/eller avgift. April -, Tjeckien Copyright © ACM --- /....................................................................................... Dessa tekniker inkluderar provtagning [, ], skisser [ ], och on-line aggregering [ ]. För att illustrera nyttan av sådana tekniker, överväga följande enkla fråga som beräknar den genomsnittliga SessionTime över alla användare med ursprung i New York: SELECT AVG (SessionTime) FRÅN Sessions Where City = 'New York' Antag att Sessions tabellen innehåller miljoner tuples för New York, och inte kan t i minne. I så fall kan ovanstående fråga ta lång tid att köra, eftersom diskavläsningar är dyra, och en sådan fråga skulle behöva flera diskåtkomst för att strömma genom alla tuples. Antag att vi istället utförde samma fråga på ett prov som endast innehåller, New York tuples, så att hela provet ts i minnet. skulle vara storleksordningar snabbare, men ändå ge ett ungefärligt resultat inom några procent av det faktiska värdet, en noggrannhet tillräckligt bra för många praktiska ändamål. Med hjälp av provtagningsteorin skulle vi till och med kunna ge kondensgränser för exaktheten i svaret [ ]. Tidigare beskrivna approximationstekniker gör olika affärer mellan efficiency och generaliteten i de frågor som de stöder. I ena änden av spektrumet, befintliga provtagning och skissbaserade lösningar uppvisar lågt utrymme och tids komplexitet, men vanligtvis göra starka antaganden om frågebördan (t.ex., de antar att de vet uppsättningen av tuples nås av framtida frågor och aggregering funktioner som används i frågor). Som ett exempel, om vi vet att alla framtida frågor är på stora städer, skulle vi helt enkelt kunna behålla slumpmässiga prover som utelämnar data om mindre städer. I andra änden av spektrumet gör system som onlineaggregation (OLA) [ ] färre antaganden om frågebördan, på bekostnad av mycket varierande prestanda. Med hjälp av OLA, ovanstående fråga kommer sannolikt nish mycket snabbare för sessioner i New York (dvs, användaren kan vara nöjd med resultatet noggrannhet, när frågan ser rst, sessioner från New York) än för sessioner i Galena, IL, en stad med färre än, människor. I själva verket, för en sådan liten stad, OLA kan behöva läsa hela tabellen för att beräkna ett resultat med tillfredsställande fel gränser. I detta dokument hävdar vi att ingen av de tidigare lösningarna är en bra t för dagens big data analytics arbetsbörda. OLA Ordförande
BlinkDB REF upprätthåller en uppsättning offlinegenererade stratifierade prover genom att använda en fellatensprofil baserad på tidigare frågor.
BlinkDB: queries with bounded errors and bounded response times on very large data
{'venue': "EuroSys '13", 'journal': None, 'mag_field_of_study': ['Computer Science']}