SQL-databasen dateres tilbage til 1970'erne og har været en ANSI-standard siden 1980'erne, men det betyder ikke, at teknologien sidder stille. Det ændrer sig stadig, og en af disse måder som GPU-accelererede databaser.
Relationsdatabaser er vokset i størrelse til datasæt, der måler i petabytes og derover. Selv med fremkomsten af 64-bit computing og terabyte hukommelse til øget behandling, er der stadig mange data at tygge igennem - og CPU'er kan kun styre så meget. Det er her GPU'er er kommet ind.
GPU'er har ændret sig fra deres oprindelige mission om at accelerere spil til at accelerere næsten alt. Nvidia har svingt mesterligt for at blive synonymt med kunstig intelligens, en proces der kræver store mængder data behandlet parallelt og andre opgaver, der kan paralleliseres godt. AMD begynder at spille catchup, men Nvidia har en lang føring.
Når det kommer til kerner, er det ikke engang tæt. Xeon-CPU'er har maksimalt 22 kerner. AMD Epyc har 32 kerner. Nvidia Volta-arkitekturen har 5.120 kerner. Forestil dig nu mere end 5.000 kerner, der kører parallelt på data, og det er klart, hvorfor GPU'er er blevet så populære til massive beregningsprojekter.
Så en ny klasse af databaser er opstået, skrevet fra bunden for at understøtte og omfavne GPU'er og deres massive parallelle behandlingsfunktioner. Disse databaser muliggør nye niveauer af databehandling, analyse og realtids Big Data, da de kan håndtere datasæt, som almindelige CPU-drevne databaser simpelthen ikke kan.
GPU-databasen defineret
Konceptet med en GPU-database er enkelt nok: Det bruger GPU'ernes parallelitet til at udføre massiv databehandlingsacceleration. GPU'en er ideel til at fremskynde behandlingen af SQL-forespørgsler, fordi SQL udfører den samme operation - normalt en søgning - på hver række i sættet.
Du placerer dog ikke bare en masse Nvidia Tesla-kort på serveren, der er vært for en Oracle-database. GPU-databaser er designet og skrevet fra bunden til at udføre parallel behandling, startende med SQL TILSLUTTE operationer.
TILSLUTTEs etablere et forhold mellem kolonner fra flere tabeller i en database og er afgørende for at udføre meningsfuld analyse. Traditionelle designtilgange til TILSLUTTEs på ældre RDBMS-systemer blev designet for mange år siden til single-core CPU'er og egner sig ikke godt selv til en CPU, langt mindre en GPU.
Ud over TILSLUTTEs, GPU-databaser har et betydeligt supportniveau, herunder:
- Stik til populære open source-rammer, såsom Hadoop, Kafka, HBase, Spark og Storm.
- ODBC- og JDBC-drivere til integration med eksisterende visualiserings- og BI-værktøjer som Tableau, Power BI og Spotfire
- API'er til bindinger med populære programmeringssprog som C ++, SQL, Java, Node.js og Python.
Hvor skal man bruge en GPU-database
I den henseende konkurrerer GPU-databaser ikke rigtig med Oracle, SQL Server eller DB2. GPU-databaser er orienteret mod at træffe beslutninger om dataanalyse, hvor virksomheder forsøger at træffe en beslutning i realtid fra store mængder data, men finder ud af, at de ikke er i stand til at gøre det, fordi der er for meget data, eller fordi visuelle analyseværktøjer er for langsomme.
GPU-databaseleverandørerne ser ikke sig selv som en erstatning for Oracle eller en OLTP-database som Teradata. I stedet for at målrette traditionelle RDBMS-arbejdsbelastninger sigter GPU-databaser mod OLAP / OLTP-verdenen og big data, hvor datasættene er enorme og behovet er i realtid. I stedet for batchprocesser, der køres over timer eller natten over, er GPU-databaser, hvor data kan præsenteres i realtid eller på timebasis.
GPU-databasen skal løse mange problemer, som NoSQL forsøger at løse, men lader dig bruge dine eksisterende strukturerede forespørgselsværktøjer. Brug af NoSQL betyder omskrivning af alle dine SQL-værktøjer, men GPU-databaser bruger eksisterende SQL-værktøjer.
”Det, vi tror, vi vil se, er, at folk er klar over, at de kan udføre multidimensionssystemer og tage data fra flere scenarier og kombinere dem,” siger Steve Worthington, nye teknologiløsningsarkitekt for Datatrend Technologies, et it-konsulentfirma, der bruger GPU-databasen SQream. "Medicinske virksomheder ønsker at tage [data] fra flere systemer og foretage analyser på tværs af databaser, fordi de tidligere ikke kunne krydse referencer og ikke havde nogen måde at slutte sig til databaserne."
Han citerer også finansielle institutioner, der laver bedrageri og risikoanalyse, der måske bare laver kreditkortchecks nu, men ønsker at foretage kontrol på tværs af flere konti. Med kraften fra GPU'en kan de krydshenvise på tværs af alle disse informationskilder på én gang.
For Rich Sutton, vicepræsident for geospatiale data hos Skyhook, en udbyder af placeringstjenester, der bruger OmniSci GPU-databasen, giver ham en meget større visualisering af geografiske datasæt, end han kunne gøre med en CPU-baseret database. ”Jeg kan indlæse en milliard rækker i OmniSci og med lidt eller ingen ventetid i stedet for at skulle se på et datasæt på 10.000 linjer i et traditionelt CPU-rum,” siger han. "Det er flere størrelsesordener, der er gavnlige for mig, hvilket reducerer forbruget af data med massivt reduceret ventetid."
Todd Mostak, administrerende direktør for OmniSci, siger, at en kunde fortalte ham, at OmniSci's hastighed “sænker omkostningerne ved nysgerrighed. De stiller spørgsmål, som de tidligere ville holde tilbage. ” En kunde af finansielle tjenester fortalte ham, at en 18-timers forespørgsel om behandling i en traditionel database gik ned til et sekundssekund, mens en telco fortalte ham, at forespørgsler, der tog timer at køre, nu svarede på under et sekund.
Et andet sted for GPU-databaser er i realtids big data, hvor Hadoop ikke er tilstrækkelig. Ami Gal, administrerende direktør for GPU-databaseleverandøren SQream, siger, at meget af løftet om big data - at finde alle de muligheder, der ligger i snesevis af petabytes af radedata - ikke blev opnået på Hadoop, fordi det var for langsomt.
“Gnist er ret godt til dataflytning og transformation, men når du først skal knuse enorme mængder data og flytte dem, begynder du at beskæftige dig med hundreder af tusinder af [beregne] noder, og det ses som for meget til at knuse i store datasæt. Men hvis du kan gøre det med ti eller 15 knudepunkter, er det meget mere effektivt, ”siger han.
Worthington siger, at GPU-baserede servere kan gøre i et kabinet, hvad der kræver mange kabinets værdi af CPU-drevne MPP-noder (multiple-parallel-processing). ”Vi kan erstatte stativer af MPP-noder med et halvt dusin noder, hver med to til fire GPU'er i dem. Med det kan vi erstatte en investering på 10 millioner dollars med under en investering på 1 million dollars, ”siger han.
GPU'en er også vigtig for Skyhook, som visualiserer store geografiske datasæt. “Hvis du har en million enheder i marken og en ping-placering et par gange i minuttet, taler du 2 milliarder datarækker om dagen. Det er umuligt at forbruge i en traditionel database. Det er bare ikke muligt. Så [a] GPU [database] bringer dig op til det sted, hvor du kan forbruge disse data, ”siger Sutton.
Før vedtagelsen af OmniSci skulle Skyhook "pyramidisere" data og kun tage segmenter af dem til visualisering. Nu siger Sutton, at det kan se på hele databilledet. "Jeg har aldrig set en anden realistisk måde at få data i form til min slags brug."
GPU-databaser: Hvad er tilgængeligt?
GPU-databaser er udelukkende et opstartsfænomen med virksomheder som Brytlyt, SQream Technologies, OmniSci, Kinetica, PG-Strom og Blazegraph.
Alle varierer lidt i, hvordan de fungerer. For eksempel foretager OmniSci visualisering af data, mens SQream bruger stik til visualiseringsværktøjer som Tableau, så hver enkelt skal evalueres individuelt for at bestemme den bedst egnede til dit behov.
De store navne i RDBMS er endnu ikke kommet om bord, bortset fra IBM, der understøtter noget GPU-behandling i DB2 Blu, en speciel version af DB2 til analytiske arbejdsbelastninger. Oracle og TeraData har begge sagt, at de arbejder med Nvidia, men der er ikke kommet noget af det endnu. Microsoft understøtter ikke GPU-acceleration på SQL Server. SQreams Gal sagde, at han har hørt, at alle RDBMS-leverandørerne arbejder på at tilføje en slags GPU-support til deres produkter, men havde ingen yderligere oplysninger.
