Hämtmat: Värd Eric Kavanaugh diskuterar innovationer inom databasteknologi med experterna Dez Blanchfield, Robin Bloor och Bert Scalzo.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, det är onsdag vid fyra östra tid. Jag är i New Orleans, sommaren kommer, det betyder att det är hett! Det är dags för Hot Technologies, ja, ja, ja. Jag heter Eric Kavanagh, jag är din värd. Jag kommer att sparka tillbaka bollen för Hot Technologies. Ämnet idag är "Framåt momentum: Flytta relationellt utöver traditionella." Folk, vi har tre databasexperter på telefon idag, så alla frågor du har, dem de svåra, ska inte vara blyga. Vi har ett gäng bra innehåll som står upp för dig idag. Det är platsen om din verkligen, nog om mig. Naturligtvis är det här året varmt. Vi pratar allt om heta tekniker i den här showen, som är ett partnerskap med våra vänner från Techopedia. Och vi går hela vägen ner till grunden för informationshantering i dag, som naturligtvis är databasen. Vi kommer att prata om hur vi kom hit, vad som händer idag och vad som händer framöver. Massor av mycket intressanta saker pågår.
Uppenbarligen har vi en del allvarlig innovation i databasutrymmet. Det var lite tyst ett tag; om du pratar med några av analytikerna i branschen, skulle jag säga förmodligen från året som 2005 till 2009 eller '10, det verkade inte som om det höll på för mycket vad gäller innovation.Och plötsligt bröt det bara ut, som ett jailbreak eller något, och nu händer det alla slags intressanta saker. Mycket av det beror på webbens omfattning och alla coola webbegenskaper som gör olika intressanta saker. Det är där NoSQL-konceptet kom ifrån. Och det betyder två olika saker: det betyder inget SQL, som det inte stöder SQL, det betyder inte bara SQL. Det finns en term "NewSQL" som vissa människor har använt. Men uppenbarligen är SQL - det strukturerade frågespråket - verkligen grunden, det är grunden för frågan.
Och det är intressant att alla dessa NoSQL-motorer, vad hände? Tja, de kom ut, det var mycket spänning åt det, och sedan några år senare, vad började vi alla höra? Åh, SQL på Hadoop. Nåväl, alla dessa företag började smälla SQL-gränssnitt på sina NoSQL-verktyg, och alla som är i programmeringsvärlden vet att det kommer att leda till vissa utmaningar och vissa svårigheter, och vissa korsade ledningar och så vidare. Så vi ska ta reda på mycket av det i dag.
Det finns våra tre presentatörer: vi har fått Dez Blanchfield som kallar in från Sydney, vår helt egen Robin Bloor som är i Texas, och det är Bert Scalzo, han är också i Texas. Så för det första kommer vi att höra från Dez Blanchfield. Folk, vi kommer att tweeta på hashtaggen för #HotTech, så känn dig fri till dina kommentarer eller dina frågor genom Q & A-komponenten i webcastkonsolen, eller till och med genom chattfönstret. Och med det, Dez Blanchfield, ta bort det.
Dez Blanchfield: Tack, Eric. Hej allihopa. Så jag kommer att försöka sätta scenen på en 30 000 fot synvinkel av vad som hände under det senaste decenniet, och de betydande förändringarna vi har sett - eller åtminstone ett och ett halvt decennium - av databashanteringssystem, och några av effekterna från en kommersiell eller teknisk synvinkel, och några av de trender som vi har utstått på sent, och leder oss in i konversationen vi ska ha idag kring ämnet.
Min omslagsbild här är en sanddyn, och det blåser små små bitar sand från toppen av den. Och som ett resultat av detta, vad som händer är att sanddynen långsamt går från ett utrymme till ett annat. Och det är ett fantastiskt fenomen, där dessa massiva 40- och 50 fot höga sandberg, faktiskt, de rör sig. Och de rör sig mycket långsamt, men de rör sig säkert, och när de rör sig förändrar de landskapet. Och det är ganska något att titta på om du tillbringar någon tid alls i ett område där sanddyner är en naturlig sak. Eftersom du kan titta ut genom fönstret en dag och inse att detta massiva berg med sand, små små korn har rört sig själv, i själva verket, och att vinden sakta flyttar det från en plats till en annan.
Och jag tror på många sätt, det har varit databassystemens värld ganska länge. Fram till mycket, nyligen, den mycket lilla förändringen i form av sandkorn som flyttar ett gigantiskt berg av sand i form av en sanddyn. Lilla förändringar har kommit in i databasplattformarna under åren, och det har varit en ganska stabil och solid miljö runt databassystem och plattformar, genom mainframe från mellanklass-eran. Men för sent har vi hänt några ganska betydelsefulla saker med våra kommersiella behov och våra tekniska drivrutiner. Jag kommer att gå oss igenom dessa.
Jag har en uppfattning om att det grundläggande konceptet för en databas, som vi kände den i många, många år, och som ni kanske har hört i pre-show banter, våra två experter som är på samtal med mig idag hade en livstid i detta utrymme och de har helt rätt när de delar skrytande rättigheter att vara där när allt började i början av 80-talet. Men vi har sett denna enorma förändring under det senaste decenniet och lite, och jag ska snabbt gå igenom oss innan jag överlämnar det till Dr. Robin Bloor.
Vi har genomgått det jag kallar "större, bättre, snabbare, billigare" -upplevelse. Som sagt har definitionen av en databas förändrats. Landskapet där databasplattformarna har varit tvungna att möta prestanda och tekniska och kommersiella krav har också förskjutits. Vi har sett den ökade efterfrågan på lösningar för att hantera antingen mer komplexa kommersiella eller mer komplexa tekniska krav. Och så en riktigt snabb genomblick av vad det faktiskt innebär, i min mening, är att vi måste sortera på 90-talet, och vi såg databasteknologi påverkas av introduktionen av internet, och typ av vad vi kallade tillbaka på internet skala. Vi pratade inte bara om människor som satt framför terminalerna, ursprungligen sådana som teletypterminaler med fysiska ers inbyggda i dem och 132 kolumner som kommer ut i papper. Sedan de tidiga gröna skärm terminalerna, stansning med tangentbord.
Men du vet, vår värld var terminaler och seriekablar eller nätverkskablar som pratade med datorer under lång tid. Sedan kom internet, och denna explosiva tillväxt av anslutning, att du inte behövde anslutas till datorn längre. För att komma till ett databassystem behövde du bara en webbläsare. Så databastekniken måste dramatiskt förändras, för att hantera skalan på allt från de grundläggande sökmotorteknologierna som användes för att indexera världen och lagra ett informationsindex i exemplet med databasformatskala. Och människor som Google och andra skapade en plattform för att göra det. Och alla nya typer av databaslagring och frågning och indexering producerades. Och sedan fick vi musikwebbplatser och filmwebbplatser.
Och sedan på 2000-talet såg vi dot-com-boom, och det skapade en ännu mer dramatisk explosion i antalet människor som använde system som alltid drivs av en databas av någon form. Det här steget, relationella databaser som fortfarande hanterat det mesta av belastningen, vi lägger dem bara på större tenn, och vi gick till de mycket, väldigt, väldigt stora mellanklasssystemen som kör Unix-plattformar från människor som IBM och Sun och så vidare . Dot-com-boom gjorde saker och ting större och snabbare ur hårdvara, prestationssynpunkt, och det fanns några betydande förändringar i databasmotorerna, men för det bättre var det fortfarande samma sak som vi såg för en länge sedan.
Och sedan fick vi denna era av webb 2.0, som vi refererar till den. Och detta var en monströs förskjutning, för plötsligt behövde vi mycket enklare databasplattformar, och det måste finnas en skala i horisontell form. Och det var en så betydande förändring i sättet att vi närmade oss idén om vad en databas var. Vi hämtar fortfarande verkligen nu enligt min åsikt. Och nu har vi att göra med hela denna quagmire, och jag säger att med en positiv snurr, inte en negativ konnotation, denna quagmire av det vi kallar big data och en enorm explosion, och jag menar explosion. Denna skandalösa förskjutning vertikalt på diagrammet med antalet alternativ vi har när vi pratar om en databas, och någon form av relationell frågefunktion.
Och intressant nog anser jag personligen att jag tror att big data verkligen bara är toppen av isberget. Vi tenderar att bli lite upphetsade över hur effekterna av big data har varit och vilka typer av val vi har tillgängliga nu. Vi har allt från NoSQL-motorer, vi har grafmotorer, vi har alla dessa olika typer av plattformar som vi kan kasta data på och göra saker med det. Till och med till det faktum att en av de allra första konversationerna jag hade med Eric Kavanagh, som är här med oss idag, handlade om en konversation som rör en sak som heter Apache Drill, som är ett projekt med öppen källkod som låter dig fråga data inuti modellerar olika datatyper: allt från råa CSE-filer som sitter på en hårddisk, till HDFS-filsystem i petabyte-skala. Och du vet, det låter dig göra dessa frågor i SQL-stil med strukturerad och ostrukturerad data om alla typer av spännande växter.
Vi håller på att se "smart byggnad" bli en sak, och vi skulle vilja tro att vi har smarta byggnader av säkerhet och värmehantering, men jag pratar om smarta byggnader som vet mycket mer om vem du är och var du är när du går in och gör alla slags snygga saker på den nivån, till smarta städer - hela ekosystem på stadsnivå - som vet hur man gör saker intelligent. Och utöver det har vi denna otroliga sak som jag inte tror att någon i världen helt har tagit grepp om, och det är formen av tingenes internet. Det har skett alla dessa olika förändringar under det senaste decenniet och lite, kanske två decennier ungefär, om vi avrundar det, som på något sätt har påverkat världen av det vi anser databaser, enligt min åsikt.
Det har varit ett par viktiga saker som har gjort detta till och med möjligt. Kostnaden för hårddiskar har minskat dramatiskt, och på många sätt är det det som gjorde det möjligt att köra några av referensarkitekturerna, till exempel Hadoop-modellen, genom att vi tar massor av data och sprider den ut på massor av hårddiskar, och gör smarta saker med det. Och i själva verket, vad som efter min mening blev avskärmning av den relationsdatabas eller den traditionella DB-enhetsmodellen. Och RAM fick väldigt, mycket billigt, och det gav oss en helt ny möjlighet att spela med olika referensarkitekturer, till exempel i minnet, och att göra saker som att dela upp mycket, mycket stora klumpar med data.
Och så detta gav oss den lilla bilden som vi tittar på nu, vilket är ett diagram som visar vilka typer av plattformar som finns tillgängliga om du är i big data-landskapet. Och det är väldigt, mycket svårt att läsa, och orsaken till det, det finns bara för mycket information om det. Det finns så många tillverknings-, modell- och tillverkningsmöjligheter för sätt att lägga in data i databasesystem av vilken form som helst och fråga dem och göra de traditionella lässkrivningarna. Och de överensstämmer inte alla, i själva verket är det mycket få som till och med följer någon grundläggande stilstandard, men de anser sig fortfarande vara en databas. Och jag ska visa dig ett par skärmar på en sekund för att ge dig lite problem med vad jag menar med övergången från 90-talet och internetskalan, till webb 2.0 och sedan hela tillväxten genom big data. Om vi tycker att den här stora datateknologiska landskapsgrafen är spännande eftersom det finns många alternativ på det, låt oss bara titta på en nyckel vertikal.
Låt oss titta på marknadsföringsteknik. Här är alternativen för databashanteringssystem, eller datahantering i bara mar-tech-utrymmet, så teknik relaterad till marknadsföring. Nu var det 2011, så för några år sedan; För fem år sedan såg det ut som landskapet. Om jag bara går tillbaka en bild kort är det så dagens datalandskap ser ut i de olika varumärkena och erbjudandena vi har inom databasteknologier. Så här såg en vertikal ut för fem år sedan, bara inom marknadsföringsteknik.
Om jag går till dagens syn är det så det ser ut och det är helt ogenomträngligt. Det är bara denna vägg av märken och alternativ, och det är tusentals och tusentals kombinationer av programvara som anser sig vara i databasklassen, att den kan fånga, skapa eller lagra och hämta data i olika former. Och jag tror att vi går in i en väldigt, väldigt intressant och modig tid nu, där man en gång kunde känna till de stora varumärkena, man kunde känna till de fem eller sex olika plattformarna från Oracle och Informix, DB2 och så vidare, och vara nästan en expert på alla märken som fanns tillgängliga för 20 år sedan. För tio år sedan blev det lite lättare eftersom vissa av varumärken tappade och inte alla varumärken kunde klara storleken på dot-com-boom, och vissa företag gick bara sönder.
Idag är det absolut omöjligt att vara expert på all databasteknologi som finns, oavsett om det är relationella databaser eller standarddatabashanteringsplattformar som vi har lärt känna under de senaste decennierna. Eller sannolikt fallet, desto mer moderna motorer som Neo4j och dessa typer. Och så jag tror att vi kommer in i en väldigt modig värld där många alternativ finns tillgängliga, och vi har plattformar i skala på horisontell basis, antingen i minnet eller på disken nu. Men jag tror att det är en utmanande tid för beslutsfattare inom teknik och företag, eftersom de måste fatta några väldigt stora beslut om teknikstackar, som i vissa fall bara har funnits i huvudsak månader. Åtta månader gammal är inte ett läskigt nummer nu för några av de mer spännande och nya open-source databasplattformarna. Och de börjar slå samman plattformar och blir ännu nyare och mer spännande.
Jag tror att vi kommer att ha en bra konversation idag om hur allt detta har påverkat de traditionella databasplattformarna och hur de svarar på det och vilka typer av tekniker som kastas på det. Och med det i åtanke kommer jag att gå vidare till Dr. Robin Bloor och få hans insikter. Robin, över till dig.
Robin Bloor: Okej, tack för det. Ja, det här är alltför stort ämne. Jag menar, om du bara tog en del av en av de illustrationer som Dez just visade dig, kan du ha en lång konversation nästan om en av sliversna. Men du vet, du kan gå till en databas - Jag har tittat på databaser, jag vet inte, sedan 1980-talet, och du kan titta på databasen på olika sätt. Och en av de saker som jag tänkte att jag skulle göra, bara kasta in i konversationen idag, var att prata om orsaken till att störande saker har hänt på maskinvarunivå. Och du måste komma ihåg, det har faktiskt hänt en hel del störande saker på mjukvarunivå, så detta är inte hela bilden av någonting, det här är bara en hårdvarosak.
Jag tänkte inte prata särskilt länge heller, jag ville bara ge dig hårdvarubilden. En databas var datainsamlingsfunktioner som spänner över CPU, minne och disk, och det förändras dramatiskt. Och anledningen till att jag säger det var att jag lärde mig att förstå databasen ur perspektivet av vad du faktiskt gjorde. Du vet, det finns en skillnad i latens mellan data som faktiskt finns på CPU, och data som dras in i CPU från minnet och data som dras från skiva till minne och genom CPU. Och de gamla databasarkitekturerna försökte bara balansera det. Du sa, de sa bara, "Det går väldigt långsamt, vi kommer att cache data på disken så att de finns i minnet. Vi kommer att försöka göra det på ett riktigt exakt sätt så att en riktigt bra del av de uppgifter vi ber om redan finns i minnet. Och vi kommer att marschera data till CPU så snabbt som vi faktiskt kan. "
Och databaser skrevs i gamla dagar maskiner skrivna för små kluster. Och nu för okunnighet om parallellism. För om du kommer att få lite prestanda ur ett kluster måste du göra olika saker parallellt. Parallellism är en del av spelet, ingenting som det är nu. Jag kommer bara att gå igenom vad som hände.
Först av allt, disk. Tja, disken är över, verkligen. Det är ganska mycket över vad gäller databaser. Jag tror att det finns ett antal nackdelar med arkivering av data, och till och med mycket stora dataljöar som körs på Hadoop, den värsta snurrande disken är förmodligen livskraftig idag. Problemet med spinndisken var verkligen att läshastigheterna inte förbättrades särskilt mycket. Och när CPU började höja Moores laghastigheter, typ av storleksordning, snabbare vart sjätte år. Och minnet följde lite efter i kölvattnet, då höll de två rimligt i takt med varandra, det var inte helt smidigt, men de gjorde det.
Men den slumpmässiga läsningen till en disk där huvudet flyger om disken, jag menar, bortsett från allt annat, det är en fysisk rörelse. Och om du gör slumpmässiga läsningar från en disk, är det otroligt långsamt jämfört med läsning från minnet, det är som 100 000 gånger långsammare. Och ganska nyligen har de flesta databasarkitekturer som jag har sett på något djup faktiskt bara läst seriellt från diskar. Du vill verkligen på ett eller annat sätt bara cache så mycket du kan från disken och dra bort den långsamma enheten och lägga den på en snabb enhet. Och det är mycket smarta saker du kan göra med det, men det är lite över.
Och solid-state-skivor, eller flash-enheter, verkligen, är vad de är, ersätter mycket snabbt snurrdisken. Och det förändras helt igen, eftersom det sätt på vilket data organiseras på en disk är organiserat enligt hur skivan fungerar. Det handlar faktiskt om ett huvud som rör sig över en snurrande yta, faktiskt flera huvud som rör sig över flera snurrande ytor och plockar upp data när de går. En solid-state-enhet är bara ett block av saker som du kan läsa. Jag menar, det första är att alla de traditionella databaserna konstruerades för att spinna disken, och de omarbetas nu för SSD. Nya databaser kan antagligen - vem som helst som skriver en ny databas just nu kan förmodligen ignorera snurrdisken, inte tänka på det alls. Men Samsung, den största tillverkaren av SSD: er, berättar att SSD: er faktiskt ligger på Moore's lagkurva.
De var redan, tror jag, ungefär tre eller fyra gånger snabbare än spinndisken, men de kommer nu att bli mycket snabbare var 18: e månad, i princip. Dubbel hastighet och tio gånger i hastighet upp till cirka sex år. Om det bara var det, så är det inte det, som jag kommer att säga er på ett ögonblick. Snurrdisken blir naturligtvis ett arkiveringsmedium.
Om minnet. Första saker först, RAM. CPU-förhållandet mellan RAM per CPU ökar bara hela tiden. Och att det naturligtvis på ett sätt levererar väldigt mycket mer fart, eftersom de tunnlandminne som du kan ha nu kan lagra mycket mer. Vad det här faktiskt gör är att det sänker på något sätt trycket på applikationer av MLTP eller slumpmässiga läsningsapplikationer, eftersom det är lättare att tillgodose dessa, eftersom du nu har mycket minne, och på så sätt kan du cache allt som är sannolikt att läsas in i minnet. Men du stöter på problem med en större datahög, så big data är egentligen inte så enkelt, egentligen.
Och sedan har vi Intel med 3D Xpoint, och IBM med vad de kallar PCM, som är fasförändringsminne, levererar något som de tror är - ja, det är minst 10 gånger snabbare än nuvarande SSD: er, och de tror att det kommer att bli mycket nära att vara samma hastighet som RAM. Och naturligtvis är det billigare. Så tidigare hade du den här databasstrukturen för CPU, minne och disk, och nu går vi mot en struktur som har fyra lager. Det har CPU, minne eller RAM, och sedan den här typen av snabbare än SSD-minne, som faktiskt är icke-flyktigt, och sedan SSD. Och dessa nya tekniker är icke-flyktiga.
Och det finns HP: s memristor, som inte är ännu, du vet, för den tillkännagavs för sju år sedan, men den har ännu inte dykt upp. Men rykten jag hör är att HP kommer att ändra spelet lite med en memristor också, så du har bara en ny minnesituation. Det här är inte som om vi har snabbare grejer, det är som om vi har fått ett helt nytt lager. Och så har vi det faktum att SSD-åtkomst, du kan läsa den parallellt. Du kan inte läsa spinnskivan parallellt, förutom genom att ha många olika snurrskivor. Men ett block av SSD, kan du faktiskt läsa parallellt. Och eftersom du kan läsa det parallellt går det mycket snabbare än dess enkla läshastigheter, om du faktiskt ställer in flera processer mellan olika processer på en enda CPU och bara har det med SSD.
Det uppskattas att du kan få nästan upp till RAM-hastigheter genom att göra det. Och allt detta säger är att minnesarkitekturens framtid är oklar. Jag menar, verkligheten är att de olika dominerande leverantörerna, vem de än visar sig vara, förmodligen kommer att bestämma hårdvarans riktning. Men ingen vet vart det går vid denna tidpunkt. Jag har pratat med några databasingenjörer som säger: "Jag är inte rädd för vad som händer", men de vet inte hur de ska optimeras från start. Och du gjorde alltid så, så det är intressant.
Och så finns CPU: n. Tja, flerkärniga CPU: er var inte bara flerkärniga CPU: er. Vi har också betydande volymer av L1, L2 och L3 cache, särskilt L3, vilket är upp till, jag vet inte, tiotals megabyte. Du kan lägga mycket där, du vet. Och därför kan du faktiskt använda chipet som ett cachemedium. Så det förändrade spelet. Och säkerligen, vektorbearbetning och datakomprimering, har ett antal leverantörer faktiskt gjort det, dragit det på CPU: n för att göra det allt mycket snabbare på CPU: n. Då får du det faktum att CPU: er med GPU: er är riktigt bra på att påskynda analysen. Och de är verkligen ganska bra på vissa typer av frågor, det beror bara på vad din fråga är.
Du kan antingen skapa kort med CPU och GPU på, eller som AMD gör just nu, du producerar något som kallas en APU, som är ett slags äktenskap mellan en CPU och en GPU; det har båda typerna av kapacitet. Så det är en annan typ av processor. Och sedan det senaste tillkännagivandet från Intel att de kommer att sätta en FPGA på chipet, den typen av gjorde mitt huvud i. Jag tänkte: "Hur i all värld kommer det att hända?" För om du har möjlighet till CPU, GPU, och du har möjlighet till CPU, FPGA - och förresten, om du verkligen vill, på samma kort kan du sätta en CPU, en GPU och en FPGA. Jag har ingen aning om hur du faktiskt skulle driva någonting på det sättet, men jag vet om företag som gör saker som det här och de får väldigt mycket snabba frågor. Det här är inte något som kommer att ignoreras, det är något som kommer att användas av de etablerade leverantörerna och av nya leverantörer som kanske kommer upp. DBMS var alltid parallella, men nu har de parallella möjligheterna just exploderat, eftersom det här gör att du kan parallellisera detta med det, med det, med det på olika sätt.
Till sist, för att skala upp eller skala ut? Uppskalning är verkligen den bästa lösningen, men för en sak. Du får mycket bättre nodprestanda om du helt enkelt kan optimera CPU-prestandan och minnet på disken på en nod. Och du kommer att använda färre noder, så det kommer att bli billigare, eller hur? Och det blir lättare att hantera. Tyvärr är det en hårdvaruberoende design, och när hårdvaran ändras blir det mindre och mindre möjligt att göra det, såvida inte dina ingenjörer kommer att kunna köra så snabbt som hårdvaran förändras. Och du får problem med arbetsbelastningen, för när du skalar upp gör du olika antaganden om vad arbetsbelastningen kommer att göra.
Om du skalar ut, det vill säga, om din arkitektur betonar skala innan du skalar upp - du måste faktiskt göra dem båda, är det bara att du betonar en. Då får du bättre nätverksprestanda, eftersom arkitekturen kommer att hantera det. Det kommer att bli dyrare i hårdvarutillstånd eftersom det kommer att finnas fler noder, men det kommer att bli färre problem med arbetsbelastningen och det kommer att bli mer flexibel design.
Och jag tänkte bara att jag skulle slänga in det, för om du faktiskt tänker på alla hårdvaruförändringar pekade jag bara fingret på, och sedan tänkte du på, hur ska du skala upp och skala ut det? Då inser du att databasingenjörer, enligt min mening, åtminstone är väl underbetalda. Så om du bara funderar på hårdvaruskiktet är databasutmaningarna tydliga. Nu överlämnar jag detta till Bert, som kommer att få oss alla att känna oss utbildade.
Eric Kavanagh: Det är allt! Bert?
Bert Scalzo: Tack så mycket. Låt mig bara komma in i dessa bilder. Jag har många bilder att gå igenom, så på en hel del av dem kanske jag går ganska snabbt. Vi kommer att prata om det här "Framåtmomentet: Flytta relationellt utöver traditionell." Det är inte din fars databas längre. Saker har förändrats, och som en tidigare talare sa, de senaste sex till sju åren har landskapet förändrats radikalt.
Jag själv har gjort databaser sedan mitten av 80-talet. Jag har skrivit böcker om Oracle, SQL Server, benchmarking och en hel del andra saker. ”Världen förändras mycket snabbt. Big kommer inte att slå litet längre. Det kommer att vara det snabbaste som slår långsamt. ”Jag lade till“ att anpassa sig. ”Det var från Rupert Murdoch. Jag tror verkligen att detta kommer att vara sant. Du kommer inte att kunna göra databasmaterial som du gjorde för 10, 15, 20 år sedan. Du måste göra det på samma sätt som företaget vill ha det nu.
Jag kommer att försöka hålla mig lite generisk i det jag presenterar, men de flesta funktioner jag pratar om hittar du i Oracle, hittar du i SQL Server, MySQL, MariaDB och några av de andra stora spelare. Den relationella databasrevolutionen håller jag igen med de tidigare talarna. Om du ser rätt ut 2010 gick vi från den röda tävlingsbilen till den gula tävlingsbilen. Det skedde en betydande förändring, och fram till 2020 tror jag att du kommer att se en annan radikal förändring. Vi har en mycket intressant tid.
Nu är den här bilden nyckeln, det är därför jag lägger en nyckel där uppe. Det är all denna förändring som pågår, och på vänster sida har jag teknik och på höger sida har jag affärer. Och frågan är, vilken orsakar vilken, och vilken stöder vilken? Vi har alla dessa hårdvaruändringar: diskar som kommer ner, hårddiskstorlek går upp, nya typer av diskar, så det täcktes av de tidigare högtalarna. Priset för att minska minnet, alla dessa nyare versioner av databaser. Men på höger sida har vi dataskydd och efterlevnad, datalagring, affärsinformation, analys, obligatorisk datalagring. Båda sidorna av ekvationen kör, och båda sidorna av ekvationen kommer att använda sig av alla dessa nya funktioner.
Först och främst har vi vår typiska SAS spinndisk, de är upp till 10 terabyte nu. Om du inte har sett, Western Digital, har HGST vad de kallar sin helium-enhet, det går upp till cirka 10 terabyte just nu. Kostnaderna för snurrdisken blir ganska låga. Som nämnts tidigare kan du få hårddiskar upp till cirka två terabyte, men Samsung har en 20-terabyte-enhet som kommer snart. Kostnaderna blir rimliga. En sak jag ska prata om de andra inte, är begreppet flash-diskar. PCIe, det är PCI Express, kontra NVMe, du kanske eller inte har hört talas om detta, icke-flyktiga minnesuttryck. I grund och botten kommer NVMe att ersätta SAS och SATA, och det är egentligen mer ett kommunikationsprotokoll än något annat. Men dessa diskar är upp till cirka tre terabyte nu.
Du kanske också har sett att vissa SAS-enheter nu har U.2-anslutningar, som är en slags anslutning än en SAS eller SATA, som stöder NVMe med en standarddisk - skivan måste naturligtvis också stödja den. Och sedan SATA med M.2-kontakter, och de börjar få NVMe. Det finns faktiskt bärbara leverantörer som nu säljer anteckningsböcker som har en NVMe-flash-disk i sig, och dessa saker kommer att skrika jämfört med tekniken du har använt tidigare.
Många människor vet inte vad alla dessa olika blixtar är. Om du tittar i det nedre högra hörnet är det ett exempel på en M.2. Du kan säga, "Tja, det ser mycket ut som mSATA-enheten till vänster om den." Men som ni ser har det två luckor i stiften i motsats till en, och den är lite större. Och M.2 kan också levereras i tre olika storlekar.
Och sedan blinkar PCI Express och NVMe. Nu är NVMe-blixten också PCI Express, men PCI Express är vanligtvis fortfarande en SAS- eller SATA-typ-kontrollalgoritm som har skrivits för spinndisk, och NVMe är de algoritmer eller tekniker som har skrivits specifikt för flash. Och igen kommer du att se alla dessa.
NVMe erbjuder en hel del saker. Jag tror att de två största förbättringarna är att uppe i det övre högra hörnet reduceras latensen med så mycket som 70 procent. Jag har faktiskt sett ännu högre än så. Om du ser i det nedre högra hörnet, när ditt operativsystem pratar med NVMe-disken, går det igenom mycket färre nivåer av programvara. I princip går du igenom NVMe-drivrutinen som ingår nu i operativsystemet, och den pratar direkt med media. Det finns många skäl till varför den här tekniken kommer att förändra databasvärlden radikalt.
Och många gånger kommer människor att säga, "Tja, hur snabbt är NVMe?" Du vet, de gamla goda dagarna, tillbaka 2004 och innan, blev vi glada om vi hade Ultra-320 SCSI, 300 megabyte per sekund. Dagens hastigheter, många av er är antagligen på fiber eller InfiniBand, och den typen av topp ut. NVMe där borta till höger, börjar där den nuvarande tekniken slutar. Vad jag får till är att PCI Express 3.0 med en åtta-länk-länk börjar på nästan 8000, och det kommer att gå upp när vi får nyare versioner av PCI Express, versioner fyra och så vidare. NVMe har ingenstans att gå utom upp.
Vad förändras nu i databasen? Nu i de övre högra hörnen av mina bilder, satte jag de affärsmässiga skäl som jag tror att tekniken visade sig. I det här fallet, på grund av datalagring och på grund av reglerande skäl för obligatorisk datalagring, börjar databaserna erbjuda komprimering i dem. Några databaser erbjuder komprimering som ett tillägg, vissa erbjuder det som inbyggt i standarden, låt oss säga företagsutgåva av deras databas, och ändå kan vissa databaser, som i Oracle, till och med ha en ännu bättre version av komprimering som är i, till exempel, deras Exadata-plattform, så att de faktiskt har byggt hårdvara som kan stödja en mycket specialiserad komprimering och den i Exadata, till exempel, får en 40x kompressionsfrekvens, och så det är mycket betydande. Och jag tror att det är obligatorisk datalagring, människor vill bara ha data längre. Företagen, för att göra analyser och BI behöver de de senaste 5, 10, 15 års värdet av data.
Nu en annan funktion som började dyka upp runt den perioden 2008-2009 var partitionering. Återigen hittar du detta i databaser som Oracle, SQL Server, och i båda av dem måste du betala för det. I Oracle måste du köpa partitionsalternativet och i SQL Server måste du vara med på datacentret. Det är din traditionella klyft-och-erövringsteknik och vad du gör är att du har konceptet med ett logiskt stort bord överst där och när det sätts på skivan är det faktiskt uppdelat i hinkar. Och du kan se att dessa hinkar är organiserade efter vissa kriterier för att separera, vanligtvis refereras till eller kallas din partitionsfunktion, och sedan kan du också dela upp en partition i vissa databasplattformar och du kan gå ännu längre.
Återigen tror jag att både datalagring och obligatorisk datalagring har drivit detta, och i vissa av dessa databaser kan du ha upp till 64 000 partitioner, och jag tror på vissa andra databaser till och med upp till 64 000 underpartitioner. Detta gör att du kan dela upp dina uppgifter i hanterbara delar. Du kommer också att dela upp indexen; det är ett alternativ du inte behöver, men du kan också dela upp dina index. En av orsakerna till detta kan vara att du har ett skjutfönster med data. Du vill behålla data om 10 år men för att släppa indexen för att köra ikvälls batchbelastning, behöver du inte släppa indexen på varje enskild rad, bara på raderna i den aktuella hinken. Partitionering är faktiskt ett mycket bra administrativt verktyg även om de flesta tycker att dess stora fördel är att avbryta partition eliminering i dina planer och därför påskynda dina frågor. Det är verkligen typ av glasyr på kakan.
Nu har du antagligen hört talas om skärning och du tänker antagligen, "Tja, varför satte du in den här bilden här?" Det här är en av dessa NoSQL - det här är en av Hadoop-miljöerna. Oracle 12c släppte två, som inte är G8 ännu, men som visas eller förhandsgranskas har faktiskt skärvning i den. Du kommer att ha ett traditionellt databassystem som Oracle och du kommer att kunna skärpa som du gör i Hadoop-modellen, och så kommer du att ha en annan uppdelning och erövringsteknik som kommer att dela upp din tabell radvis i grupperingar per nod och detta kommer att bli - precis som vad du ser i några av dina NoSQL-databaser. Och faktiskt MySQL, du kan faktiskt åstadkomma det här ganska mycket med hjälp av en av deras klusteringstekniker, men det kommer till en traditionell databas och jag antar att Microsoft inte vill bli kvar. Dessa två spelar hoppa groda med varandra hela tiden så jag förväntar mig att se skärning i kanske nästa version av SQL Server.
Livscykelhantering av data, återigen obligatorisk datalagring, men också för business intelligence och analys. Det här är verkligen en splittring-och-erövringsteknik, och vanligtvis gör DBA: er manuellt, och det är: ”Jag kommer att behålla årets data på snabba skivor, förra årets data på något långsammare diskar, kanske jag kommer för att behålla de senaste två åren innan det på ännu långsammare skivor, och sedan har jag någon arkiveringsmetod. ”Det är vanligtvis inte tejpade längre, det är vanligtvis - du har någon form av nätverksmonterad lagring eller någon enhet som har massor lagring och är, du vet, kostnadseffektivt men det är fortfarande snurrdisk.
Och så nu kan du faktiskt - både på Oracle och på SQL Server - du kan köpa ett alternativ där du definierar reglerna och detta händer bara automatiskt i bakgrunden. Du behöver inte skriva skript längre, du behöver inte göra någonting. Och om du har sett SQL Server 2016, som just kom ut första juni, finns det en ny funktion som heter "Stretch Databases" som i princip låter dig göra - i det nedre högra hörnet där - kan du flytta från flera lager direkt i molnet och igen är detta en funktion som är inbyggd i databasen, du säger bara något som "Om uppgifterna är mer än 365 dagar gamla, vänligen flytta den till molnet och, du vet, gör det automatiskt för mig."
Detta kommer att bli en riktigt cool funktion, jag tänker faktiskt att det kan vara det vi kommer att se i framtiden, vilket är att du kommer att ha hybriddatabaser där du kommer att hålla lite lokalt och några i molnet. Innan detta tänkte människor, "Åh, jag kommer antingen att göra på plats eller så kommer jag att göra på molnet." Nu ser vi äktenskapet mellan de två teknikerna på detta hybridmode. Jag tror att detta kommer att bli ganska stort och Microsoft kom dit först.
Redaktion, detta beror på dataskydd och efterlevnad. Nu i de gamla goda dagarna kan vi ha sagt, "Hej, applikationsutvecklare, när du visar detta i rapporten, när du visar detta på skärmen här är några säkerhetssaker du bör kontrollera och snälla, du vet, bara visa data de ska se eller maskera eller redigera data som de inte ska se. ”Tja, som vanligt, när du skjuter ut det till applikationen görs det inte på ett ställe så det görs annorlunda eller så gör det inte blir inte klar på vissa ställen. Och så nu har du faktiskt fått denna kapacitet i dina databasesystem.
Nu i SQL Server 2016 är den här funktionen inbyggd så att den inte är en valfri kostnadspost ännu att ligga på datacentret, tror jag; och i Oracle 12 måste du köpa deras tillägg till livscykelhantering, men det här är något nytt och återigen drivs det av verksamheten. Och särskilt för att du håller så mycket data nu, och du gör data mining, så BI och analysen, måste du veta vem som har åtkomst till vilken data och se till att de bara får se vad de får se.
På samma sätt, titta igen på det, dataskydd och efterlevnad. Du kommer att upptäcka att många av databasesystemen nu bygger komprimering, eller jag är ledsen, kryptering direkt i databasen och vad som är viktigt med den här krypteringen, om du tittar på nedåtpilen och uppåtpilen på diagrammet skriver den det ner till disk krypterad och sedan läser den tillbaka till minne och dekrypterar det. Det är faktiskt en modell, det finns en annan modell som, du vet, faktiskt bara gör det när den kommunicerar data över nätverket till den faktiska klientapplikationen.
I så fall skulle den till och med fortfarande på databasservern i minnet kunna krypteras och bara dekrypteras när den skickas över till klientapplikationen. Det finns två olika modeller här och du hittar dessa i databaserna, och i själva verket en av databaserna som just har lagt till detta nyligen var MariaDB i deras version 10.X; Jag tror att de är på 10.1 eller 10.2 nu. Och jag gjorde faktiskt en viss benchmarking för den här krypteringen, och för att få den här krypteringen upplevde jag bara cirka 8 procent minskning av genomströmning eller hastighet. I ett benchmarkingtest orsakade inte krypteringen så mycket och det är därför en mycket användbar funktion.
Nu har vi nämnt tidigare om flashminne och SSD: er och sådant. En av de funktioner du har i Oracle och SQL Server som många inte inser är att du kan ta en blixt eller SSD som finns på din databaseserver och du kan säga till databasen: "Använd det här som om det var minne. Behandla RAM som förmånligt, men låtsas som att det här är ett långsamt minne och använd det som en utökad cache. "Nu i SQL Server 2014 kom detta ut och kallades" Buffer Pool Extension ", det är gratis. I Oracle kom den ut i 11g R2 och den kallades "Databas Flash Cache" och den var också gratis där.
Mitt råd är dock att provköra denna funktion noggrant. Varje gång du gör cachen större när du gör en tittning tar det längre tid. Om du lägger ett tre-terabyte flash-kort och säger till databasen, "Lägg till det i ditt minne", kan du faktiskt upptäcka att något bromsades på grund av tiden att titta in och se är det i flash, är det en smutsig eller rena? Det finns en punkt att minska avkastningen. Mitt råd är igen testkörning här, se vad som fungerar för dig, men igen, det finns i din databas och i fall av Oracle's, i både SQL Server och Oracle, har det funnits i ett par år nu.
Och sedan tar det oss till farfar som var databaserna i minnet och det beror på att databaspriserna har sjunkit. Det andra skälet till att du antagligen skulle tro att detta har inträffat är att mycket av analysen kräver att data är mycket snabbt tillgängliga, och det måste därför vara i minnet. Observera att algoritmerna som databaserna använder för att få åtkomst till dessa data, för att komprimera dem, för att kryptera dem, för att lagra dem, du vet att i vissa fall vissa databaser kan fortsätta att lagra i minnet som en rad.
I vissa fall kan vissa databaser dela upp detta i en kolumnorienterad och anledningen till att de gör det är att de får en mycket högre komprimeringsnivå, någonstans runt 11 till 12X genom att lagra den i kolumnordning jämfört med radordning. Detta visades först i SQL Server 2014, det kallades "Hekaton." Det har ökat radikalt i SQL Server 2016, de kommer att se det refereras av några olika namn och det kom ut i Oracle 12c; Jag säger den andra utgåvan här, inte R2. Det fanns två olika utgåvor av Oracle 12c, 12.1.0.1 och 12.1.0.2. Det är den andra utgåvan av R1-versionen av databasen.
Och det sätt som du definierar det, i minnet-objekt är liknande i båda databaserna. Här kan du se till höger uppe i hörnet, jag skapar en SQL Server och du kan se den säger med minne optimerat och hållbarhet endast är schema. Jag tänker inte gå igenom alla dessa syntaxbetydningar, och i Oracle är det faktiskt ännu enklare, du ändrar bara ett bord och säger i minnet eller inte och du kan ändra det. Jag kan säga att det i dag är i minnet och imorgon är det inte och det är väldigt flexibelt.
Jag gjorde några tester på Oracle med minnetabeller, jag hade några tester som tog nästan 40 minuter att köra, där uppe på toppraden. Vad som är viktigt är när jag kom till de två nedre raderna, jag hade ökat körtiden eller minskat den, skulle jag säga, till fem minuter ungefär, och när jag tittade på kompressionsfaktorn var data i minnet faktiskt 3,6 till 4,6 gånger mindre. Det är viktigt eftersom jag i detta fall använde kolumnorienterat format och det är komprimering. Och så gissa vad? Jag passade faktiskt nästan fyra till fem gånger så mycket data i mitt minne. Inte bara fick jag fördelen med minnet, fördelen med kolumnorienterad, utan också fördelen med mycket mer data - upp till fem gånger så mycket data i minnescachen, så det här är en ganska kraftfull teknik. Återigen Oracle och SQL Server, du vill titta på dessa, de är riktigt coola funktioner. Och med det tror jag att jag kommer att öppna det för frågor.
Eric Kavanagh: Tja Bert, för det första har du varit väldigt osjälvisk i all denna underbara utbildning. Kan du prata bara en minut om vad ni gör? Eftersom du har någon möjliggörande teknik som kan underlätta det du har pratat om. Prata bara en minut om vad ni gör, och låt oss sedan få Dez och Robin ner i ekvationen här.
Bert Scalzo: Ja, jag jobbar för ett företag som heter IDERA. Vi är i Texas, vi har huvudkontor i Houston, och jag sitter faktiskt i Austin just nu men jag är baserad i Dallas. Vi skapar databasverktyg och vi skapar databasverktyg som hjälper dig att lösa problem. Det problemet kan vara något så enkelt som produktivitet, i vilket fall har vi ett verktyg som heter DBwartan som låter dig utföra dina databasadministrativa uppgifter och det är ett verktyg som låter dig hantera 12 olika databasplattformar. Jag kan hantera SQL Server, jag kan hantera Oracle, jag kan hantera MySQL, DB2, Postgres och jag använder ett verktyg, ett körbart, ett GUI-design och en konsekvent uppsättning arbetsflöden. Vi skapar också verktyg för att utföra efterlevnad, vi har ett verktyg som heter SQL Compliance Manager för att hjälpa dig att uppfylla dina efterlevnadsbehov. Ett annat verktyg som heter SQL Security, så vi försöker göra verktygen som hjälper dig att vara effektiva och effektiva, och vad som verkligen är trevligt om du går till vår webbplats, vi har en hel massa freeware där ute, så om ingenting annat, ladda ner - Jag tror att vi har 20 eller 25 freeware. Det finns några riktigt bra freeware-saker där, som att det finns en SQL Server och en Windows Hjälpkontroll som bara kommer att titta på vad du har och berätta om du har problem eller saker och det är helt gratis.
Eric Kavanagh: Och du verkligen typ av—
Bert Scalzo: Definitivt de första sakerna—
Eric Kavanagh: Du talar till heterogeniteten på marknaden idag, det brukade vara en slags ekvation i en storlek som passar alla som jag faktiskt minns att jag intervjuade Dr. Michael Stonebraker långt tillbaka 2005, när han gick på ett stort tryck han pratade om dom i den kolumnorienterade databasrörelsen och han pratade allt om hur en-storlek-passar-alla-relationella modellen dominerade under många år, och han förutspådde att allt skulle förändras, och pojke hade han rätt i det. Nu har vi denna riktigt mångsidiga och intressanta miljö med massor av olika alternativ och möjligheter, men du behöver någon för att hantera allt detta och det verkar för mig att ditt företag är fokuserat ganska akut på att lösa matematiska problem och därmed vara en möjliggörare för heterogenitetens rubrik, eller hur?
Bert Scalzo: Absolut. Jag menar att det alltid kommer att finnas DBA som säger: "Jag vill inte använda ett GUI-verktyg, jag gör allt med skript," vet du? De tycker att de är superman-typen av DBA och det är bra, men för de flesta av oss människor vill vi bara göra arbete och - du vet, jag använder Microsoft Word för att skriva mina dokument. Jag använder Microsoft Outlook för att göra mitt. Jag menar, jag har verktyg för att utföra uppgifter. Vi bygger samma typ av koncept, vi bygger verktyg för databasadministratörer och utvecklare för att hjälpa dem att fokusera på vad de vill göra och inte hur de måste göra det.
Eric Kavanagh: Det är meningsfullt, men låt mig överlämna er till våra experter, och folk känner sig fri att dyka in. Vi har några kommentarer från publiken. Kanske, Dez, ett par frågor och Robin ett par frågor?
Dez Blanchfield: Säker. En av de första frågorna som jag vill kasta till dig, med tanke på den enorma erfarenhet du fick, ser du en tidpunkt när något av detta kommer att sakta ner? Eller tror du att vi verkligen bara är vid utgången av denna ständiga tillväxtlinje för förändring? Jag tror att en av de största problemen som företagen står inför, och då alltid de som försöker stödja tekniken som företagen för att driva sina företag är att förändringsgraden är så dramatisk att de bara inte kan hålla jämna steg med alla de olika funktionerna, programvaran och systemen, och ramar och arkitekturer, och ny kod kommer upp, och sedan hårdvaran under det, ser du den aktuella förändringshastigheten avta alls? Jag menar, du hanterar ett så brett utbud av plattformar med hela IDERA-sviten, kommer vi att sakta ner snart eller är vi på det här galna goda tåget länge ännu?
Bert Scalzo: Jag tror att vi är vid de första 20 procenten av den tillväxtkurvan och vi har en lång väg att gå och det är två saker som driver det. Tekniken fortsätter att utvecklas. Du har nämnt några av de nya minnestyperna som kommer att komma ut, det kommer att bli fantastiskt. Samsungs kommer att ha en 20-terabyte flashenhet här verkligen snart. Det kommer att förändra saker. Vi har alla dessa NoSQL- och molndatabaser, detta kommer bara att fortsätta. En sak som är ganska rolig är dock när jag tittar på databaser som Oracle och SQL Server och några av de andra, de är verkligen inte relationsdatabaser längre. Jag kan lägga in ostrukturerad data i Oracle och ändå behålla ACID-överensstämmelse. Om du skulle ha berättat för det för 20 år sedan, hade jag bara sagt att du var på droger.
Dez Blanchfield: Ja, ja, de är coola. Tja även nu de motorer som har ganska fina nischvertikaler som GIS, bara bättre än inbyggd kapacitet nu. Du kom med några fantastiska kommentarer om de utmaningar som DBA står inför och de olika tiderna för DBA som vi hoppas se runt om i stället, men hur ser världen ut med det slags lager av verksamheten som du har att göra med? Jag menar, det här är de människor som använder de olika plattformarna från din diagnostikhanterare, till inventeringsverktygen och hela vägen ner till bälgen till defraggeringen, hur hanterar DBA: s denna förändring och hur gör de det - du vet , vad gör de med dina verktyg för att hantera den här betydande förändringen i deras landskap?
Bert Scalzo: Tja, jag kommer att gå tillbaka för nästan 20 år sedan, då ska jag säga att DBA löser en mycket specifik roll i en organisation. De arbetar vanligtvis med en databasplattform, kanske två, och de hanterade ett relativt litet antal databaser. Nu snabb framåt till idag och databasadministratören, han kommer faktiskt att känna till 10 databasplattformar. Han hanterar, och detta är inget skämt, i vissa fall tusentals databaser; det är mer om SQL Server-världen eller MySQL-världen. Men fortfarande i Oracle-världen kunde de hantera hundratals databaser. Och så de har alla dessa nya funktioner kommer ut, de har alla dessa nya plattformar, och de har alla dessa databaser de är ansvariga för. De letar efter verktyg för att möjliggöra deras produktivitet och också för att hjälpa dem att lära sig några saker.
Och jag ger dig ett exempel - om jag vill dela upp en tabell är det en ganska obskur syntax, och om jag vill dela upp den blir syntaxen ännu svårare. Jag vet vad jag vill göra, jag vill skapa hinkar. Om jag har ett verktyg som DBwartan som säger: "Hej, här är en fin skärm som låter dig koncentrera dig på vad du försöker göra snarare än hur du försöker göra det, och åh förresten, tryck på Visa SQL-knappen när du är klar och vi visar dig vad SQL var så att du kan börja verkligen lära dig och behärska detta. ”
DBA: er hittar att verktyg som hjälper dem att få jobbet gjort men också hjälper till att lära dem alla dessa nya saker som de använder och detsamma skulle vara sant - låt oss säga att jag är en Oracle-kille och jag går över till MySQL och säger, ”Okej, skapa en databas, DBwartan. Visa mig nu SQL eftersom jag undrar hur det är att skapa en databas på MySQL och jag har bara lärt mig syntax. ”Och så hjälper vi dem inte bara att arbeta över hela databasen, vi utbildar dem också över hela databasen.
Dez Blanchfield: Det blir ännu mer intressant när du kommer ut till några av de mer moderna - eller inte mer moderna, det är inte en rättvis sak att säga - men en gång i tiden är en databas en databas. Idag ser jag allt du pratar om där med den extra utmaningen som tekniken staplar som vi traditionellt ser från leverantörer och du sorterar öppen källkod till den och också att de är bra. Inte bara ta itu med databasmotorerna och frågespråken, utan de handlar också om datatyperna, det strukturerade och ostrukturerade, du vet, utmaningen att behöva ta itu med allt från den yttersta delen av spektrumet för en multi-petabyte HDFS miljö till små små behållare och paketfiler och olika loggfilformat.
Och jag tror att det är någonting vi ser där det bara är ingen människa, oavsett hur mycket av en superman, superkvinna, vad de än tror att de är, de fysiskt, de kan bara inte mentalt hantera den förändringsgraden och variationerna. Jag tror att sviten med verktyg du erbjuder nu kommer att komma till en punkt där de nästan kommer att ligga på en standarduppsättning på många sätt så att vi inte kan köra de databasmiljöer vi har utan dem eftersom vi bara fysiskt kan inte kasta så många kroppar på dem. Jag gillade verkligen din presentation. Jag kommer att överföra till Dr. Robin Bloor, jag är säker på att han har massor av frågor att kasta på dig också.
Robin Bloor: Okej. Jag har verkligen frågor. Bert, jag vet inte vart du ska - jag hade ett riktigt intressant samtal för ett par dagar sedan där någon började berätta om det senaste DU-dataskyddet, och det verkade för mig utifrån vad de sa att det var otroligt drakoniska när det gäller saker de insisterade på. Jag undrade om du verkligen tittade på det; är det något du är bekant med?
Bert Scalzo: Absolut. Ja.
Robin Bloor: 2016, okej, berätta om det.
Bert Scalzo: Och jag har faktiskt—
Robin Bloor: Djupt intressant.
Bert Scalzo: Jag arbetade faktiskt ett tag för en flashförsäljare, i deras databasområde och hjälpte dem att bygga flashprodukter för databaser, och jag kan säga er att draken går hela vägen ner. Vad jag menar är, om du kommer ihåg min ena bild, sa jag i vissa databaser att det kommer att göra krypteringen men det sätter det i serverminnet och i vissa databaser är krypteringen - den är fortfarande krypterad i serverminnet, den krypteras bara när det skickas till klienten. Vad du också hittar är några av dessa regeringsstandarder, särskilt försvarsdepartementet eller militär här i USA, de går också hela vägen ner till blixtnivån och de vill veta inte bara att du stöder kryptering och dekryptering i din hårdvara, men att om någon stal chips som - du vet, drog dem ur saken, ur din server, att vad som finns där är krypterat och så även om de har lagring kan det inte vara och de skulle hela vägen ner till själva - inte till själva blixtdelen utan ner till de enskilda chips. De ville veta att chip för chip, allt var krypterat.
Robin Bloor: Wow. Jag menar att det finns många saker som - du vet, jag tror att det bara var en eller två bilder som du har tagit fram det här, men det var något, ett scenario som jag tycker är riktigt intressant. Reducering av information till exempel, det måste vara lite smart än att bara maskera bort olika fält, speciellt med maskininlärning nuförtiden kan du göra deduktiva saker som gör att du kan yta information som du tidigare inte kunde ytan.
Om du försöker skydda, låt oss säga hälsoinformation, då är det en mycket, väldigt drakonisk regel i USA när det gäller hälsoinformation, men du kan faktiskt, med hjälp av olika maskininlärningstekniker, ofta räkna ut vem som är någon medicinsk information faktiskt är det. Jag undrade bara om du har något att säga om det eftersom de alla tycker att det är ett intressant område.
Bert Scalzo: Ja, absolut, och jag använder bara detta som exempel, jag försöker inte säga att en databas är bättre än en annan, men detta är ett mycket bra exempel på vad du just frågade. I Oracle, om jag inte får se en rad med data till exempel, som jag inte får se John Smiths medicinska post. Om jag säger "Välj den posten" i Oracle, kommer jag att blockeras eller jag får se vad jag får se och det kommer att ändras. Och om jag säger: "Välj kontostjärna från tabellen där det är lika med John Smith", får jag noll.
I SQL Server kan den göra redigeringen men den har några hål. Om jag säger "Välj kontostjärna från bordet där det är lika med John Smith", kommer jag faktiskt att få tillbaka en, så jag vet att det finns en John Smith. Det ena är säkrare än det andra. Nu förväntar jag mig att de fixar det, de spelar alltid språnggroda med varandra. Och igen, jag försöker inte skilja mellan databaserna annat än att visa ett exempel på - titta på vad vi pratar om nu, något så enkelt som valt konto måste också klippas av redigeringen, även om tekniskt sett talar, det finns inget som redigeras annat än att det finns raden.
Robin Bloor: Ja visst. Det är typ av intressant. Jag menar, en annan allmän fråga eftersom jag inte har mycket tid handlar egentligen bara om förbättringarna.Jag menar att du har varit i ett där jag vet att du har visat oss exempel på olika testresultat du har kört - tror du att de traditionella databaserna, låt oss kalla dem dominerande databaser, SQL Server och Oracle, gör du tror du att de kommer att ligga före slutförandet? Eller tror du att de faktiskt kommer att bli fångade av en eller annan av olika slags störningar på marknaden som verkligen går för dem? Vad är din åsikt?
Bert Scalzo: Jag har en åsikt och det är - du vet, återigen kommer jag att säga att det är min åsikt - Microsoft till exempel, i post-Ballmer-eran är bara att imponera det levande helvetet ur mig. Jag menar att denna stretchdatabas får SQL Server på Linux, får .NET över på Linux, får PowerShell över på Linux; Jag tror inte att traditionella databasleverantörer kommer att bli kvar. Jag tror att de har beslutat, "Hej, låt de nya killarna, startups definiera något. Låt dem ta reda på vad skärmning är och hur det ska perfekteras, och när de har gjort all forskning och utveckling vet vi exakt vad användare vill ha, nu låt oss lägga till skärning till Oracle. ”Jag tror att de bara blir smarta och att säga, "Hej, att vara andra eller tredje är inte dåligt när du är den dominerande spelaren för då kommer inte människor att migrera bort från dig."
Robin Bloor: Ja, jag menar att det är en strategi som har använts. Jag menar att IBM brukade göra det och hela det - för hela deras produktsortiment och det rankas ganska bra tills någon kommer på något som bara är helt utanför väggen som ingen någonsin har tänkt på, men du kan inte planera mot det ändå.
Frågor från publiken, Eric?
Eric Kavanagh: Ja, men du har tid jag tänker bara för en kanske och jag vet att Bert måste springa. Det var någonting här i - okej, den skärvande arkitekturen på Oracle 12c är som en indikation på - eller vad är det en indikation på enligt din åsikt, vad tror du att händer där?
Bert Scalzo: Oracle absorberar eller / och erbjuder allt som alla andra databasleverantörer är. Till exempel kan jag lägga ostrukturerad data i Oracle. Jag vet inte hur du kan lägga ostrukturerad data och sedan kalla det en relationsdatabas, så det är inte meningsfullt, men du kan. Och nu lägger Oracle till skärning, så Oracle säger: ”Vet du vad? Oavsett vad marknaden vill, kommer vi att erbjuda vårt databaserbjudande eftersom marknaden vill ha vad marknaden vill och vi vill leverera lösningen, vi vill att de ska stanna hos oss. ”
Jag tror att du kommer att se fler artiklar. Jag skulle inte bli förvånad över att se Hadoop-liknande kluster av databasnoder inte i ett Oracle-rack eller ett verkligt applikationskluster, men i grund och botten i mer av en traditionell grupp av Hadoop-typ som gör det skärvande. Och så jag tror att du kommer att kunna distribuera en databas som Oracle som du skulle ha en Hadoop, och den här typen av trender kommer att fortsätta. Dessa stora databasleverantörer, de tjänar miljarder dollar och de vill inte förlora sin marknad, så de är villiga att anpassa sig till något eller adoptera någonting.
Eric Kavanagh: Vet du, det är roligt eftersom jag har följt leverantörerna av öppen källkod en ganska lång tid och har undrat allt detta medan hur stor påverkan det kommer att få på traditionell stängda dörrsteknologi, och en stund kände det säkert som leverantörerna av öppen källkod gjorde allvarliga framsteg, och nu när jag tittar på marknaden ser jag typ av vad du säger, att de stora killarna har gjort sin matematik, har skärpt sina pennor och de räknat ut hur de kan väva mycket av det i deras arkitekturer. Oavsett om det är IBM, eller Oracle eller SAP - Jag var precis på SapphireNow-konferensen förra månaden och Steve Lucas, som är chef för hälften av det företaget, skrytade att SAP nu integrerar i sin HANA-molnplattform, mer open source-komponenter än någon av deras konkurrenter. Om du gör matematiken på det är det ett ganska imponerande uttalande och det säger att de stora killarna inte kommer någonstans snart.
Bert Scalzo: Nej, jag skulle satsa mina pengar på båda. Jag menar att om du tittar var Microsofts aktie nyligen på cirka $ 50 och du vet, för bara några år sedan var det 25 år. Du fördubblar inte ditt aktiekurs på en kort period om du inte gör bra saker och du vet, från att göra allt från Windows 10 som är gratis för det första året till alla andra smarta saker de gör, den här stretchdatabasfunktionen tror jag är bara fenomenal. Jag tror att vad som kommer att hända är att många kommer att hamna i Azure, inte direkt, inte som de sa, "Låt oss migrera min databas till Azure." Det kommer att migrera där borta på magiskt sätt eftersom det kommer att arkiveras där borta med denna nya stretchdatabasfunktion och så kommer antagandet av Azure att bara skyrocket.
Eric Kavanagh: Det är väl en av trenderna på marknaden som även jag kan se, även på din Mac. När du går in på din Mac för att spara några dokument, de nu - och de nyare Mac: erna följer bara genom molnet, eller hur? Jag menar, det finns mycket förnuft i den strategin och jag tittar också på den och går, ”Okej killar, ni försöker locka mig bit för bit in i din molnmiljö, och sedan en dag när jag vill se en film om mitt kreditkort har gått ut, jag kommer att ha problem. ”
Bert Scalzo: Ja, men du gör det vidare.
Eric Kavanagh: Ja. Det är sant.
Bert Scalzo: Du lägger på allt.
Eric Kavanagh: Tja, inte riktigt allt.
Bert Scalzo: Nej jag menar-
Eric Kavanagh: Ja, fortsätt.
Bert Scalzo: Dessa sociala trender når ut till företag. Nu har företag fortfarande en hel del andra saker de måste göra, men de ser dessa trender och de gör samma slags saker. Jag ser varken Oracle eller Microsoft försvinna. I själva verket kommer jag att köpa lager på båda varje gång det är ett dopp.
Eric Kavanagh: Ja verkligen. Tja folkens, gå till idera.com, I-D-E-R-A dot com. Som Bert sa, de har en hel massa gratis saker där uppe och det är en av de nya trenderna på marknaden - ge dig några gratis saker att leka med, få dig ansluten och sedan köp de riktiga sakerna.
Folk, det har varit en annan het teknik. Tack för din tid idag, Bert, naturligtvis, och Robin också. Vi kommer att prata med dig nästa vecka, folkens, massor av saker som händer. Om du har några idéer, känn dig fri till dina verkligen. Vi pratar med dig nästa gång folk, ta hand. Hejdå.