Av Techopedia Staff, 8. juni 2016
Takeaway: Vert Eric Kavanaugh diskuterer innovasjoner innen databaseteknologi med ekspertene Dez Blanchfield, Robin Bloor og Bert Scalzo.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, det er onsdag klokka fire østlige. Jeg er i New Orleans, sommeren kommer, det betyr at den er varm! Det er på tide med Hot Technologies, ja, ja. Jeg heter Eric Kavanagh, jeg vil være verten din. Jeg kommer til å sparke ballen tilbake for Hot Technologies. Temaet i dag er “Forward Momentum: Moving Relational Beyond Traditional.” Folkens, vi har tre databaseeksperter på telefon i dag, så alle spørsmål du har, send dem de harde, ikke vær sjener. Vi har en haug med godt innhold stilt opp for deg i dag. Det er stedet om ditt virkelig, nok om meg. I år er det selvfølgelig varmt. Vi snakker om varme teknologier i dette showet, som er et samarbeid med våre venner fra Techopedia. Og vi går helt ned til grunnlaget for informasjonsstyring i dag, som selvfølgelig er databasen. Vi skal snakke om hvordan vi kom hit, hva som skjer i dag og hva som skjer fremover. Mange veldig interessante ting som skjer.
Det er klart at vi har en seriøs innovasjon på databasen. Det var litt stille en stund; Hvis du snakker med noen av analytikerne i virksomheten, vil jeg si fra år til, 2005 til 2009 eller '10, det virket ikke som om det skjedde for mye når det gjelder innovasjon. Og plutselig brøt det bare ut, som et fengsel eller noe, og nå skjer det alle slags interessante ting. Mye av det skyldes nettets omfang, og alle de kule webegenskapene som gjør forskjellige interessante ting. Det var her NoSQL-konseptet kom fra. Og det betyr to forskjellige ting: det betyr ingen SQL, som i den ikke støtter SQL, det betyr også ikke bare SQL. Det er et begrep “NewSQL” som noen mennesker har brukt. Men åpenbart er SQL - det strukturerte spørrespråket - virkelig grunnlaget, det er grunnlaget for spørring.
Og det er interessant at alle disse NoSQL-motorene, hva skjedde? De kom ut, det var mye spenning med det, og så noen år senere, hva begynte vi alle å høre? Å, SQL på Hadoop. Vel, alle disse selskapene begynte å smelle SQL-grensesnitt på NoSQL-verktøyene sine, og alle som er i programmeringsverdenen vet at det vil føre til noen utfordringer og noen vanskeligheter, og noen kryssede ledninger og så videre. Så vi kommer til å finne ut av mye av det i dag.
Det er de tre presentatørene våre: Vi har fått Dez Blanchfield til å ringe inn fra Sydney, vår helt egen Robin Bloor som er i Texas, og det samme er Bert Scalzo, han er også i Texas. Så først av alt får vi høre fra Dez Blanchfield. Folkens, vi vil tweete på hashtaggen til #HotTech, så send gjerne dine kommentarer, eller send spørsmålene dine gjennom spørsmål og svar-komponenten i webcast-konsollen, eller til og med gjennom chat-vinduet. Og med det, Dez Blanchfield, ta den bort.
Dez Blanchfield: Takk, Eric. Hei alle sammen. Så jeg skal prøve å sette scenen på et 30.000 fot synspunkt av hva som skjedde det siste tiåret, og de betydelige skiftene vi har sett - eller minst et og et halvt tiår uansett - av databasehåndteringssystemer, og noen av virkningene fra et kommersielt eller teknisk synspunkt, og noen av trendene vi har tålt sent, og fører oss inn i samtalen vi skal føre i dag rundt emnet.
Coveret mitt her er en sanddyne, og det blåser små biter av små sand på toppen av den. Og som et resultat av det, skjer det at sanddyne sakte går fra det ene rommet til det andre. Og det er et fantastisk fenomen, hvor disse massive 40- og 50 fot høye fjellene av sand, effektivt, de faktisk beveger seg. Og de beveger seg veldig sakte, men de beveger seg sikkert, og når de beveger seg, endrer de landskapet. Og det er ganske noe å se på hvis du i det hele tatt tilbringer tid i et område der sanddyner er en naturlig ting. Fordi du kan se ut av vinduet en dag og innse at dette massive fjellet med sand, små bittesmå korn har beveget seg av seg selv, i kraft, og at vinden sakte forskyver det fra et sted til et annet.
Og jeg tror på mange måter, det har vært en verden av databasesystemer i ganske lang tid. Inntil veldig, ganske nylig, det veldig lille skiftet i form av sandkorn som beveger et gigantisk fjell av sand i form av en sanddyne. Det har kommet små skift i databaseplattformene gjennom tidene, og det har vært et ganske stabilt og solid miljø rundt databasesystemer og plattformer, gjennom hovedrammen i mellomtonen. Men på sent har vi hatt noen ganske betydningsfulle ting som skjer med våre kommersielle behov og våre tekniske drivere. Jeg kommer til å gå oss gjennom disse.
Jeg har en oppfatning om at det grunnleggende konseptet for en database, slik vi kjente den i mange, mange år, og som du kanskje har hørt i før-show-skjebnen, hadde våre to eksperter som er på samtalen med meg i dag en levetid i denne plassen, og de har helt rett i å dele skrytbare rettigheter til å være der når det hele startet på begynnelsen av 80-tallet. Men vi har sett dette enorme skiftet i løpet av det siste tiåret og litt, og jeg skal raskt gå gjennom oss før jeg overlater det til Dr. Robin Bloor.
Vi har vært igjennom dette jeg kaller, "større, bedre, raskere, billigere" opplevelse. Som sagt har definisjonen av en database endret seg. Landskapet som databaseplattformene har hatt for å møte ytelse, og tekniske og kommersielle krav har også endret seg. Vi har sett denne økningen i etterspørselen etter løsninger for å håndtere enten mer komplekse kommersielle eller mer komplekse tekniske krav. Og så en veldig rask titt gjennom hva det faktisk betyr, i mitt sinn, er at vi måtte sortere på 90-tallet, og vi så databaseteknologi påvirket av introduksjonen av internett, og slags hva vi kalte tilbake da internett skala. Vi snakket ikke bare om folk som satt foran terminaler, opprinnelig slike som teletype-terminaler med fysiske skrivere innebygd i dem og 132 kolonner med tekst som kommer ut i papir. Deretter de tidlige grønne skjermterminalene, stansing med tastaturer.
Men du vet, vår verden var terminaler og seriekabler eller nettverkskabler som snakket til datamaskiner i lang tid. Så kom internett, og denne eksplosive veksten av tilkoblingsmuligheter, at du ikke trenger å være koblet til datamaskinen lenger. For å komme til et databasesystem trengte du bare en nettleser. Så databaseteknologi måtte endre seg dramatisk for å håndtere omfanget av alt fra de grunnleggende søkemotorteknologiene som ble brukt til å indeksere verden, og lagre en indeks med informasjon, i eksempelet med databaseformatskala. Og folk som Google og andre ga en plattform for å gjøre det. Og alle nye typer databaselagring og spørring og indeksering ble produsert. Og så hadde vi musikksider og filmsider kommet med.
Og så på 2000-tallet så vi dot-com-boom, og som ga en enda mer dramatisk eksplosjon i antall mennesker som bruker systemer som alltid ble drevet av en database av en eller annen form. Dette stadiet, relasjonsdatabaser som fremdeles taklet mesteparten av belastningen, vi la dem bare på større tinn, og vi gikk til de veldig, veldig, veldig store mellomtonesystemene som kjører Unix-plattformer fra folk som IBM og Sun og så videre . Dot-com boom gjorde tingene større og raskere fra en maskinvare, ytelsessynspunkt, og det var noen betydelige endringer i databasemotorene, men for den bedre del var det fortsatt det samme vi hadde sett for en lang tid.
Og så fikk vi denne epoken av web 2.0, som vi refererer til den. Og dette var et uhyrlig skifte, fordi vi plutselig trengte mye enklere databaseplattformer, og det måtte være en skala i horisontal form. Og det var et så betydelig skifte i måten at vi nærmet ideen om hva en database var. Vi henter fortsatt virkelig nå nå etter mitt syn. Og nå har vi å gjøre med hele denne quagmire, og jeg sier at med et positivt spinn, ikke en negativ konnotasjon, dette quagmire av det vi omtaler som big data, og en enorm eksplosjon, og jeg mener eksplosjon. Dette skandaløse skiftet vertikalt på grafen over antall alternativer vi har når vi snakker om en database, og en eller annen form for relasjonell spørringsevne.
Og interessant nok er jeg personlig av den oppfatning at jeg tror at big data egentlig bare er toppen av isfjellet. Vi har en tendens til å bli litt begeistret for hva virkningen av big data har vært, og hvilke valg vi har tilgjengelig nå. Vi har alt fra NoSQL-motorer, vi har grafmotorer, vi har alle disse forskjellige plattformene som vi kan kaste data på og gjøre ting med det. Selv til det punktet hvor faktisk en av de aller første samtalene jeg hadde med Eric Kavanagh, som er her med oss i dag, dreide seg om en samtale knyttet til en ting som heter Apache Drill, som er et åpen kildekode-prosjekt som lar deg spørre data inne i modeller forskjellige datatyper: alt fra rå CSE-filer som sitter på en harddisk, til HDFS-filsystemer i petabyte skala. Og du vet, det lar deg gjøre disse spørsmålene i SQL-stil med strukturerte og ustrukturerte data om alle slags spennende planter.
Vi er i ferd med å se "smart bygning" bli en ting, og vi vil gjerne tro at vi har smarte bygninger med sikkerhet og varmestyring, men jeg snakker om smarte bygninger som vet mye mer om hvem du er og hvor du er når du går inn og gjør alle slags pene ting på det nivået, til smarte byer - hele økosystemer på bynivå - som vet hvordan du gjør ting intelligent. Og utover det har vi fått til denne utrolige tingen som jeg ikke tror noen i verden fullt ut har forstått, og det er formen for tingenes internett. Det har skjedd alle disse forskjellige endringene i løpet av det siste tiåret og litt, kanskje to tiår, hvis vi avrunder det, som etter min mening har påvirket verden av det vi anser som databaser.
Det har vært et par viktige ting som har gjort dette enda mulig. Kostnaden for harddisker har falt dramatisk, og det er på mange måter det som gjorde det mulig å drive noen av referansearkitekturene som Hadoop-modellen, ved at vi tar masse data og sprer den ut på mange harddisker, og gjør smarte ting med det. Og i virkeligheten, det som etter mitt syn ble avskåret av den relasjonsdatabase eller tradisjonelle DB-enhetsmodell. Og RAM ble veldig, veldig billig, og det ga oss en helt ny mulighet til å leke med forskjellige referansearkitekturer som in-memory, og å gjøre ting som å dele opp veldig, veldig store klumper med data.
Og dette ga oss dette lille bildet som vi ser på nå, som er et diagram som viser hvilke typer plattformer som er tilgjengelige hvis du er i big data-landskapet. Og det er veldig, veldig vanskelig å lese, og grunnen til det, det er bare for mye informasjon om det. Det er så mange muligheter for å lage, modellere og produsere måter å sette data inn i databasesystemer av hvilken som helst form, og spørre dem om, og gjøre de tradisjonelle leseskrivningene. Og de er ikke alle kompatible, faktisk er det veldig få av dem som til og med overholder noen grunnleggende stilstandard, men de anser seg fortsatt som en database. Og jeg skal vise deg et par skjermer i løpet av et sekund for å gi deg litt kontekst rundt hva jeg mener med skiftet fra 90-tallet og internett-skalaen, til web 2.0, og deretter hele veksten gjennom big data. Hvis vi synes at dette landskapet med stor datateknologi er spennende fordi det er mange alternativer på det, la oss bare se på en nøkkel vertikal.
La oss se på markedsføringsteknologi. Her er alternativene for databestyringssystemer, eller datahåndtering på bare mar-tech-plassen, så teknologi relatert til markedsføring. Nå var dette i 2011, så for noen år siden; for fem år siden var det slik landskapet så ut. Hvis jeg bare går tilbake et lysbilde kort, er det slik dagens datalandskap ser ut i de forskjellige merkene og tilbudene vi har innen databaseteknologier. Slik så en vertikal ut for fem år siden, bare innen markedsføringsteknologi.
Hvis jeg går til dagens syn, er det slik det ser ut, og det er helt ugjennomtrengelig. Det er bare denne veggen av merker og alternativer, og det er tusenvis og tusenvis av kombinasjoner av programvare som anser seg for å være i databaseklassen, som den kan fange, opprette eller lagre og hente data i forskjellige former. Og jeg tror vi går inn i en veldig, veldig interessant og modig tid nå, hvor du en gang kunne kjenne de store merkene, kan du kjenne de fem eller seks forskjellige plattformene fra Oracle og Informix, DB2 og så videre, og være nesten en ekspert på alle merkene som var tilgjengelige for 20 år siden. For ti år siden ble det litt enklere fordi noen av merkene falt av, og ikke alle merkene kunne takle omfanget av dot-com-boom, og noen selskaper gikk bare i stykker.
I dag er det absolutt umulig å være ekspert på all databaseteknologien som finnes, enten det er relasjonsdatabaser, eller standard databasestyringsplattformer som vi har blitt kjent med i løpet av de siste tiårene. Eller sannsynligvis tilfelle, jo mer moderne motorer som Neo4j og de typene. Og så jeg tror vi inngår i en veldig modig verden der mange alternativer er tilgjengelige, og vi har plattformer i skala på horisontal basis, enten i minnet eller på disk nå. Men jeg synes det er en utfordrende tid for beslutningstakere innen teknologi og virksomhet, fordi de trenger å ta noen veldig store beslutninger om teknologibunker, som i noen tilfeller bare har eksistert i hovedsak måneder. Atten måneder gammel er ikke noe skummelt tall nå for noen av de mer spennende og nye open source databaseplattformene. Og de begynner å slå sammen plattformer og blir enda nyere og mer spennende.
Jeg tror vi kommer til å ha en god samtale i dag om hvordan alt dette har påvirket de tradisjonelle databaseplattformene og hvordan de reagerer på det, og hvilke typer teknologier som kastes mot det. Og med det i bakhodet, skal jeg nå videre til Dr. Robin Bloor, og få hans innsikt. Robin, over til deg.
Robin Bloor: Ok, takk for det. Ja, dette er altfor stort tema. Jeg mener, hvis du bare tok en del av en av illustrasjonene som Dez nettopp viste deg, kan du ha en lang samtale omtrent en av slivene. Men du vet, du kan gå i en database - jeg har sett på databaser, jeg vet ikke, siden 1980-tallet, og du kan se på databasen på forskjellige måter. Og en av tingene som jeg regnet med at jeg ville gjøre, bare kaste inn i samtalen i dag, var å snakke om årsaken til at forstyrrende ting har skjedd på maskinvarenivå. Og du må huske på at det har skjedd utrolig mange forstyrrende ting på programvarenivå, så dette er ikke det fulle bildet av noe, dette er bare en maskinvare-ting.
Jeg hadde ikke tenkt å snakke særlig lenge heller, jeg ville bare gi deg maskinvarebildet. En database var datainnhentingsfunksjoner som spenner over CPU, minne og disk, og det endrer seg dramatisk. Og grunnen til at jeg sier det, var at jeg lærte å forstå databasen fra perspektivet til hva du faktisk gjorde. Du vet, det er en forskjell i latenstid mellom data som faktisk er på CPU-en, og data som blir trukket inn i CPU fra minnet, og data som blir trukket fra disk til minne, og gjennom CPU. Og de gamle databasearkitekturene prøvde bare å balansere det. Du sa, de sa bare: “Vel, dette går veldig tregt, vi vil lagre dataene på disken slik at de er i minnet. Vi vil prøve å gjøre det på en virkelig nøyaktig måte slik at en virkelig god andel av dataene vi ber om allerede er i minnet. Og vi vil marsjere dataene til CPU så raskt vi faktisk kan. "
Og databaser ble skrevet i gamle dager maskiner er skrevet for små klynger. Og nå, for uvitende om parallellisme. For hvis du skal få litt ytelse ut av en klynge, må du gjøre forskjellige ting parallelt. Parallellisme er en del av spillet, ingenting som det er nå. Jeg vil bare gå gjennom det som skjedde.
Først av alt, disk. Vel, disken er over, egentlig. Det er ganske mye over databaser. Jeg tror det er en rekke sammenhenger med arkivering av data, og til og med veldig store datasjøer som kjører på Hadoop, er den verste spinnende disken sannsynligvis levedyktig i dag. Problemet med spinningsdisken var egentlig at lesehastighetene ikke forbedret seg særlig mye. Og når CPU skulle øke Moores lovhastigheter, slags størrelsesorden, raskere hvert sjette år. Og minnet fulgte litt etter i kjølvannet, da holdt de to rimelig i takt med hverandre, det var ikke helt glatt, men de gjorde det.
Men den tilfeldige lese til en disk der hodet flyr rundt disken, mener jeg, bortsett fra alt annet, er det en fysisk bevegelse. Og hvis du foretar tilfeldige avlesninger fra en disk, er det utrolig tregt i forhold til lesing fra minnet, det er som 100 000 ganger tregere. Og ganske nylig har faktisk de fleste av databasearkitekturene jeg har sett på i noen dybde, nettopp lest seriell fra disker. Du vil virkelig, på en eller annen måte, bare buffer så mye du kan fra disken, og dra den av den langsomme enheten og legg den på en rask enhet. Og det er mange smarte ting du kan gjøre med det, men det er litt over.
Og solid-state disker, eller flash-stasjoner, virkelig, er det de er, og erstatter veldig raskt spinningsdisken. Og det endres igjen fullstendig, fordi måten data er organisert på en disk på, er at de er organisert i henhold til måten disken fungerer på. Det handler faktisk om et hode som beveger seg over en spinnende overflate, faktisk flere hoder som beveger seg over flere spinnende flater, og plukker opp dataene når de går. En solid state-stasjon er bare en blokk med ting du kan lese. Jeg mener, det første er at alle de tradisjonelle databasene ble konstruert for å spinne disk, og de blir nå konstruert for SSD. Nye databaser kan sannsynligvis - alle som skriver en ny database akkurat nå, kan antagelig ignorere spinningsdisken, ikke tenke på det i det hele tatt. Men Samsung, den største produsenten av SSD-er, forteller oss at SSD-er faktisk er på Moore's lovkurve.
De var allerede, tror jeg, omtrent tre eller fire ganger raskere enn spinningsdisken, men de kommer nå til å bli mye raskere hver 18. måned, i utgangspunktet. Dobbelt i hastighet, og 10 ganger i hastighet opp til omtrent seks år. Hvis det bare var det, er det ikke det, som jeg vil fortelle deg om et øyeblikk. Spinning disk blir selvfølgelig et arkiveringsmedium.
Om minne. Første ting først, RAM. CPU-forholdet mellom RAM per CPU øker bare hele tiden. Og det leverer selvfølgelig på en måte en forferdelig mye mer fart, fordi dekningen med minne du kan ha nå, kan lagre mye mer. Hva dette faktisk gjør er at det på en måte reduserer presset på MLTP-applikasjoner, eller randomiserte programmer, fordi det er lettere å imøtekomme disse, fordi du nå har mye minne, og på den måten kan du cache alt som er sannsynligvis å bli lest inn i minnet. Men du får problemer med en større dataheap, så big data er faktisk ikke så enkelt, egentlig.
Og så har vi Intel med 3D Xpoint, og IBM med det de kaller PCM, som er faseendringsminne, leverer noe de tror er - vel, det er minst 10 ganger raskere enn nåværende SSD-er, og de tror det vil få veldig nær å være samme hastighet som RAM. Og selvfølgelig er det rimeligere. Så tidligere hadde du denne databasestrukturen til CPU, minne og disk, og nå beveger vi oss mot en struktur som har fire lag. Det har CPU, minne eller RAM, og så denne typen raskere enn SSD-minne, som faktisk er ustabilt, og deretter SSD. Og disse nye teknologiene er ikke-flyktige.
Og det er HPs memristor, som ikke er enda, vet du, fordi den ble kunngjort for syv år siden, men den er ennå ikke dukket opp. Men ryktene jeg hører er at HP kommer til å endre spillet litt med en memristor også, så du har akkurat en ny minnesituasjon. Dette er ikke som at vi har raskere ting, dette er som om vi har fått et helt nytt lag. Og så har vi det faktum at SSD-tilgang, kan du lese den parallelt. Du kan ikke lese spinningsdisk parallelt, bortsett fra ved å ha mange forskjellige spinnedisker. Men en blokk med SSD, kan du faktisk lese parallelt. Og fordi du kan lese det parallelt, går det langt raskere enn dets enkle lesehastigheter, hvis du faktisk konfigurerer flere prosesser på tvers av de forskjellige prosessene på en enkelt CPU, og bare har det med SSD.
Det anslås at du kan få nesten opptil RAM-hastigheter ved å gjøre det. Og alt dette er å si er at fremtiden for minnearkitektur er uklar. Jeg mener, virkeligheten er at de forskjellige dominerende leverandørene, uansett hva de viser seg å være, sannsynligvis vil bestemme retningen på maskinvaren. Men ingen vet hvor det går på dette tidspunktet. Jeg har snakket med noen databaseanleggere som sier: "Jeg er ikke redd for hva som skjer, " men de vet ikke hvordan de skal optimalisere fra start. Og du har alltid gjort det, så det er interessant.
Og så er det CPU-en. Vel, CPU-er med flere kjerner var ikke bare CPU-er med flere kjerner. Vi har også betydelige volumer av L1, L2 og L3 cache, spesielt L3, som er opp til, jeg vet ikke, titalls megabyte. Du kan legge mye der, vet du. Og derfor kan du faktisk bruke brikken som et hurtigbuffermedium. Så det forandret spillet. Og sikkert, vektorbehandling og datakomprimering, har en rekke leverandører faktisk gjort det, dratt det inn på CPU-en for å få det hele til å gå mye raskere på CPU-en. Da får du det faktum at vel, CPUer med GPU-er er veldig flinke til å akselerere analysene. Og de er egentlig ganske gode til visse typer spørsmål, det kommer bare an på hva spørringen er.
Du kan enten lage brett med CPUer og GPUer på, eller som AMD gjør akkurat nå, produserer du noe som kalles en APU, som er et slags ekteskap med en CPU og en GPU; det har begge slags muligheter. Så det er en annen type prosessor. Og så den siste kunngjøringen fra Intel om at de kommer til å sette en FPGA på brikken, den typen gjorde hodet mitt i. Jeg tenkte: "Hvordan i all verden skal det skje?" Fordi hvis du har fått mulighet for CPU, GPU, og du har muligheten til CPU, FPGA - og forresten, hvis du virkelig vil, på samme brett kan du sette en CPU, og en GPU, og en FPGA. Jeg aner ikke hvordan du faktisk skulle drive noe på den måten, men jeg vet om selskaper som gjør ting som dette, og de får veldig, veldig raske spørsmålssvar. Dette er ikke noe som kommer til å bli ignorert, dette er noe som kommer til å bli brukt av de etablerte leverandørene, og kanskje av nye leverandører som kommer opp. DBMS-er var alltid parallelle, men nå har de parallelle mulighetene nettopp eksplodert, fordi dette lar deg parallellisere dette med det, med det, med det på forskjellige måter.
Til slutt, for å skalere opp eller skalere ut? Oppskalering er egentlig den beste løsningen, men for en ting. Du får langt bedre nodeytelse hvis du bare absolutt kan optimalisere ytelsen til CPU og minne på disken på en node. Og du vil bruke færre noder, så det blir billigere, ikke sant? Og det vil være lettere å administrere. Dessverre er det en maskinvareavhengig design, og etter hvert som maskinvareendringer blir det mindre og mindre mulig å gjøre det, med mindre ingeniørene dine kommer til å kunne løpe så raskt som maskinvaren endres. Og du får problemer med arbeidsmengden, for når du skalerer opp, gjør du forskjellige antagelser om hva arbeidsmengden kommer til å gjøre.
Hvis du skalerer ut, det vil si hvis arkitekturen din legger vekt på skalaen før skalaen opp - faktisk du må gjøre dem begge, er det bare at du legger vekt på en. Da vil du få bedre nettverksytelse, fordi arkitekturen vil takle det. Det vil være dyrere i maskinvaremessige termer fordi det vil være flere noder, men det vil være færre problemer med arbeidsmengden, og det vil være mer fleksibel design.
Og jeg trodde bare at jeg ville kaste det inn, for hvis du faktisk tenker på alle maskinvareendringene, rettet jeg bare fingeren på, og så tenkte du på, hvordan skal du skalere og skalere ut de tingene? Da skjønner du at databaseanleggere etter min mening er godt underbetalte. Så hvis du bare tenker på maskinvarelaget, er databaseutfordringene klare. Nå gir jeg dette videre til Bert, som kommer til å gjøre at vi alle føler oss utdannet.
Eric Kavanagh: Det er det! Bert?
Bert Scalzo: tusen takk. La meg bare komme rett inn i disse lysbildene. Jeg har mange lysbilder å gå gjennom, så på ganske mange av dem går jeg kanskje ganske raskt. Vi kommer til å snakke om dette "Forward Momentum: Moving Relational Beyond Traditional." Det er ikke farens database lenger. Ting har endret seg, og som en tidligere foredragsholder sa, de siste seks til syv årene, har landskapet endret seg radikalt.
Selv har jeg holdt på med databaser siden midten av 80-tallet. Jeg har skrevet bøker om Oracle, SQL Server, benchmarking og ganske mange andre ting. ”Verden forandrer seg veldig raskt. Stor vil ikke slå liten lenger. Det vil være den hurtige juling den sakte. ”Jeg la til“ å tilpasse seg. ”Det var fra Rupert Murdoch. Jeg tror virkelig dette kommer til å bli sant. Du kommer ikke til å være i stand til å gjøre databaser slik du gjorde for 10, 15, 20 år siden. Du må gjøre det slik virksomheten vil ha det nå.
Jeg skal prøve å holde meg litt generisk i det jeg presenterer, men de fleste funksjonene jeg snakker om du finner i Oracle, finner du i SQL Server, MySQL, MariaDB og noen av de andre store spillere. Den relasjonelle databaserevolusjonen, jeg er nok en gang enig med de tidligere foredragsholderne. Ser du rett rundt 2010, gikk vi fra den røde racerbilen til den gule racerbilen. Det skjedde en betydelig endring, og i 2020 tror jeg at du kommer til å se en annen radikal endring. Vi er i en veldig interessant tid.
Nå, dette lysbildet er nøkkelen, det er derfor jeg la en nøkkel der oppe. Det er all denne endringen som skjer, og på venstre side har jeg teknologi, og på høyre side har jeg forretninger. Og spørsmålet er, hvilken som forårsaker hvilken, og hvilken støtter hvilken? Vi har alle disse maskinvareendringene: disker kommer ned, diskstørrelse går opp, nye typer disker, så det ble dekket av de tidligere høyttalerne. Prisen for å slippe minne, alle disse nyere versjonene av databaser. Men på høyre side har vi databeskyttelse og samsvar, datavarehus, forretningsinformasjon, analyse, obligatorisk oppbevaring av data. Begge sider av ligningen kjører, og begge sider av ligningen kommer til å gjøre bruk av alle disse nye funksjonene.
Først av alt, vi har den typiske SAS spinnedisken, de er opptil 10 terabyte nå. Hvis du ikke har sett, har Western Digital, HGST det de kaller helium-stasjonen deres, det vil gå opp til rundt 10 terabyte akkurat nå. Kostnadene for spinnedisken blir ganske lave. Som nevnt tidligere, kan du få solid-state-disker opp til omtrent to terabyte, men Samsung har en 20-terabyte-enhet som kommer snart. Kostnadene blir rimelige. En ting jeg skal snakke om de andre ikke, er begrepet flash-disker. PCIe, det er PCI Express, kontra NVMe, du har kanskje ikke hørt om dette, ikke-flyktige minneuttrykket. I utgangspunktet kommer NVMe til å være en erstatning for SAS og SATA, og det er egentlig mer en kommunikasjonsprotokoll enn noe annet. Men disse platene er på omtrent tre terabyte nå.
Du har kanskje også sett at noen SAS-stasjoner nå har U.2-kontakter, som er en annen kontakt enn en SAS eller SATA, som støtter NVMe med en standard disk - disken må selvfølgelig også støtte den. Og så SATA med M.2-kontakter, og de begynner å få NVMe. Faktisk er det bærbare leverandører som nå selger bærbare datamaskiner som har en NVMe-flash-disk i seg, og disse tingene vil skrike sammenlignet med teknologien du har brukt før.
Mange mennesker vet ikke hva alle disse forskjellige blinkene er. Hvis du ser nede i høyre hjørne, er det et eksempel på en M.2. Du kan si, "Vel, det ser veldig ut som mSATA-stasjonen til venstre for den." Men som du kan se, har det to hull i pinnene i motsetning til en, og den er litt større. Og også, M.2 kan komme i tre forskjellige størrelser.
Og så blitser PCI Express, og NVMe. Nå er NVMe-blitsen også PCI Express, men PCI Express er typisk fortsatt en SAS- eller SATA-type kontrollalgoritme som ble skrevet for spinningsdisk, og NVMe er algoritmene eller teknikkene som ble skrevet spesielt for flash. Og igjen, du kommer til å se alle disse.
NVMe tilbyr ganske mange ting. Jeg tror de to største forbedringene er, oppe i høyre hjørne reduseres latensen med så mye som 70 prosent. Jeg har faktisk sett enda høyere enn det. Hvis du ser i nedre høyre hjørne, når operativsystemet ditt snakker med NVMe-disken, går det gjennom færre nivåer av programvare. I utgangspunktet går du gjennom NVMe-driveren som er inkludert i operativsystemet, og den snakker rett med media. Det er mange grunner til at denne teknologien kommer til å endre databasens verden radikalt.
Og mange ganger vil folk si: “Vel, hvor raskt er NVMe?” Du vet, de gode gamle dagene, tilbake til 2004 og før, ble vi spent på om vi hadde Ultra-320 SCSI, 300 megabyte per sekund. Dagens hastigheter, mange av dere er sannsynligvis på fiber eller InfiniBand, og den typen topp ut. NVMe der til høyre, starter der de nåværende teknologiene slutter. Det jeg får til er at PCI Express 3.0 med en åttefelts lenke starter på nesten 8000, og det vil gå opp når vi får nyere versjoner av PCI Express, versjon fire og så videre. NVMe har ingen steder å gå bortsett fra opp.
Hva er det som endrer seg i databasen? Nå i øverste høyre hjørne av lysbildene mine satte jeg de forretningsgrunner jeg tror teknologien dukket opp. I dette tilfellet, på grunn av datalagring og på grunn av regulatoriske årsaker til obligatorisk datalagring, begynner databasene å tilby komprimering i dem. Noen databaser tilbyr komprimering som tillegg, noen tilbyr den som innebygd til standarden, la oss si bedriftsutgaven av databasen deres, og likevel kan noen databaser, som i Oracle, til og med ha en enda bedre versjon av komprimering som er i, for eksempel, Exadata-plattformen deres, så de har faktisk bygd maskinvare som kan støtte en veldig spesialisert komprimering, og den i Exadata, for eksempel, får en kompresjonsfrekvens på 40x, og derfor er den veldig betydelig. Og jeg tror det er obligatorisk datalagring, folk vil bare ha data lenger. Virksomhetene, for å gjøre analyse og BI, trenger de de siste 5, 10, 15 års dataverdiene.
Nå var en annen funksjon som begynte å dukke opp rett rundt den perioden 2008-2009, partisjonering. Igjen, du finner dette i databaser som Oracle, SQL Server, og i begge de du må betale for det. I Oracle må du kjøpe partisjonsalternativet, og i SQL Server må du være på datasenterutgaven. Det er din tradisjonelle skillelinje-og-erobringsteknikk, og det du gjør er at du har konseptet med et logisk stort bord øverst der, og når det blir satt på disk, blir det faktisk delt opp i bøtter. Og du kan se at disse bøttene er organisert etter noen kriterier for å skille, vanligvis referert til eller kalt partisjoneringsfunksjonen din, og da kan du også underinddeling i noen databaseplattformer, og du kan gå enda lenger.
Igjen, jeg tror både datalagring og obligatorisk datalagring har presset dette, og i noen av disse databasene kan du ha opptil 64 000 partisjoner, og jeg tror på noen andre databaser til og med opptil 64 000 underpartisjoner. Dette lar deg dele dataene dine opp i håndterbare stykker. Du vil også dele indeksene; det er et alternativ, du trenger ikke å gjøre det, men du kan dele indeksene også. En av grunnene til å gjøre dette kan være at du har et skyvevindu med data. Du vil beholde 10 år med data, men for å slippe indeksene for å kjøre kveldens batchbelastning, trenger du ikke å slippe indeksene på hver eneste rad, bare på radene som er i den nåværende bøtta. Partisjonering er faktisk et veldig godt administrativt verktøy, selv om de fleste tror at det er en stor fordel å avstå partisjon eliminering i planene dine og derfor fremskynde spørsmålene dine. Det er virkelig slags glasur på kaken.
Nå har du sikkert hørt om skjæring, og du tenker sannsynligvis, "Vel, hvorfor la du dette lysbildet inn her?" Dette er et av disse NoSQL - dette er et av Hadoop-miljøene. Oracle 12c ga ut to, som ikke er G8 ennå, men som vises eller forhåndsvises har faktisk skjær i seg. Du kommer til å ha et tradisjonelt databasesystem som Oracle, og du vil være i stand til å skjære som du gjør i Hadoop-modellen, og slik at du kommer til å ha en annen skillelinje og erobre teknikk som kommer til å dele opp tabell radvis i grupperinger per node, og dette kommer til å bli - akkurat som det du ser i noen av NoSQL-databasene dine. Og faktisk MySQL, du kan faktisk oppnå dette ganske mye ved å bruke en av deres klyngeteknikker, men det kommer til en tradisjonell database og antar at Microsoft ikke vil ønske å sitte igjen. Disse to spiller hoppfrosk med hverandre hele tiden, så jeg forventer å se skjæring i kanskje den neste versjonen av SQL Server.
Datas livssyklusstyring, igjen obligatorisk datalagring, men også for forretningsintelligens og analyse. Virkelig, dette er en splitt-og-erobringsteknikk, og typisk gjør DBA-er dette manuelt, og det vil si: "Jeg kommer til å beholde årets data på raske disker, fjorårets data på litt tregere disker, kanskje jeg å beholde de to siste årene før det på enda tregere disker, og så har jeg en arkivmetode. ”Det er vanligvis ikke teipet lenger, det er vanligvis - du har en slags nettverkstilkoblet lagring eller en enhet som har mye lagring og er, du vet, kostnadseffektiv, men det er fortsatt spinnende disk.
Og nå kan du faktisk - både på Oracle og på SQL Server - kjøpe et alternativ der du definerer reglene, og dette skjer bare automatisk i bakgrunnen. Du trenger ikke å skrive skript lenger, du trenger ikke å gjøre noe. Og hvis du har sett SQL Server 2016, som nettopp kom ut første juni, er det en ny funksjon som heter "Stretch Databases", som du i utgangspunktet lar deg gjøre - i nederste høyre hjørne der - kan du flytte fra flere lag direkte i skyen og igjen er dette en funksjon som er innebygd i databasen. Du sier bare noe som: "Hvis dataene er mer enn 365 dager gamle, kan du flytte dem inn i skyen, og du vet det, gjør det automatisk for meg."
Dette kommer til å bli en veldig kul funksjon, faktisk tenker jeg at det kan være det vi kommer til å se i fremtiden, og det er at du kommer til å ha hybriddatabaser der du skal holde noen lokale og noen i skyen. Før dette tenkte folk: "Åh, jeg skal enten gjøre et sted, eller det skal jeg gjøre på skyen." Nå ser vi ekteskapet med de to teknologiene på denne hybride måten. Jeg tror dette blir ganske stort og Microsoft kom dit først.
Redaksjon, dette skyldes databeskyttelse og overholdelse. Nå i de gode gamle dagene kan vi ha sagt: "Hei, applikasjonsutvikler, når du viser dette i rapporten, når du viser dette på skjermen, her er det noen sikkerhets ting du bør sjekke og vær så snill, du vet, bare vis dataene de skal se eller maskere eller redigere dataene som de ikke skal se. "Vel, som vanlig, når du skyver det ut til applikasjonen, blir det ikke gjort på ett sted, så det blir gjort annerledes, eller det gjør det ikke noen steder blir det ikke gjort. Og så nå har du faktisk fått denne muligheten i databasesystemene dine.
Nå i SQL Server 2016 er denne funksjonen innebygd, slik at den ikke er en valgfri kostnadsartikkel som enda skal være på datasentertillegget, tror jeg; og i Oracle 12 må du kjøpe deres livssyklusadministrasjonstillegg, men dette er noe nytt og igjen blir det drevet av virksomheten. Og spesielt fordi du holder på med så mye data nå, og du driver med data mining, så BI og analysene, må du vite hvem som får tilgang til disse dataene og sørge for at de bare får lov til å se hva de får se.
På samme måte, se på det igjen, databeskyttelse og overholdelse. Du vil oppdage at mange av databasesystemene nå bygger komprimering, eller beklager, kryptering direkte i databasen og hva som er viktig med denne krypteringen, hvis du ser på pil ned og pil opp på diagrammet skriver den det ned til disken kryptert, og deretter leser den den opp i minnet og dekrypterer den. Det er faktisk en modell, det er en annen modell som, du vet, faktisk bare gjør det når den kommuniserer dataene over nettverket til selve klientapplikasjonen.
I så fall vil den til og med fremdeles på databaseserveren i minnet kunne krypteres og bare dekrypteres når den sendes over til klientprogrammet. Det er to forskjellige modeller her, og du finner disse i databasene, og faktisk en av databasene som nettopp la til dette nylig, var MariaDB i deres versjon 10.X; Jeg tror de er på 10.1 eller 10.2 nå. Og jeg gjorde faktisk noen benchmarking for denne krypteringen, og for å få denne krypteringen opplevde jeg bare om lag 8 prosent reduksjon i gjennomstrømning eller hastighet. I en benchmarking-test forårsaket ikke krypteringen så mye, og det er derfor en veldig nyttig funksjon.
Nå har vi nevnt tidligere om flash-minne og SSD-er og slike ting. En av funksjonene du har i Oracle og SQL Server som mange ikke er klar over, er at du kan ta en flash eller SSD som er på databaseserveren din, og du kan si til databasen: "Bruk dette som om de var minne. Behandle RAM som preferanser, men later som om dette er tregt minne og bruk det som en utvidet cache. ”Nå i SQL Server 2014 kom dette ut og ble kalt“ Buffer Pool Extension, ”det er gratis. I Oracle kom den ut i 11g R2 og den ble kalt “Database Flash Cache”, og den var også gratis der.
Mitt råd er imidlertid å prøvekjør denne funksjonen nøye. Hver gang du gjør hurtigbufferen større når du skal søke, tar det lenger tid. Hvis du setter et tre-terabyte flash-kort og sier til databasen, "Legg det til i minnet, " kan du faktisk oppleve at noe ble redusert på grunn av tiden å se på og se at det er i blitz, er det skittent eller ren? Det er et poeng av å redusere avkastningen. Mitt råd er igjen prøvekjøring dette, se hva som fungerer for deg, men igjen, det er i databasen din og i tilfelle av Oracle's, i både SQL Server og Oracle, har den vært der i et par år nå.
Og så bringer det oss til bestefar som var databasene i minnet, og det er fordi databaseprisene har falt. Den andre grunnen til at du sannsynligvis skulle tro at dette har skjedd, er mye av analysen som krever at dataene skal være veldig raskt tilgjengelige, og det må derfor være i minnet. Legg merke til at algoritmene som databasene bruker for å få tilgang til disse dataene, for å komprimere dem, for å kryptere dem, for å lagre dem. Du vet i noen tilfeller at noen databaser kan fortsette å lagre minnet som en rad.
I noen tilfeller kan noen databaser bryte dette opp i en kolonneorientert, og grunnen til at de gjør det er at de får et mye høyere komprimeringsnivå, et sted rundt 11 til 12X ved å lagre det i kolonne rekkefølge kontra radrekkefølge. Dette dukket opp første gang i SQL Server 2014, det ble kalt “Hekaton.” Det er blitt radikalt økt i SQL Server 2016, de vil se det referert av noen forskjellige navn, og det kom ut i Oracle 12c; Jeg sier den andre utgivelsen her, ikke R2. Det var to forskjellige utgivelser av Oracle 12c, 12.1.0.1 og 12.1.0.2. Det er den andre utgivelsen av R1-versjonen av databasen.
Og måten du definerer det på, minne-objektet ligner i begge databasene. Her kan du se i høyre øverste hjørne, jeg oppretter en SQL Server, og du kan se den sier med minneoptimalisert og holdbarhet bare er skjema. Jeg skal ikke gå over alle disse syntaksbetydningene, og i Oracle er det faktisk enda enklere, du bare endrer et bord og sier i minnet eller ikke, og du kan endre det. Jeg kan si i dag at det er i minnet og i morgen er det ikke, og det er veldig fleksibelt.
Jeg gjorde noen tester på Oracle med minnetabeller, jeg hadde noen tester som tok nesten 40 minutter å løpe, der oppe på øverste rad. Det som er viktig er da jeg kom til de to nederste radene, jeg hadde økt kjøretiden eller redusert den, skulle jeg si, til fem minutter omtrent, og da jeg så på kompresjonsfaktoren, var dataene i minnet faktisk 3, 6 til 4, 6 ganger mindre. Det er viktig fordi jeg i dette tilfellet brukte kolonneorientert format og det er komprimering. Og gjett hva? Jeg passet faktisk nesten fire til fem ganger så mye data i hukommelsen. Ikke bare fikk jeg fordelen med minnet, fordelen med kolonneorientert, men også fordelen med langt mer data - opptil fem ganger så mye data i minnebufferen, så dette er en ganske kraftig teknikk. Igjen Oracle og SQL Server, du vil se på disse, de er veldig kule funksjoner. Og med det tror jeg at jeg vil åpne det for spørsmål.
Eric Kavanagh: Vel Bert, først og fremst har du vært veldig uselvisk i all denne fantastiske utdannelsen. Kunne du snakke bare et øyeblikk om hva dere gjør? Fordi du har noe muliggjørende teknologi som kan lette det du har snakket om. Bare snakk et øyeblikk om hva dere gjør, så la oss få Dez og Robin ned i ligningen her.
Bert Scalzo: Ja, jeg jobber for et selskap som heter IDERA. Vi er i Texas, vi har hovedkontor i Houston, og jeg sitter faktisk i Austin akkurat nå, men jeg har base i Dallas. Vi lager databaseverktøy og lager databaseverktøy som hjelper deg med å løse problemer. Dette problemet kan være noe så enkelt som produktivitet. I så fall har vi et verktøy som heter DBwartan som lar deg utføre databaseadministrasjonsoppgaver, og det er ett verktøy som lar deg administrere 12 forskjellige databaseplattformer. Jeg kan administrere SQL Server, jeg kan administrere Oracle, jeg kan administrere MySQL, DB2, Postgres, og jeg bruker ett verktøy, ett kjørbart, ett GUI-design og ett konsekvent sett med arbeidsflyter. Vi lager også verktøy for å utføre overholdelse, vi har et verktøy som heter SQL Compliance Manager for å hjelpe deg med å oppfylle dine overholdelsesbehov. Et annet verktøy som heter SQL Security, så vi prøver å lage verktøyene som vil hjelpe deg å være effektive og effektive, og hva som virkelig er fint hvis du går til nettstedet vårt, har vi en hel haug med freeware der ute, så hvis ikke annet, kan du laste ned - Jeg tror vi har omtrent 20 eller 25 freewares. Det er noen virkelig gode freeware ting der ute, som om det er en SQL Server og en Windows Hjelpsjekk som bare i utgangspunktet vil se på hva du har og fortelle deg om du har problemer eller ting, og det er helt gratis.
Eric Kavanagh: Og du virkelig slags -
Bert Scalzo: Definitivt de første tingene -
Eric Kavanagh: Du snakker med heterogeniteten i markedet i dag, det pleide å være en slags en-størrelse-passer-alle-ligning som jeg faktisk husker at jeg intervjuet Dr. Michael Stonebraker langt tilbake da han i 2005, da han gikk videre et stort dytt og snakket om dom over den kolonneorienterte databasebevegelsen, og han snakket alt om hvordan en-størrelse-passer-alle-relasjonsmodellen dominerte i mange år, og han spådde at alt ville endre seg, og gutt hadde han rett i at. Nå har vi dette veldig mangfoldige og interessante miljøet med mange forskjellige muligheter og muligheter, men du trenger noen til å administrere alt dette, og det ser ut til at selskapet ditt er veldig akutt fokusert på å løse matematikkproblemer, og dermed være en muliggjørelse av overskrift av heterogenitet, ikke sant?
Bert Scalzo: Absolutt. Jeg mener det alltid vil være DBA-er som sier: "Jeg vil ikke bruke et GUI-verktøy, jeg gjør alt med skript, " vet du? De tror de er supermannstypen DBA, og det er bra, men for de fleste av oss mennesker ønsker vi bare å få gjort arbeid, og - du vet, jeg bruker Microsoft Word til å skrive dokumentene mine. Jeg bruker Microsoft Outlook til å gjøre e-posten min. Jeg mener, jeg har verktøy for å gjøre oppgaver. Vi bygger samme type konsept, vi bygger verktøy for databaseadministratorer og utviklere som hjelper dem å fokusere på hva de vil gjøre og ikke hvordan de må gjøre det.
Eric Kavanagh: Det er fornuftig, men la meg vende deg til ekspertene våre, og folk kan gjerne dykke i. Vi har fått et par kommentarer fra publikum. Kanskje, Dez, et par spørsmål og Robin et par spørsmål?
Dez Blanchfield: Visst. Et av de første spørsmålene jeg vil kaste til deg, gitt det enorme spennet av erfaring du fikk, ser du et tidspunkt når noe av dette kommer til å avta? Eller tror du at vi egentlig bare er inngangspunktet til denne kontinuerlige vekstlinjen for endring? Jeg tror en av de største problemene som selskapene står overfor, og da alltid mennesker som prøver å støtte teknologien som blir gitt disse selskapene til å drive sine virksomheter, er at endringshastigheten er så dramatisk at de bare ikke kan følge med alle de forskjellige funksjonene, programvaren og systemene, og rammer, og arkitekturer, og ny kode som kommer opp, og deretter maskinvaren under det, ser du gjeldende endringshastighet i det hele tatt? Jeg mener, du har å gjøre med et så bredt spekter av plattformer med hele IDERA-suiten, skal vi bremse opp snart, eller er vi liksom på dette vanvittige løpende godstoget lenge ennå?
Bert Scalzo: Jeg tror vi er på de første 20 prosentene av vekstkurven, og vi har en lang vei å gå, og det er to ting som presser det. Teknologien fortsetter å utvikle seg. Du har nevnt noen av de nye minnetypene som kommer til å komme ut, det vil være fantastisk. Samsung kommer til å ha en 20-terabyte flash-stasjon her virkelig snart. Det kommer til å endre ting. Vi har alle disse NoSQL- og skydatabasene, dette kommer bare til å fortsette. En ting som er ganske morsomt, er at når jeg ser på databaser som Oracle og SQL Server og noen av de andre, er de egentlig ikke relasjonsdatabaser lenger. Jeg kan legge ustrukturerte data i Oracle og likevel opprettholde ACID-overholdelse. Hvis du hadde fortalt meg det for 20 år siden, hadde jeg bare sagt at du var på narkotika.
Dez Blanchfield: Ja, ja, de er kule. Selv nå er de motorene som har ganske fine nisjefortikaler som GIS, bare bedre enn innfødt evne nå. Du kom med noen gode kommentarer om utfordringene som DBA-er står overfor og de forskjellige tider for DBA-er som vi håper å se rundt om i stedet, men hvordan ser verden ut med det slags laget av virksomheten du arbeider med? Jeg mener, dette er menneskene som bruker de forskjellige plattformene fra diagnosebehandleren din, til inventarverktøyene, og helt ned til å glede seg til defragging, hvordan takler DBAs denne endringen og hvordan gjør de det - du vet, hva gjør de med verktøyene dine for å håndtere dette betydelige skiftet i landskapet?
Bert Scalzo: Vel, jeg kommer tilbake for snart 20 år siden, da vil jeg si at DBA løser en veldig spesifikk rolle i en organisasjon. De jobber vanligvis med en databaseplattform, kanskje to, og de klarte et relativt lite antall databaser. Nå er det raskt frem til i dag og databaseadministratoren, han kommer til å kjenne 10 databaseplattformer. Han styrer, og dette er ingen spøk, i noen tilfeller tusenvis av databaser; det er mer om SQL Server-verdenen eller MySQL-verdenen. Men fremdeles i Oracle-verdenen kunne de administrere hundrevis av databaser. Og slik at de har fått alle disse nye funksjonene ut, de har alle disse nye plattformene, og de har alle disse databasene de er ansvarlige for. De leter etter verktøy for å aktivere produktiviteten og også for å hjelpe dem å lære noen ting.
Og jeg vil gi deg et eksempel - hvis jeg vil partisjonere et bord, er det en ganske uklar syntaks, og hvis jeg vil subpartisjonere den, blir syntaksen enda vanskeligere. Jeg vet hva jeg vil gjøre, jeg vil lage bøtter. Hvis jeg har et verktøy som DBbrevan som sier: "Hei, her er en fin skjerm som lar deg konsentrere deg om hva du prøver å gjøre, heller enn hvordan du prøver å gjøre det, og å forresten, trykk på Vis SQL-knapp når du er ferdig, så viser vi deg hva SQL var, slik at du kan begynne å virkelig lære og mestre dette. ”
DBAer finner ut at verktøy som hjelper dem med å få jobben gjort, men også hjelper dem med å lære dem alle disse nye tingene de bruker, og det samme vil være sant - la oss si at jeg er en Oracle-fyr og jeg går over til MySQL og sier, “OK, lag en database, DBbrevan. Vis meg nå SQL fordi jeg lurer på hvordan det er å lage en database på MySQL, og jeg har nettopp lært å syntaxe. ”Og så hjelper vi dem ikke bare til å jobbe på tvers av databaser, vi utdanner dem også i hele databasen.
Dez Blanchfield: Det blir enda mer interessant når du kommer ut til noe av det mer moderne - eller ikke mer moderne, det er ikke en rettferdig ting å si - men en gang i blant er en database en database. I disse dager ser jeg alt du snakker om der med den ekstra utfordringen at teknologien stabler som vi tradisjonelt ser fra leverandører og du slags åpen kildekode i den og også at de er gode. Ikke bare håndtere databasemotorene og spørrespråkene, men de tar også for seg datatypene, det strukturerte og ustrukturerte, du vet, utfordringen med å måtte håndtere alt fra enden av spekteret til en multi-petabyte HDFS miljø til små bittesmå containere, og pakkefiler og forskjellige loggfilformater.
Og jeg tror at det er noe vi ser der vi ingen mennesker, uansett hvor mye av en supermann, superkvinne, hva de måtte tro de er, de fysisk, de bare ikke kan mentalt takle den endringshastigheten og omfanget av variasjoner. Jeg tror verktøyet du tilbyr nå kommer til et punkt der de nesten vil være på et standardsett på mange måter, slik at vi ikke kan kjøre databasemiljøene vi har uten dem fordi vi bare fysisk kan ikke kaste så mange kropper på dem. Jeg likte presentasjonen din. Jeg vil overføre til Dr. Robin Bloor, jeg er sikker på at han har mange spørsmål å kaste på deg også.
Robin Bloor: OK. Vel, jeg har absolutt spørsmål. Bert, jeg vet ikke hvor du skal - jeg hadde en veldig interessant samtale for et par dager siden der noen begynte å fortelle meg om den nyeste DU-databeskyttelsen, og det syntes for meg utifra det de sa at det var utrolig drakoniske når det gjelder ting de insisterte på. Jeg lurte på om du faktisk hadde sett på det; er det noe du er kjent med?
Bert Scalzo: Absolutt. Yeah.
Robin Bloor: 2016, OK, fortell oss om det.
Bert Scalzo: Og jeg har faktisk-
Robin Bloor: Dypt interessant.
Bert Scalzo: Jeg har faktisk jobbet en stund for en flash-leverandør, i deres databaseområde og hjulpet dem med å lage flash-produkter for databaser, og jeg kan fortelle deg at drakonianen går helt ned. Det jeg mener er at hvis du husker min ene lysbilde, sa jeg i noen databaser at den vil gjøre krypteringen, men den legger den inn i serverminnet og i noen databaser er krypteringen - den er fremdeles kryptert i serverminnet, den blir bare dekryptert når det blir sendt til klienten. Det du også finner er noen av disse regjeringsstandardene, spesielt forsvarsdepartementet eller militæret her i USA, de går også helt ned til blitsnivået, og de vil vite ikke bare at du støtter kryptering og dekryptering i maskinvaren din, men at hvis noen stjal sjetongene som - du vet, trakk dem ut av tingen, ut av serveren din, at det som er der er kryptert, og selv om de har lagring, kan det ikke være, og de vil helt ned til selve - ikke til selve blitsdelen, men ned til de enkelte sjetongene. De ønsket å vite at chip for chip, alt var kryptert.
Robin Bloor: Wow. Jeg mener det er mange ting som - du vet, jeg tror det bare var en eller to lysbilder du har fått opp om dette, men det var noe, et scenario som jeg synes er veldig interessant. Reduksjon av informasjon for eksempel, det må være litt smart enn bare å maskere bort forskjellige felt, fordi du spesielt med maskinlæring i dag kan gjøre deduktive ting som lar deg overflateinformasjon som du ikke tidligere kunne overflate.
Hvis du prøver å beskytte, la oss si helseinformasjon, så er det en veldig, veldig drakonisk regel i USA når det gjelder helseinformasjon, men du kan faktisk ved hjelp av forskjellige maskinlæringsmetoder, kan du ofte finne ut hvem som er noen medisinsk informasjon faktisk er. Jeg lurte bare på om du har noe å si om det fordi de alle synes det er et interessant område.
Bert Scalzo: Ja, absolutt, og jeg bruker bare dette som eksempel, jeg prøver ikke å si at en database er bedre enn en annen, men dette er et veldig godt eksempel på det du nettopp spurte. I Oracle, hvis jeg ikke får lov til å se en rekke data for eksempel, som at jeg ikke har lov til å se John Smith-journalen. Hvis jeg sier: "Velg den posten" i Oracle, vil jeg bli blokkert, eller jeg får lov til å se hva jeg får lov til å se, og den blir omgjort. Og hvis jeg sier: "Velg kontostjerne fra tabellen der det er lik John Smith, " får jeg null.
I SQL Server kan den gjøre redaksjonen, men den har noen hull. Hvis jeg sier: "Velg kontostjerne fra bordet der det tilsvarer John Smith, " vil jeg faktisk få tilbake en, så jeg vet at det er en John Smith. Den ene er sikrere enn den andre. Nå forventer jeg at de ordner det, de spiller alltid sprangfrosk med hverandre. Og igjen, jeg prøver ikke å skille mellom databasene annet enn å vise et eksempel på - se på hva vi snakker om nå, noe så enkelt som å velge konto må også kuttes av redaksjonen, selv om teknisk sett snakker, er det ingenting som blir redusert annet enn eksistensen av rekken.
Robin Bloor: Ja, ikke sant. Det er litt interessant. Jeg mener, et annet generelt spørsmål fordi jeg ikke har mye tid, handler egentlig bare om forbedringene. Jeg mener at du har vært i et sted der jeg vet at du har vist oss eksempler på forskjellige testresultater du har kjørt - tror du at de tradisjonelle databasene, la oss kalle dem de dominerende databasene, SQL Server og Oracle, gjør du det tror de kommer til å ligge foran ferdigstillelsen? Eller tror du at de faktisk kommer til å bli fanget av en eller annen av forskjellige slags forstyrrelser på markedet som virkelig kjører for dem? Hva er din mening?
Bert Scalzo: Jeg har en mening og det er - du vet, igjen skal jeg si at det er min mening - Microsoft, for eksempel i post-Ballmer-tiden, er bare å imponere det levende helvete ut av meg. Jeg mener denne strekningsdatabasen får SQL Server på Linux, får .NET over på Linux, får PowerShell over på Linux; Jeg tror ikke at tradisjonelle databaseleverandører kommer til å komme igjen. Jeg tror de har bestemt seg: “Hei, la de nye gutta, startupene definere noe. La dem finne ut hva avskjerming er og hvordan det skal perfeksjoneres, og når de har gjort all forskningen og utviklingen, vet vi nøyaktig hva brukerne vil ha, la oss nå legge avskjerming til Oracle. ”Jeg tror de bare blir smarte og å si: "Hei, å være andre eller tredje er ikke dårlig når du er den dominerende spilleren, for da vil ikke folk migrere av deg."
Robin Bloor: Ja, jeg mener det er en strategi som har blitt brukt. Jeg mener IBM pleide å gjøre det og hele det - for hele produktene deres, og det rangerer rimelig godt til noen kommer på noe som bare er helt utenfor veggen som ingen noen gang har tenkt på, men du kan ikke planlegge mot det uansett.
Spørsmål fra publikum, Eric?
Eric Kavanagh: Ja, men du har tid jeg tenker bare for en kanskje, og jeg vet at Bert må løpe. Det var noe her inne - greit nok, avskjæringsarkitekturen på Oracle 12c er det som en indikasjon på - eller hva er det en indikasjon på etter din mening, hva tror du som skjer der?
Bert Scalzo: Vel, Oracle absorberer eller / og tilbyr alt det som alle de andre databaseleverandørene er. Jeg kan for eksempel legge ustrukturerte data i Oracle. Jeg vet ikke hvordan du kan legge ustrukturerte data og så kalle det en relasjonsdatabase, så det gir ikke mening, men det kan du også. Og nå legger Oracle til skjæring, så Oracle sier: “Vet du hva? Uansett hva markedet vil, vil vi tilby vårt database tilbud fordi markedet vil ha det markedet vil og vi vil levere løsningen, vi vil at de skal være med oss. ”
Jeg tror at du kommer til å se flere ting. Jeg vil ikke bli overrasket over å se Hadoop-lignende klynger av databaseknuter ikke i et Oracle-rack eller ekte applikasjonsklynge, men i utgangspunktet i mer av en tradisjonell klynging av Hadoop-typen som gjør det skjærende. Og så jeg tror du vil være i stand til å distribuere en database som Oracle som du ville ha en Hadoop, og denne typen trender kommer til å fortsette. Disse store databaseleverandørene, de tjener milliarder av dollar, og de vil ikke miste markedet, så de er villige til å tilpasse seg noe eller adoptere noe.
Eric Kavanagh: Vel, du vet, det er morsomt fordi jeg har fulgt open source-leverandørene i ganske lang tid og har lurt på alt om det, hvor stor innvirkning det vil ha på tradisjonell teknologi med lukkede dører, og en stund det det føltes helt sikkert som om åpen kildekode-leverandørene gjorde noen alvorlige fremskritt, og nå når jeg ser på markedsplassen ser jeg slags hva du sier, at de store gutta har gjort matte, har skjerpet blyantene og de fant ut hvordan de kan veve mye av det inn i arkitekturene sine. Enten det er IBM, eller Oracle, eller SAP - Jeg var nettopp på SapphireNow-konferansen forrige måned, og Steve Lucas, som er leder av halvparten av det selskapet, skryt av at SAP nå innlemmer i HANA-skyplattformen, mer open source-komponenter enn noen av deres konkurrenter. Hvis du gjør regnestykket på det, er det et ganske imponerende utsagn, og det forteller meg at de store gutta ikke kommer noen vei snart.
Bert Scalzo: Nei, jeg vil satse pengene mine på begge deler. Jeg mener at hvis du ser, var Microsofts aksje nylig på rundt $ 50, og du vet, bare for noen år siden var det 25 år. Du dobler ikke aksjekursen din i løpet av en kort periode med mindre du gjør gode ting, og vet, fra å gjøre alt fra Windows 10 å være gratis det første året til alle de andre smarte tingene de gjør, denne strekningsdatabasefunksjonen tror jeg bare er fantastisk. Jeg tror at det som kommer til å skje, er at mange kommer til å havne i Azure, ikke direkte, ikke som de sa, "La oss migrere databasen min til Azure." Den kommer til å migrere der borte på en magisk måte fordi den kommer til å bli arkivert der borte ved hjelp av denne nye strekningsdatabasefunksjonen, og så blir adopsjonen av Azure bare skyrocket.
Eric Kavanagh: Det er vel en av trendene på markedet som selv jeg kan se, selv på Mac-en. Når du går inn på Mac-en for å lagre noen dokumenter, gjør de det nå - og de nyere Mac-maskinene følger bare gjennom skyen, ikke sant? Jeg mener, det er mye fornuftig i den strategien, og jeg ser også på den og går, “OK fyrene, dere prøver å lokke meg stykke for bit inn i skymiljøet ditt, og så en dag når jeg vil se en film om kredittkortet mitt er utløpt. Jeg kommer til å være i trøbbel. ”
Bert Scalzo: Ja, men du gjør det på Facebook.
Eric Kavanagh: Ja. Det er sant.
Bert Scalzo: Du legger alt på Facebook.
Eric Kavanagh: Vel, ikke helt alt.
Bert Scalzo: Nei, jeg mener -
Eric Kavanagh: Ja, fortsett.
Bert Scalzo: Disse sosiale trendene når ut i virksomheter. Nå har bedrifter fremdeles mange andre ting de må gjøre, men de ser disse trendene og de gjør de samme tingene. Jeg ser ikke verken Oracle eller Microsoft gå bort. Faktisk kommer jeg til å kjøpe aksjer på begge deler hver gang det er en dukkert.
Eric Kavanagh: Ja, ja. Vel folkens, gå til idera.com, IDERA dot com. Som Bert sa, de har en hel haug med gratis ting der oppe, og det er en av de nye trendene på markedet - gi deg noen gratis ting å leke med, bli hekta og så kjøper du de virkelige tingene.
Folkens, dette har vært en annen het teknologi. Takk for tiden din i dag, Bert, selvfølgelig, og Robin også. Vi skal snakke med deg neste uke, mange ting som skjer. Hvis du har noen ideer, kan du gjerne sende dem på e-post. Vi snakker med deg neste gang folkens, ta vare. Ha det.
