SQL datu bāze ir datēta ar pagājušā gadsimta 70. gadiem un ir bijusi ANSI standarts kopš 1980. gadiem, taču tas nenozīmē, ka tehnoloģija joprojām atrodas mierā. Tas joprojām mainās, un tas ir viens no GPU paātrinātu datu bāzu veidiem.
Relāciju datu bāzu apjoms ir pieaudzis līdz datu kopām, kas mēra petabaitus un ārpus tām. Pat ar 64 bitu skaitļošanas un terabaitu atmiņas parādīšanos, lai palielinātu apstrādi, tas joprojām ir daudz datu, ko sakošļāt - un CPU var pārvaldīt tikai tik daudz. Tur ir ienākuši GPU.
GPU ir pārveidojušies no sākotnējās spēļu paātrināšanas misijas līdz gandrīz visa paātrināšanai. Nvidia ir meistarīgi pagriezusies, lai kļūtu par mākslīgā intelekta sinonīmu - procesu, kas prasa lielu daudzumu paralēli apstrādātu datu un citus labi paralēlus uzdevumus. AMD sāk spēlēt panākumus, taču Nvidia ir gara vadība.
Kas attiecas uz kodoliem, tas pat nav tuvu. Xeon procesoros ir ne vairāk kā 22 kodoli. AMD Epyc ir 32 kodoli. Nvidia Volta arhitektūrā ir 5120 kodoli. Tagad iedomājieties, ka vairāk nekā 5000 kodolu darbojas paralēli datiem, un ir skaidrs, kāpēc GPU ir kļuvuši tik populāri masveida skaitļošanas projektiem.
Tātad ir izveidojusies jauna datu bāzu klase, kas ir uzrakstīta no paša sākuma, lai atbalstītu un aptvertu GPU un to milzīgās paralēlās apstrādes iespējas. Šīs datu bāzes nodrošina jaunu datu apstrādes, analīzes un reāllaika lielo datu līmeni, jo tās var apstrādāt datu kopas, kuras parastās ar CPU darbināmās datu bāzes vienkārši nevar.
Definēta GPU datu bāze
GPU datu bāzes koncepcija ir pietiekami vienkārša: tā izmanto GPU paralēlismu, lai veiktu masīvu datu apstrādes paātrinājumu. GPU ir ideāli piemērots SQL vaicājumu apstrādes paātrināšanai, jo SQL veic vienu un to pašu darbību - parasti meklēšanu - katrā kopas rindā.
Tomēr jūs vienkārši neievietojat virkni Nvidia Tesla karšu serverī, kurā atrodas Oracle datu bāze. GPU datu bāzes ir izstrādātas un rakstītas no paša sākuma, lai veiktu paralēlo apstrādi, sākot ar SQL PIEVIENOTIES operācijas.
PIEVIENOTIESs izveido saikni starp kolonnām no vairākām tabulām datu bāzē, un tām ir izšķiroša nozīme jēgpilnas analīzes veikšanā. Tradicionālās pieejas dizainam PIEVIENOTIESPar mantotajām RDBMS sistēmām pirms gadiem tika izstrādāti viena kodola procesori, un tās nav piemērotas pat procesoram, vēl jo vairāk GPU.
Tālāk PIEVIENOTIESGPU datubāzēm ir ievērojams atbalsta līmenis, tostarp:
- Savienotāji populārām atvērtā koda sistēmām, piemēram, Hadoop, Kafka, HBase, Spark un Storm.
- ODBC un JDBC draiveri integrācijai ar esošajiem vizualizācijas un BI rīkiem, piemēram, Tableau, Power BI un Spotfire
- API saitēm ar populārām programmēšanas valodām, piemēram, C ++, SQL, Java, Node.js un Python.
Kur izmantot GPU datu bāzi
Šajā ziņā GPU datu bāzes īsti nekonkurē ar Oracle, SQL Server vai DB2. GPU datubāzes ir orientētas uz datu analīzes lēmumu pieņemšanu, kur uzņēmumi mēģina pieņemt lēmumu reāllaikā no milzīga datu apjoma, bet uzskata, ka nespēj to izdarīt, jo datu ir pārāk daudz vai vizuālās analīzes rīki ir pārāk lēni.
GPU datu bāzes piegādātāji neuzskata sevi par Oracle aizstājēju vai OLTP datu bāzi, piemēram, Teradata. Tā vietā, lai mērķētu uz tradicionālajām RDBMS slodzēm, GPU datu bāzes ir vērstas uz OLAP / OLTP pasauli un lielajiem datiem, kur datu kopas ir masīvas un nepieciešamība ir reāllaika. Tā vietā, lai sērijveida procesi notiktu stundām vai nakti, GPU datu bāzes ir tās, kur datus var uzrādīt reāllaikā vai stundā.
GPU datu bāzei vajadzētu atrisināt daudzas problēmas, kuras mēģina atrisināt NoSQL, bet ļauj izmantot esošos strukturētos vaicājumu rīkus. NoSQL izmantošana nozīmē visu savu SQL rīku pārrakstīšanu, bet GPU datu bāzēs tiek izmantoti esošie SQL rīki.
"Tas, ko mēs domājam, ka redzēsim, ir cilvēki, kuri saprot, ka viņi var veikt daudzdimensiju sistēmas, ņemt datus no vairākiem scenārijiem un tos apvienot," saka Stīvs Vērttons, jauno tehnoloģiju risinājumu arhitekts Datatrend Technologies, IT konsultāciju birojam, kas izmanto GPU datu bāzi SQream. "Medicīnas kompānijas vēlas ņemt [datus] no vairākām sistēmām un veikt analīzi visās datu bāzēs, jo iepriekš tās nevarēja veikt savstarpējas atsauces un nebija iespējas pievienoties datu bāzēm."
Viņš arī min finanšu iestādes, kas veic krāpšanu un riska analīzi, kuras, iespējams, tagad veic tikai kredītkaršu pārbaudes, bet vēlas veikt pārbaudes vairākos kontos. Izmantojot GPU, viņi vienlaikus var savstarpēji atsaukties uz visiem šiem informācijas avotiem.
Ričam Satonam, atrašanās vietas pakalpojumu sniedzēja Skyhook ģeotelpisko datu viceprezidentam, izmantojot OmniSci GPU datu bāzi, viņš iegūst daudz lielāku ģeogrāfisko datu kopu vizualizāciju, nekā viņš varētu darīt ar CPU balstītu datu bāzi. "Es varu ielādēt miljardu rindu OmniSci un ar nelielu vai bez latentuma laiku, tā vietā, lai tradicionālajā CPU telpā būtu jāaplūko datu kopa ar 10 000 līnijām," viņš saka. "Tas ir daudzkārtīgi lielumi, kas man ir izdevīgi, samazinot datu patēriņu ar ievērojami samazinātu latentumu."
Tods Mostaks, OmniSci izpilddirektors, saka, ka viens klients viņam teicis, ka OmniSci ātrums “pazemina ziņkārības izmaksas. Viņi uzdod jautājumus, kurus iepriekš atturētu. ” Viens finanšu pakalpojumu klients viņam teica, ka 18 stundu apstrādes vaicājums tradicionālajā datu bāzē sasniedza sekundi, savukārt telekomunikācija viņam teica, ka vaicājumi, kuru izpildei vajadzēja stundas, tagad atbild sekundē.
Vēl viena vieta GPU datu bāzēm ir reāllaika lielie dati, kur Hadoop ir pietrūcis. GPU datu bāzes nodrošinātāja SQream izpilddirektors Ami Gal saka, ka liela daļa lielo datu solījumu - atrast visas iespējas, kas atrodas desmitos petabaitu rindu datu, netika sasniegta Hadoop, jo tas bija pārāk lēns.
“Spark ir diezgan labs datu kustībai un pārveidošanai, bet, kad jums ir nepieciešams sakraut milzīgu datu daudzumu un tos pārvietot, jūs sākat tikt galā ar simtiem tūkstošu [skaitļošanas] mezglu, un tas tiek uzskatīts par pārāk daudz, lai grieztos lielās datu kopās. Bet, ja to var izdarīt ar desmit vai 15 mezgliem, tas ir daudz efektīvāk, ”viņš saka.
Worthington saka, ka GPU bāzes serveri vienā kabinetā var darīt to, kas prasa daudzu skapju CPU darbināmu vairāku paralēlu apstrādi (MPP) mezglus. “Mēs varam aizstāt MPP mezglu plauktus ar pusduci mezglu, katrā no tiem ir divi līdz četri GPU. Ar to mēs varam aizstāt ieguldījumus 10 miljonu ASV dolāru apmērā ar mazāk nekā USD 1 miljonu, ”viņš saka.
GPU ir svarīgs arī Skyhook, kas vizualizē lielas ģeogrāfiskās datu kopas. “Ja jums laukā un pingēšanas vietā pāris reizes minūtē ir miljons ierīču, jūs runājat par 2 miljardiem datu rindu dienā. To nav iespējams patērēt tradicionālajā datu bāzē. Tas vienkārši nav iespējams. Tātad [a] GPU [datu bāze] aizved jūs tur, kur jūs varat patērēt šos datus, ”saka Satons.
Pirms OmniSci ieviešanas Skyhook vajadzētu “piramidizēt” datus, vizualizēšanai ņemot tikai to segmentus. Tagad Satons saka, ka tas var apskatīt visu datu attēlu. "Es nekad neesmu redzējis vēl vienu reālistisku veidu, kā iegūt datus atbilstoši savam lietojumam."
GPU datu bāzes: kas ir pieejams
GPU datubāzes ir pilnīgi startēšanas parādība, ar tādiem uzņēmumiem kā Brytlyt, SQream Technologies, OmniSci, Kinetica, PG-Strom un Blazegraph.
Visi nedaudz atšķiras pēc to darbības veida. Piemēram, OmniSci veic datu vizualizāciju, savukārt SQream izmanto savienotājus ar vizualizācijas rīkiem, piemēram, Tableau, tāpēc katrs no tiem ir jānovērtē atsevišķi, lai noteiktu vispiemērotāko jūsu vajadzībām.
Lielie vārdi RDBMS vēl nav iekļauti, izņemot IBM, kas atbalsta dažas GPU apstrādi DB2 Blu, kas ir īpaša DB2 versija analīzes darba slodzēm. Oracle un TeraData abi ir teikuši, ka viņi strādā ar Nvidia, taču nekas vēl nav izdevies. Microsoft neatbalsta GPU paātrinājumu SQL Server. SQream’s Gal teica, ka ir dzirdējis, ka visi RDBMS pārdevēji strādā, lai saviem produktiem pievienotu sava veida GPU atbalstu, taču viņiem nebija papildu informācijas.
