SQL-databasen dateres tilbake til 1970-tallet og har vært en ANSI-standard siden 1980-tallet, men det betyr ikke at teknologien sitter stille. Det er fortsatt i endring, og en av disse måtene som GPU-akselerert databaser.
Relasjonsdatabaser har vokst i størrelse til datasett som måler i petabyte og utover. Selv med fremveksten av 64-biters databehandling og terabyte minne for økt prosessering, er det fremdeles mye data å tygge gjennom - og CPUer kan bare administrere så mye. Det er her GPUer har kommet inn.
GPU-er har gått fra sitt opprinnelige oppdrag om å akselerere spill til å akselerere nesten alt. Nvidia har svingt mesterlig for å bli synonymt med kunstig intelligens, en prosess som krever store mengder data som behandles parallelt og andre oppgaver som kan parallelliseres godt. AMD begynner å spille innhenting, men Nvidia har lang ledelse.
Når det gjelder kjerner, er det ikke en gang i nærheten. Xeon-prosessorer har maksimalt 22 kjerner. AMD Epyc har 32 kjerner. Nvidia Volta-arkitekturen har 5.120 kjerner. Tenk deg nå mer enn 5000 kjerner som kjører parallelt på data, og det er klart hvorfor GPU-er har blitt så populære for store databehandlingsprosjekter.
Så en ny klasse med databaser har dukket opp, skrevet fra grunnen av for å støtte og omfavne GPUer og deres massive parallelle prosesseringsmuligheter. Disse databasene muliggjør nye nivåer av databehandling, analyse og sanntids Big Data, ettersom de kan håndtere datasett som vanlige CPU-drevne databaser rett og slett ikke kan.
GPU-databasen definert
Konseptet med en GPU-database er enkelt nok: Den bruker parallelliteten til GPUer for å utføre massiv akselerasjon av databehandling. GPUen er ideell for å akselerere prosessering av SQL-spørsmål fordi SQL utfører den samme operasjonen - vanligvis et søk - på hver rad i settet.
Imidlertid legger du ikke bare en haug med Nvidia Tesla-kort på serveren som er vert for en Oracle-database. GPU-databaser er designet og skrevet fra grunnen av for å utføre parallell behandling, startende med SQL BLI MED operasjoner.
BLI MEDs etablere et forhold mellom kolonner fra flere tabeller i en database og er avgjørende for å utføre meningsfull analyse. Tradisjonelle designtilnærminger for BLI MEDs på eldre RDBMS-systemer ble designet for mange år siden for enkeltkjerne-prosessorer og egner seg ikke godt til og med til en CPU, enda mindre en GPU.
Bortenfor BLI MEDs, GPU-databaser har et betydelig nivå av støtte, inkludert:
- Koblinger til populære open source-rammer, som Hadoop, Kafka, HBase, Spark og Storm.
- ODBC- og JDBC-drivere for integrering med eksisterende visualiserings- og BI-verktøy som Tableau, Power BI og Spotfire
- API-er for bindinger med populære programmeringsspråk som C ++, SQL, Java, Node.js og Python.
Hvor du skal bruke en GPU-database
I den forbindelse konkurrerer ikke GPU-databaser egentlig med Oracle, SQL Server eller DB2. GPU-databaser er orientert mot å ta dataanalysebeslutninger, der bedrifter prøver å ta en beslutning i sanntid fra store mengder data, men ikke klarer å gjøre det fordi det er for mye data eller fordi visuelle analyseverktøy er for sakte.
GPU-databaseleverandørene ser ikke på seg selv som erstatning for Oracle eller en OLTP-database som Teradata. I stedet for å målrette tradisjonelle RDBMS-arbeidsbelastninger, retter GPU-databaser seg mot OLAP / OLTP-verdenen og stordata, der datasettene er enorme og behovet i sanntid. I stedet for batch-prosesser som kjøres over timer eller over natten, er GPU-databaser der data kan presenteres i sanntid eller på timebasis.
GPU-databasen skal løse mange problemer som NoSQL prøver å løse, men lar deg bruke de eksisterende strukturerte søkeverktøyene dine. Å bruke NoSQL betyr å skrive om alle SQL-verktøyene dine, men GPU-databaser bruker eksisterende SQL-verktøy.
"Det vi tror vi vil se, er at folk innser at de kan gjøre flerdimensjonssystemer og ta data fra flere scenarier og kombinere det," sier Steve Worthington, nye teknologiløsningsarkitekt for Datatrend Technologies, et IT-konsulentselskap som bruker GPU-databasen SQream. "Medisinske selskaper ønsker å ta [data] fra flere systemer og gjøre analyser på tvers av databaser, for før kunne de ikke kryssreferanser og hadde ingen måte å bli med i databasene."
Han siterer også finansinstitusjoner som gjør svindel og risikoanalyse som kanskje bare gjør kredittkortsjekker nå, men vil gjøre sjekker på flere kontoer. Med kraften fra GPU kan de kryssreferanse på tvers av alle disse informasjonskildene samtidig.
For Rich Sutton, visepresident for geospatiale data hos Skyhook, en leverandør av lokasjonstjenester, som bruker OmniSci GPU-databasen, gir ham en mye større visualisering av geografiske datasett enn han kunne gjort med en CPU-basert database. "Jeg kan laste en milliard rader i OmniSci og med liten eller ingen ventetid i stedet for å måtte se på et datasett på 10.000 linjer i et tradisjonelt CPU-rom," sier han. "Det er flere størrelsesordener som er gunstig for meg, noe som reduserer forbruket av data med betydelig redusert ventetid."
Todd Mostak, administrerende direktør i OmniSci, sier at en kunde fortalte ham at hastigheten til OmniSci “senker nysgjerrighetskostnadene. De stiller spørsmål de tidligere ville holde igjen. ” En finansiell kunde fortalte ham at en 18-timers prosesseringsforespørsel på en tradisjonell database gikk ned til et sekundssekund, mens en telekommunikasjon fortalte ham at spørsmål som det tok timer å kjøre, svarer på under et sekund.
Et annet sted for GPU-databaser er sanntids big data, der Hadoop har kommet til kort. Ami Gal, administrerende direktør for GPU-databaseleverandøren SQream, sier mye av løftet om big data - å finne alle mulighetene som ligger i titalls petabytes med raddata - ble ikke oppnådd på Hadoop fordi det var for sakte.
“Gnist er ganske bra for databevegelse og transformasjon, men når du trenger å knuse store mengder data og flytte dem, begynner du å håndtere hundretusenvis av [beregne] noder, og det blir sett på som for mye å knase i store datasett. Men hvis du kan gjøre det med ti eller 15 noder, er det mye mer effektivt, sier han.
Worthington sier at GPU-baserte servere kan gjøre i ett kabinett, noe som krever mange kabinettverdier av CPU-drevne MPP-noder (multiple-parallel-processing). “Vi kan erstatte stativer med MPP-noder med et halvt dusin noder, hver med to til fire GPUer. Med det kan vi erstatte en investering på 10 millioner dollar med under en investering på 1 million dollar, sier han.
GPU er også viktig for Skyhook, som visualiserer store geografiske datasett. “Hvis du har en million enheter i felten og pingesteder et par ganger i minuttet, snakker du 2 milliarder datarader om dagen. Det er umulig å konsumere i en tradisjonell database. Det er bare ikke mulig. Så [a] GPU [database] bringer deg dit du kan konsumere dataene, sier Sutton.
Før SkyNook adopterte OmniSci, måtte hun "pyramidisere" data, og bare ta segmenter av dem for visualisering. Nå, sier Sutton, kan den se på hele databildet. "Jeg har aldri sett en annen realistisk måte å få data i form for min bruk."
GPU-databaser: Hva er tilgjengelig
GPU-databaser er helt et oppstartsfenomen, med selskaper som Brytlyt, SQream Technologies, OmniSci, Kinetica, PG-Strom og Blazegraph.
Alle varierer litt i hvordan de fungerer. For eksempel gjør OmniSci visualisering av data, mens SQream bruker kontakter til visualiseringsverktøy som Tableau, slik at hver enkelt må evalueres individuelt for å finne den beste passformen for dine behov.
De store navnene i RDBMS har ennå ikke kommet ombord, med unntak av IBM, som støtter noe GPU-prosessering i DB2 Blu, en spesiell versjon av DB2 for analytiske arbeidsbelastninger. Oracle og TeraData har begge sagt at de jobber med Nvidia, men ingenting har kommet til det ennå. Microsoft støtter ikke GPU-akselerasjon på SQL Server. SQream’s Gal sa at han har hørt at alle RDBMS-leverandørene jobber for å legge til en slags GPU-støtte til produktene sine, men hadde ingen ytterligere informasjon.
