Door Techopedia Staff, 8 juni 2016
Takeaway: gastheer Eric Kavanaugh bespreekt innovaties in databasetechnologie met experts Dez Blanchfield, Robin Bloor en Bert Scalzo.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Dames en heren, het is woensdag om vier oosterse tijd. Ik ben in New Orleans, de zomer komt eraan, dat betekent dat het heet is! Het is tijd voor Hot Technologies, ja inderdaad, ja inderdaad. Mijn naam is Eric Kavanagh, ik zal je gastheer zijn. Ik ga de bal hier terug schoppen voor Hot Technologies. Het onderwerp van vandaag is "Forward Momentum: Moving Relational Beyond Traditional." Mensen, we hebben vandaag drie database-experts aan de telefoon, dus als u vragen heeft, stuur ze de moeilijke, wees niet verlegen. We hebben vandaag een heleboel goede inhoud voor je klaarstaan. Er is echt een plekje in het jouwe, genoeg in mij. Natuurlijk is dit jaar hot. We hebben het allemaal over de nieuwste technologieën in deze show, een samenwerking met onze vrienden van Techopedia. En we gaan vandaag helemaal naar de basis van informatiebeheer, wat natuurlijk de database is. We gaan het hebben over hoe we hier zijn gekomen, wat er vandaag gebeurt en wat er in de toekomst gebeurt. Er gebeuren heel veel interessante dingen.
Uiteraard hebben we een aantal serieuze innovatie in de database-ruimte. Het was een tijdje een beetje stil; als je met een aantal van de analisten in het bedrijf praat, zou ik waarschijnlijk zeggen vanaf het jaar 2005 tot 2009 of '10, het leek er niet op dat er te veel gaande was op het gebied van innovatie. En plotseling brak het uit, zoals een jailbreak of zoiets, en nu gebeuren er allerlei interessante dingen. Veel daarvan komt door de schaal van het web en alle coole webeigenschappen die verschillende interessante dingen doen. Dat is waar het NoSQL-concept vandaan kwam. En dat betekent twee verschillende dingen: het betekent geen SQL, omdat het geen SQL ondersteunt, het betekent ook niet alleen SQL. Er is een term "NewSQL" die sommige mensen hebben gebruikt. Maar het is duidelijk dat SQL's - de Structured Query Language - echt de basis vormen, het is de basis van query's.
En het is interessant dat al deze NoSQL-engines, wat is er gebeurd? Nou, ze kwamen naar buiten, er was veel opwinding over, en dan een paar jaar later, wat begonnen we allemaal te horen? Oh, SQL op Hadoop. Welnu, al deze bedrijven begonnen SQL-interfaces op hun NoSQL-tools te slaan, en iedereen die in de programmeerwereld is, weet dat dit zal leiden tot enkele uitdagingen en enkele moeilijkheden, en enkele gekruiste draden, enzovoort. Dus we gaan vandaag veel van dat soort dingen ontdekken.
Er zijn onze drie presentatoren: we hebben Dez Blanchfield bellen vanuit Sydney, onze eigen Robin Bloor die in Texas is, en Bert Scalzo ook, hij is ook in Texas. Dus we zullen allereerst van Dez Blanchfield horen. Mensen, we zullen tweeten op de hashtag van #HotTech, dus voel je vrij om je opmerkingen te sturen, of je vragen te stellen via de Q&A component van de webcastconsole, of zelfs via het chatvenster. En daarmee, Dez Blanchfield, haal het weg.
Dez Blanchfield: Bedankt, Eric. Hallo iedereen. Dus ik ga proberen om de scène in een gezichtsveld van 30.000 voet te plaatsen, vergelijkbaar met wat er in het afgelopen decennium is gebeurd, en de belangrijke verschuivingen die we hebben gezien - of in ieder geval anderhalf decennium - van de databasebeheersystemen, en enkele van de effecten vanuit commercieel of technisch oogpunt, en enkele van de trends die we de laatste tijd hebben doorgemaakt, en leiden ons naar het gesprek dat we vandaag over het onderwerp hebben.
Mijn omslagfoto hier is een zandduin, en er waait wind kleine kleine stukjes zand van de bovenkant. En als gevolg daarvan, wat er gebeurt is dat zandduin langzaam van de ene ruimte naar de andere loopt. En het is een verbazingwekkend fenomeen, waar deze enorme 40- en 50-voet hoge bergen zand effectief bewegen. En ze bewegen heel langzaam, maar ze bewegen zeker, en terwijl ze bewegen, veranderen ze het landschap. En het is nogal iets om naar te kijken als je wat tijd doorbrengt in een gebied waar zandduinen van nature zijn. Omdat je op een dag uit het raam kunt kijken en je kunt realiseren dat deze enorme berg zand, kleine, kleine korrels in feite helemaal uit zichzelf zijn verplaatst en dat de wind het langzaam van de ene plaats naar de andere verplaatst.
En ik denk dat dat in veel opzichten al geruime tijd de wereld van databasesystemen is. Tot heel, heel recent, die heel kleine verschuiving in de vorm van zandkorrels die een gigantische berg zand in de vorm van een zandduin verplaatsen. Door de jaren heen zijn er kleine verschuivingen in de databaseplatforms gekomen en het was een redelijk stabiele en solide omgeving rond databasesystemen en platforms, door het mainframe van het middensegment. Maar de laatste tijd hebben er een aantal behoorlijk belangrijke dingen plaatsgevonden met onze commerciële behoeften en onze technische stuurprogramma's. Ik ga ons daarmee doornemen.
Ik ben van mening dat het basisconcept van een database, zoals we die al vele, vele jaren kenden, en zoals je misschien al in de pre-show scherts hebt gehoord, onze twee experts die vandaag met mij aan het bellen zijn, een leven lang hebben geleefd deze ruimte en ze hebben volkomen gelijk in het delen van opscheppen dat ze er waren toen het allemaal begon in de vroege jaren '80. Maar we hebben deze enorme verschuiving in het laatste decennium en een beetje gezien, en ik ga ons snel doorlopen voordat ik het overhandig aan Dr. Robin Bloor.
We hebben dit meegemaakt wat ik noem, "grotere, betere, snellere, goedkopere" ervaring. Zoals ik al zei, is de definitie van een database gewijzigd. Het landschap waarin de databaseplatforms de prestaties en de technische en commerciële vereisten moesten aanpakken, is ook veranderd. We hebben deze stijgende vraag naar oplossingen gezien om te gaan met ofwel complexere commerciële, ofwel complexere technische vereisten. En dus is een heel snel overzicht van wat dat eigenlijk betekent, in mijn gedachten, dat we een soort van de jaren 90 zijn en we zagen dat databasetechnologie werd beïnvloed door de introductie van internet, en wat we toen het internet noemden schaal. We hadden het niet alleen over mensen die voor terminals zaten, oorspronkelijk van teletype-terminals met ingebouwde fysieke printers en 132 kolommen tekst die op papier uitkwamen. Dan de vroege groene schermterminals, ponsen met toetsenborden.
Maar weet je, onze wereld bestond uit terminals en seriële kabels of netwerkkabels die lange tijd met computers praatten. Toen kwam het internet, en deze explosieve groei van connectiviteit, dat je niet meer op de computer hoefde te worden aangesloten. Om naar een databasesysteem te gaan, had u alleen een webbrowser nodig. Dus database-technologie moest drastisch veranderen om de schaal van alles aan te pakken, van de basistechnologie voor zoekmachines die werden gebruikt om de wereld te indexeren, en een informatie-index op te slaan, in het voorbeeld van de schaal van de database-indeling. En mensen zoals Google en anderen hebben daarvoor een platform geboden. En alle nieuwe soorten databaseopslag en query's en indexering werden geproduceerd. En toen hadden we muzieksites en filmsites.
En toen in de jaren 2000 zagen we de dot-com boom, en dat veroorzaakte een nog dramatischere explosie in het aantal mensen dat systemen gebruikte die steevast werden aangedreven door een database van een of andere vorm. Deze fase, relationele databases die nog steeds het grootste deel van de belasting aankonden, we hebben ze gewoon op groter tin gezet, en we gingen een beetje naar de zeer, zeer, zeer grote mid-range systemen met Unix-platforms van mensen zoals IBM en Sun enzovoort. . De dot-com-boom heeft de dingen alleen maar groter en sneller gemaakt vanuit het oogpunt van hardware en prestaties, en er waren enkele belangrijke wijzigingen in de database-engines, maar voor het grootste deel was het nog steeds hetzelfde dat we een beetje hadden gezien voor een lange tijd.
En toen kregen we dit tijdperk van web 2.0, zoals we ernaar verwijzen. En dit was een monsterlijke verschuiving, omdat we ineens veel eenvoudiger databaseplatforms nodig hadden en er een schaal moest zijn in een horizontale vorm. En dat was zo'n belangrijke verschuiving in de manier waarop we het idee benaderden van wat een database was. Naar mijn mening zijn we nu nog steeds aan het inhalen. En nu hebben we te maken met dit hele moeras, en ik zeg dat met een positieve draai, geen negatieve connotatie, dit moeras van wat we big data noemen, en een enorme explosie, en ik bedoel explosie. Deze schandalige verschuiving verticaal op de grafiek van het aantal opties dat we hebben als we het hebben over een database en een vorm van relationele query-mogelijkheden.
En interessant genoeg ben ik persoonlijk van mening dat ik denk dat big data echt slechts het topje van de ijsberg is. We hebben de neiging om een beetje enthousiast te worden over wat de impact van big data is en over de soorten keuzes die we nu beschikbaar hebben. We hebben alles van NoSQL-engines, we hebben grafische engines, we hebben al deze verschillende soorten platforms waar we gegevens naartoe kunnen gooien en er dingen mee kunnen doen. Zelfs tot op het punt dat in feite een van de allereerste gesprekken die ik had met Eric Kavanagh, die hier vandaag bij ons is, rond een gesprek ging over iets dat Apache Drill heette, een open-sourceproject waarmee je kunt zoeken gegevens binnen het model verschillende gegevenstypen: alles van onbewerkte CSE-bestanden op een harde schijf tot HDFS-bestandssystemen op petabyte-schaal. En weet je, het stelt je in staat om deze SQL-stijl vragen van gestructureerde en ongestructureerde gegevens van allerlei spannende planten te doen.
We staan op het punt om "slim bouwen" een ding te worden, en we willen graag denken dat we slimme gebouwen hebben voor beveiliging en warmtebeheer, maar ik heb het over slimme gebouwen die veel meer weten over wie je bent en waar je bent als je binnenkomt en allerlei leuke dingen doet op dat niveau, tot slimme steden - hele ecosystemen op stadsniveau - die weten hoe ze dingen intelligent moeten doen. En verder hebben we iets ongelooflijks waarvan ik denk dat niemand in de wereld het volledig begrijpt, en dat is de vorm van het internet der dingen. Het afgelopen decennium zijn er al die verschillende veranderingen geweest en een beetje, misschien twee decennia ruwweg, als we het afronden, hebben dat naar mijn mening een beetje invloed gehad op de wereld van wat we databases beschouwen.
Er zijn een aantal belangrijke dingen geweest die dit zelfs mogelijk hebben gemaakt. De kosten van harde schijven zijn dramatisch gedaald, en in veel opzichten is het hierdoor mogelijk geworden om een aantal van de referentiearchitecturen, zoals het Hadoop-model, aan te sturen, in die zin dat we veel gegevens verzamelen en verspreiden op veel harde schijven, en doe er slimme dingen mee. En in feite, wat mijns inziens sharding werd van de relationele database of het traditionele DB-eenheidsmodel. En RAM werd heel, heel goedkoop, en dat gaf ons een hele nieuwe mogelijkheid om te spelen met verschillende referentie-architecturen zoals in het geheugen, en om dingen te doen zoals het partitioneren van zeer, zeer grote hoeveelheden gegevens.
En dus gaf dit ons dit kleine plaatje waar we nu naar kijken, wat een diagram is dat de soorten platforms toont die beschikbaar zijn als je je in het big data-landschap bevindt. En het is heel, heel moeilijk om te lezen, en de reden daarvoor is dat er gewoon teveel informatie over is. Er zijn zoveel mogelijkheden voor het maken, modelleren en fabriceren van manieren om gegevens in databasesystemen van welke vorm dan ook te plaatsen en ernaar te zoeken en de traditionele read-writes uit te voeren. En ze zijn niet allemaal compliant, in feite voldoen slechts weinigen aan een standaard stijlstandaard, maar ze beschouwen zichzelf nog steeds als een database. En ik ga je in een seconde een paar schermen laten zien om je wat context te geven over wat ik bedoel met de verschuiving van de jaren 90 en de internetschaal naar web 2.0, en dan de hele groei door big data. Als we denken dat deze landschapsgrafiek met big data-technologie spannend is omdat er veel opties op staan, laten we eens kijken naar een belangrijke verticale.
Laten we eens kijken naar marketingtechnologie. Hier zijn de opties voor databasebeheersystemen of gegevensbeheer binnen alleen de mar-tech-ruimte, dus technologie gerelateerd aan marketing. Nu was dit in 2011, dus een paar jaar geleden; vijf jaar geleden zag het landschap er zo uit. Als ik even één dia even terugga, is dit hoe het gegevenslandschap van vandaag eruitziet in de verschillende merken en aanbiedingen die we hebben in databasetechnologieën. Dit is hoe een verticaal eruit zag vijf jaar geleden, alleen in marketingtechnologie.
Als ik nu naar de weergave van vandaag ga, is dit hoe het eruit ziet en het is volledig ondoordringbaar. Het is gewoon deze muur van merken en opties, en het is duizenden en duizenden combinaties van software die zichzelf in de database-klasse beschouwt, die het gegevens in verschillende vormen kan vastleggen, creëren of opslaan en ophalen. En ik denk dat we nu een zeer, zeer interessante en moedige tijd ingaan, waar je ooit de grote merken kon kennen, je de vijf of zes verschillende platforms van Oracle en Informix, DB2 enzovoort kon kennen, en bijna een expert over alle merken die zo'n 20 jaar geleden beschikbaar waren. Tien jaar geleden werd het een beetje gemakkelijker omdat sommige van de merken vielen, en niet alle merken de schaal van de dot-com boom konden verwerken, en sommige bedrijven gingen gewoon failliet.
Tegenwoordig is het absoluut onmogelijk om een expert te zijn in alle bestaande databasetechnologie, of het nu gaat om relationele databases of standaard databasebeheerplatforms die we de afgelopen decennia hebben leren kennen. Of waarschijnlijk het geval, de modernere motoren zoals Neo4j en dergelijke. En dus denk ik dat we een heel dappere wereld betreden waar veel opties beschikbaar zijn, en we hebben platforms op schaal op horizontale basis, hetzij in het geheugen of nu op schijf. Maar ik denk dat het een uitdagende tijd is voor technologie- en zakelijke besluitvormers, omdat ze een aantal zeer grote beslissingen moeten nemen over technologiestacks, die in sommige gevallen slechts in wezen maanden bestaan. Achttien maanden oud is nu geen eng getal voor enkele van de meer opwindende en nieuwe open-source databaseplatforms. En ze beginnen platforms samen te voegen en worden nog nieuwer en spannender.
Ik denk dat we vandaag een geweldig gesprek gaan voeren over hoe dit alles de traditionele databaseplatforms heeft beïnvloed en hoe ze daarop reageren, en de soorten technologieën die daar naartoe worden gegooid. En met dat in gedachten, ga ik nu over aan Dr. Robin Bloor, en krijg zijn inzichten. Robin, aan jou.
Robin Bloor: Oké, bedankt daarvoor. Ja, dit is een veel te groot onderwerp. Ik bedoel, als je gewoon een strookje nam van een van de illustraties die Dez je net liet zien, zou je een lang gesprek kunnen voeren over zowat een van de strookjes. Maar weet je, je kunt naar een database gaan - ik kijk al sinds de jaren 80 naar databases, ik weet het niet, en je kunt op verschillende manieren naar de database kijken. En een van de dingen die ik dacht dat ik zou doen, gewoon vandaag in het gesprek gooien, was om te praten over de reden waarom verstorende dingen zijn gebeurd op het niveau van hardware. En je moet in gedachten houden dat er op het niveau van software ook ontzettend veel verstorende dingen zijn gebeurd, dus dit is niet het volledige beeld, het is gewoon een hardware-kwestie.
Ik ging ook niet zo lang praten, ik wilde je alleen het hardware-beeld geven. Een database was het ophalen van gegevens over CPU, geheugen en schijf, en dat verandert enorm. En de reden dat ik dat zeg, was dat ik de database heb leren begrijpen vanuit het perspectief van wat je daadwerkelijk deed. Weet je, er is een verschil in latentie tussen gegevens die feitelijk op de CPU staan, en gegevens die uit het geheugen in de CPU worden getrokken en gegevens die van schijf in het geheugen en via de CPU worden getrokken. En de oude database-architecturen probeerden dat gewoon in evenwicht te brengen. Weet je, ze zeiden alleen maar: "Wel, dit gaat erg langzaam, we zullen de gegevens op de schijf opslaan zodat ze in het geheugen zijn. We zullen proberen dat op een echt nauwkeurige manier te doen, zodat een echt groot deel van de gegevens waar we om vragen al in het geheugen is. En we zullen de gegevens zo snel mogelijk naar de CPU marcheren. ”
En databases werden vroeger geschreven, machines zijn geschreven voor kleine clusters. En nu, voor de onwetende van het parallellisme. Omdat als je prestaties uit een cluster wilt halen, je verschillende dingen parallel moet doen. Parallellisme is een onderdeel van het spel, niets zoals het nu is. Ik zal gewoon een beetje doorlopen wat er is gebeurd.
Allereerst schijf. Nou schijf is echt voorbij. Het is zo ongeveer voorbij met betrekking tot databases. Ik denk dat er een aantal contexten zijn voor het archiveren van gegevens, en zelfs zeer grote gegevensmeren die op Hadoop draaien, de slechtste draaiende schijf is tegenwoordig waarschijnlijk levensvatbaar. Het probleem met de draaiende schijf was echt dat de leessnelheden niet bijzonder veel verbeterden. En toen CPU de wet-snelheden van Moore omhoog ging, soort orde van grootte, sneller om de zes jaar. En het geheugen volgde een beetje in zijn kielzog, toen hielden die twee redelijk gelijke tred met elkaar, het was niet helemaal soepel, maar dat deden ze.
Maar het willekeurig lezen op een schijf waar het hoofd rond de schijf vliegt, ik bedoel, afgezien van iets anders, is het een fysieke beweging. En als u willekeurig leest van een schijf, is het ongelooflijk langzaam in vergelijking met lezen uit het geheugen, het is 100.000 keer langzamer. En vrij recent hebben de meeste database-architecturen waar ik diepgaand naar heb gekeken eigenlijk alleen serieel gelezen van schijven. Je wilt echt, op de een of andere manier, zoveel mogelijk van de schijf cachen en het van dat trage apparaat halen en op een snel apparaat plaatsen. En er zijn veel slimme dingen die je daarmee kunt doen, maar het is een beetje voorbij.
En solid-state disks, of flash drives, is echt wat ze zijn, ze vervangen de spinning disk heel snel. En dat verandert weer helemaal, want de manier waarop gegevens op een schijf worden georganiseerd, is dat ze zijn georganiseerd volgens de manier waarop de schijf werkt. Het gaat eigenlijk over een kop die over een draaiend oppervlak beweegt, eigenlijk over meerdere koppen die over meerdere draaiende oppervlakken bewegen en de gegevens oppikken terwijl ze gaan. Een solid-state drive is slechts een blok dingen die je kunt lezen. Ik bedoel, het eerste is dat alle traditionele databases zijn ontworpen voor het draaien van de schijf, en ze worden nu opnieuw ontworpen voor SSD. Nieuwe databases kunnen waarschijnlijk - iedereen die nu een nieuwe database schrijft, kan de draaiende schijf waarschijnlijk negeren, er helemaal niet aan denken. Maar Samsung, de belangrijkste fabrikant van SSD's, vertelt ons dat SSD's zich in de wetcurve van de Moore bevinden.
Ze waren, denk ik, al ongeveer drie of vier keer sneller dan de draaiende schijf, maar ze worden nu in principe elke 18 maanden veel sneller. Dubbele snelheid, en 10 keer in snelheid tot ongeveer zes jaar. Als dat het juist was, is dat het niet, zoals ik u zo meteen zal vertellen. De draaiende schijf wordt natuurlijk een archiveringsmedium.
Over geheugen. Eerste dingen eerst, RAM. De CPU-verhouding tussen RAM per CPU neemt alleen maar toe. En dat levert natuurlijk in zekere zin veel meer snelheid op, omdat de hectares geheugen die je nu kunt hebben veel meer kunnen opslaan. Wat dit eigenlijk doet, is dat het de druk op MLTP-type applicaties of random read-applicaties vermindert, omdat het gemakkelijker is om die te bedienen, omdat je nu veel geheugen hebt en op die manier kun je alles opslaan dat wordt waarschijnlijk in het geheugen gelezen. Maar je ondervindt problemen met een grotere datahoop, dus big data is eigenlijk niet zo eenvoudig, echt.
En dan hebben we Intel met 3D Xpoint en IBM met wat ze PCM noemen, wat faseveranderingsgeheugen is, dat iets levert waarvan ze denken dat het goed is - nou ja, het is minstens 10 keer sneller dan de huidige SSD's, en ze denken dat het heel dicht bij dezelfde snelheid als RAM. En natuurlijk is het goedkoper. Dus eerder had je deze database-structuur van CPU, geheugen en schijf, en nu gaan we naar een structuur met vier lagen. Het heeft CPU, geheugen of RAM, en dan dit soort sneller dan SSD-geheugen, dat eigenlijk niet-vluchtig is, en dan SSD. En deze nieuwe technologieën zijn niet-vluchtig.
En er is HP's memristor, die nog niet bekend is, omdat het ongeveer zeven jaar geleden werd aangekondigd, maar het is nog niet verschenen. Maar de geruchten die ik hoor, zijn dat HP het spel ook een beetje zal veranderen met een memristor, dus je hebt gewoon een nieuwe geheugensituatie. Dit is niet alsof we snellere dingen hebben, dit is alsof we een hele nieuwe laag hebben. En dan hebben we het feit dat SSD-toegang u parallel kunt lezen. Je kunt de draaiende schijf niet parallel lezen, behalve door veel verschillende draaiende schijven te hebben. Maar een blok SSD kun je eigenlijk parallel lezen. En omdat je dat parallel kunt lezen, gaat het veel sneller dan zijn eenvoudige leessnelheden, als je eigenlijk meerdere processen instelt over de verschillende processen op een enkele CPU, en het gewoon hebt met de SSD.
Naar schatting kun je daarmee bijna RAM-snelheden halen. En het enige dat dit zegt, is dat de toekomst van geheugenarchitectuur onduidelijk is. Ik bedoel, de realiteit is dat de verschillende dominante leveranciers, wie ze ook blijken te zijn, waarschijnlijk de richting van de hardware zullen bepalen. Maar niemand weet waar het op dit moment naartoe gaat. Ik heb gesproken met enkele database-ingenieurs die zeggen: "Ik ben niet bang voor wat er gebeurt", maar ze weten niet hoe ze dit vanaf het begin kunnen optimaliseren. En dat deed je altijd al, dus dat is interessant.
En dan is er de CPU. Nou, multicore CPU's waren niet alleen multicore CPU's. We hebben ook aanzienlijke volumes L1-, L2- en L3-cache, met name L3, wat tot tientallen megabytes kan. Je kunt er veel plaatsen, weet je. En daarom kunt u de chip eigenlijk als cachemedium gebruiken. Dus dat veranderde het spel. En zeker, vectorverwerking en datacompressie, een aantal leveranciers hebben dat echt gedaan, die dingen naar de CPU gesleept om het allemaal een stuk sneller naar de CPU te laten gaan. Dan merk je dat CPU's met GPU's echt goed zijn in het versnellen van analyses. En ze zijn echt heel goed in bepaalde soorten vragen, het hangt er maar vanaf wat uw vraag is.
Je kunt boards maken met CPU's en GPU's aan, of zoals AMD nu doet, produceer je iets dat een APU wordt genoemd, wat een soort huwelijk is tussen een CPU en een GPU; het heeft beide soorten mogelijkheden. Dus dat is een ander soort processor. En dan de recente aankondiging van Intel dat ze een FPGA op de chip zouden plaatsen, dat deed mijn hoofd erin. Ik dacht: "Hoe gaat het in vredesnaam gebeuren?" Want als je de mogelijkheid van CPU, GPU, en je hebt de mogelijkheid van CPU, FPGA - en trouwens, als je echt wilt, kun je op hetzelfde bord een CPU en een GPU en een FPGA plaatsen. Ik heb geen idee hoe je zoiets eigenlijk zou doen, maar ik ken wel bedrijven die dit soort dingen doen, en ze krijgen heel, heel snelle antwoorden op vragen. Dit is niet iets dat zal worden genegeerd, dit is iets dat zal worden gebruikt door de gevestigde leveranciers en misschien door nieuwe leveranciers die eraan komen. DBMS's waren altijd evenwijdig, maar nu zijn de parallelle mogelijkheden zojuist geëxplodeerd, omdat je hiermee op verschillende manieren parallel kunt lopen met dat, met dat, met dat.
Eindelijk opschalen of opschalen? Opschalen is echt de beste oplossing, maar in de eerste plaats. U krijgt veel betere knooppuntprestaties als u de prestaties van de CPU en het geheugen op de schijf op één knooppunt absoluut kunt optimaliseren. En u zult minder knooppunten gebruiken, dus het wordt goedkoper, toch? En het zal gemakkelijker te beheren zijn. Helaas is het een hardware-afhankelijk ontwerp en naarmate de hardware verandert, wordt het steeds minder mogelijk om dat te doen, tenzij je technici zo snel kunnen draaien als de hardware verandert. En u krijgt wel problemen met de werkdruk, want wanneer u opschaalt, maakt u verschillende veronderstellingen over wat de werkdruk gaat doen.
Als je opschaalt, dat wil zeggen, als je architectuur de nadruk legt op schalen voordat opschalen - eigenlijk moet je ze allebei doen, het is gewoon dat je er één benadrukt. Dan krijgt u betere netwerkprestaties, omdat de architectuur het aankan. In hardware-termen zal het duurder zijn omdat er meer knooppunten zullen zijn, maar er zullen minder problemen met de werklast zijn en er zal een flexibeler ontwerp zijn.
En ik dacht dat ik dat gewoon in zou gooien, want als je echt denkt aan alle hardwareveranderingen waar ik net met mijn vinger op wees, en toen dacht je, hoe ga je opschalen en opschalen over dat soort dingen? Dan realiseert u zich dat database-ingenieurs, naar mijn mening tenminste, goed onderbetaald zijn. Dus als u alleen de hardwarelaag overweegt, zijn de database-uitdagingen duidelijk. Nu geef ik dit door aan Bert, die ons allemaal opgeleid zal laten voelen.
Eric Kavanagh: Dat is alles! Bert?
Bert Scalzo: Heel erg bedankt. Laat me gewoon meteen deze dia's ingaan. Ik heb veel dia's om door te nemen, dus op een flink aantal daarvan kan ik vrij snel gaan. We gaan het hebben over dit "Forward Momentum: Relational Beyond Traditional Traditional". Het is niet meer de database van je vader. De dingen zijn veranderd, en zoals een eerdere spreker zei, de afgelopen zes tot zeven jaar is het landschap radicaal veranderd.
Zelf doe ik al sinds het midden van de jaren '80 databases. Ik heb boeken geschreven over Oracle, SQL Server, benchmarking en heel wat andere dingen. “De wereld verandert heel snel. Groot zal niet meer klein kloppen. Het zal de snelle zijn die de langzame verslaat. "Ik voegde de" aan te passen. "Dat was van Rupert Murdoch. Ik geloof echt dat dit waar zal zijn. Je zult niet in staat zijn om database-dingen te doen zoals je 10, 15, 20 jaar geleden deed. Je zult het moeten doen zoals het bedrijf het nu wil.
Ik ga proberen een beetje generiek te blijven in wat ik presenteer, maar de meeste functies waar ik het over heb, vind je in Oracle, je vindt in SQL Server, MySQL, MariaDB en enkele andere grote spelers. De relationele database revolutie, ik ben het een beetje opnieuw eens met de eerdere sprekers. Als je rond 2010 goed kijkt, zijn we van de rode raceauto naar de gele raceauto gegaan. Er was een belangrijke verandering en in 2020 geloof ik dat je nog een radicale verandering zult zien. We zitten in een heel interessante tijd.
Nu is deze dia de sleutel, daarom heb ik daar een sleutel neergezet. Er is al deze verandering gaande, en aan de linkerkant heb ik technologie, en aan de rechterkant heb ik zaken. En de vraag is, welke veroorzaakt welke en welke ondersteunt welke? We hebben al deze hardwarewijzigingen: schijven die naar beneden gaan, schijfgrootte omhoog, nieuwe typen schijven, dus dat werd gedekt door de eerdere luidsprekers. De prijs van geheugenverlies, al deze nieuwere versies van databases. Maar aan de rechterkant hebben we gegevensbescherming en compliance, datawarehousing, business intelligence, analyse, verplichte gegevensbewaring. Beide kanten van de vergelijking rijden, en beide kanten van de vergelijking gaan gebruik maken van al deze nieuwe functies.
Allereerst hebben we onze typische SAS-draaiende schijf, ze zijn nu tot 10 terabytes. Als je nog niet hebt gezien, Western Digital, heeft HGST wat ze hun heliumdrive noemen, die nu tot ongeveer 10 terabytes gaat. De kosten van de draaiende schijf worden behoorlijk laag. Zoals eerder vermeld, kunt u solid-state schijven tot ongeveer twee terabytes krijgen, maar Samsung heeft binnenkort een eenheid van 20 terabyte. De kosten worden redelijk. Een ding dat ik over de anderen ga vertellen, is het concept van flash-schijven. PCIe, dat is PCI Express, versus NVMe, je hebt misschien wel gehoord van dit niet-vluchtige geheugenexpress. In principe wordt NVMe een vervanging voor SAS en SATA, en het is echt meer een communicatieprotocol dan iets anders. Maar die schijven zijn nu ongeveer drie terabytes.
Je hebt misschien ook gezien dat sommige SAS-schijven nu worden geleverd met U.2-connectoren, wat een soort andere connector is dan een SAS of SATA, die NVMe ondersteunt met een standaardschijf - de schijf moet deze natuurlijk ook ondersteunen. En dan SATA met M.2-connectoren, en die beginnen NVMe te krijgen. In feite zijn er nu notebookverkopers die notebooks verkopen met een NVMe-flashdisk en die dingen zullen schreeuwen in vergelijking met de technologie die u eerder hebt gebruikt.
Veel mensen weten niet wat al die verschillende flitsen zijn. Als je in de rechteronderhoek kijkt, is dat een voorbeeld van een M.2. Je zou kunnen zeggen: "Nou, het lijkt veel op de mSATA-schijf links ervan." Maar zoals je kunt zien, heeft het twee gaten in de pinnen in tegenstelling tot een, en het is een beetje groter. En de M.2 kan ook in drie verschillende maten worden geleverd.
En dan de PCI Express-flitser en de NVMe-flitser. Nu is de NVMe-flash ook PCI Express, maar de PCI Express is meestal nog steeds een SAS- of SATA-type controlleralgoritme dat is geschreven voor de draaiende schijf, en NVMe zijn de algoritmen of technieken die specifiek voor flash zijn geschreven. En nogmaals, je gaat deze allemaal zien.
NVMe biedt nogal wat dingen. Ik denk dat de twee grootste verbeteringen in de rechterbovenhoek de latentie met maar liefst 70 procent verminderen. Ik heb zelfs nog hoger gezien dan dat. Als u in de rechteronderhoek kijkt, wanneer uw besturingssysteem spreekt met de NVMe-schijf, gaat het bovendien veel minder softwareniveaus door. Kortom, u gaat door het NVMe-stuurprogramma dat nu is opgenomen in het besturingssysteem en het spreekt rechtstreeks naar de media. Er zijn veel redenen waarom deze technologie de database-wereld ingrijpend zal veranderen.
En vaak zullen mensen zeggen: "Wel, hoe snel is NVMe?" Weet je, de goede oude tijd, in 2004 en eerder, werden we enthousiast als we Ultra-320 SCSI hadden, 300 megabytes per seconde. De snelheden van vandaag, velen van jullie zijn waarschijnlijk op glasvezel of InfiniBand, en dat soort toppen. NVMe daar rechts begint bij het einde van de huidige technologieën. Wat ik bedoel is, PCI Express 3.0 met een acht-baans link begint bij bijna 8000, en het zal stijgen naarmate we nieuwere versies van PCI Express krijgen, versie vier enzovoort. NVMe kan nergens heen, behalve naar boven.
Wat veranderen er nu in de database? Nu in de rechterbovenhoek van mijn dia's, zet ik de zakelijke redenen waarvan ik denk dat de technologie opdook. In dit geval beginnen de databases compressie te bieden vanwege gegevensopslag en vanwege wettelijke redenen voor verplichte gegevensbewaring. Nu bieden sommige databases compressie als een add-on, sommige bieden het als ingebouwd in de standaard, laten we zeggen enterprise-editie van hun database, en toch kunnen sommige databases, zoals in Oracle, zelfs een nog betere compressieversie hebben die in, zeg, hun Exadata-platform, dus ze hebben eigenlijk hardware gebouwd die een zeer gespecialiseerde compressie kan ondersteunen en die in Exadata, bijvoorbeeld, krijgt een 40x compressiesnelheid, en dus is het heel belangrijk. En ik denk dat het de verplichte bewaring van gegevens is, mensen willen gewoon langer gegevens. De bedrijven hebben voor analyse en BI de gegevens van de laatste 5, 10, 15 jaar nodig.
Nu was een andere functie die rond die periode 2008, 2009 begon te verschijnen, aan het partitioneren. Nogmaals, u vindt dit in databases zoals Oracle, SQL Server, en in beide moet u ervoor betalen. In Oracle moet u de partitie-optie kopen en in SQL Server moet u in de datacenterversie zijn. Het is je traditionele verdeel-en-heers techniek en wat je doet is dat je het concept van een logische grote tafel bovenaan hebt en wanneer het op schijf wordt gezet, wordt het eigenlijk opgesplitst in emmers. En u kunt zien dat die emmers zijn georganiseerd volgens enkele criteria voor het scheiden, waarnaar gewoonlijk wordt verwezen of uw partitiefunctie wordt genoemd, en dan kunt u ook in sommige databaseplatforms sub-partities maken en u kunt zelfs nog verder gaan.
Nogmaals, ik denk dat zowel datawarehousing als de verplichte bewaring van gegevens dit hebben gepusht, en in sommige van deze databases kun je tot 64.000 partities hebben, en ik geloof op sommige andere databases zelfs tot 64.000 subpartities. Hiermee kunt u uw gegevens opdelen in beheersbare stukken. U zult ook de indexen verdelen; het is een optie, dat hoeft niet, maar u kunt uw indexen ook partitioneren. Een van de redenen om dit te doen, kan zijn dat u een gegevensvenster hebt. U wilt de waarde van 10 jaar bewaren, maar om de indexen te laten vallen om de batch-lading van vanavond uit te voeren, wilt u de indexen niet op elke rij laten vallen, alleen op de rijen in de huidige bucket. Partitioneren is eigenlijk een zeer goed administratief hulpmiddel, hoewel de meeste mensen denken dat het grote voordeel ervan is om partitie-eliminatie in uw plannen te voorkomen en daarom uw vragen te versnellen. Dat is echt een soort kers op de taart.
Nu heb je waarschijnlijk gehoord over scherfschudden en denk je waarschijnlijk: "Wel, waarom heb je deze dia hier geplaatst?" Dit is een van die NoSQL - dit is een van die Hadoop-achtige omgevingen. Oracle 12c heeft er twee uitgebracht, die nog geen G8 is, maar die wel wordt getoond of bekeken, heeft eigenlijk scherven. Je hebt een traditioneel databasesysteem zoals Oracle en je zult kunnen scherpen zoals je in het Hadoop-model doet, en dus zul je een andere verdeel-en-heers-techniek hebben die je gaat splitsen tabel rijgewijs in groepen per knooppunt en dit zal zijn - net zoals wat u ziet in sommige van uw NoSQL-databases. En eigenlijk MySQL, je kunt dit eigenlijk vrijwel bereiken met een van hun clusteringstechnieken, maar het komt in een traditionele database en ik denk dat Microsoft niet achter wil blijven. Deze twee spelen de hele tijd sprongkikker met elkaar, dus ik zou sharding verwachten in misschien de volgende versie van SQL Server.
Data lifecycle management, opnieuw verplicht bewaren van gegevens, maar ook voor business intelligence en analyse. Dit is echt een verdeel-en-heers techniek, en meestal doen DBA's dit handmatig, en dat is: “Ik ga de gegevens van dit jaar bewaren op snelle schijven, de gegevens van vorig jaar op iets langzamere schijven, misschien ga ik om de laatste twee jaar daarvoor op nog langzamere schijven te houden, en dan heb ik een archiveringsmethode. ”Het wordt meestal niet meer opgenomen, het is meestal - je hebt een soort netwerk-aangesloten opslag of een apparaat met veel van opslag en is, weet u, kosteneffectief, maar het draait nog steeds schijf.
En dus kunt u nu - zowel op Oracle als op SQL Server - een optie kopen waarbij u de regels definieert en dit gebeurt gewoon automatisch op de achtergrond. U hoeft geen scripts meer te schrijven, u hoeft niets te doen. En als je SQL Server 2016 hebt gezien, dat net op 1 juni uitkwam, is er een nieuwe functie genaamd "Stretch Databases" die je in principe toestaat - in de rechteronderhoek daar - kun je vanuit meerdere lagen rechtstreeks naar de cloud gaan en nogmaals, dit is een functie die in de database is ingebouwd, je zegt gewoon iets als: "Als de gegevens meer dan 365 dagen oud zijn, verplaats deze dan naar de cloud en, weet je, doe het automatisch voor mij."
Dit wordt echt een coole functie, ik denk zelfs dat dit misschien is wat we in de toekomst gaan zien, namelijk dat je hybride databases hebt waar je wat lokale en sommige in de cloud. Voordien dachten mensen: "Oh, ik ga het op locatie doen of ik ga het doen in de cloud." Nu zien we het huwelijk van de twee technologieën op deze hybride manier. Ik denk dat dit behoorlijk groot zal zijn en Microsoft is er eerst gekomen.
Redactie, dit komt door gegevensbescherming en compliance. Nu, in de goede oude tijd, zouden we misschien gezegd hebben: “Hé, applicatieontwikkelaar, als je dit in het rapport weergeeft, als je dit op het scherm weergeeft, zijn hier enkele dingen die je moet controleren en alsjeblieft, je weet wel, toon alleen de gegevens ze worden verondersteld om de gegevens te zien of te maskeren of te redigeren die ze niet zouden moeten zien. ”Wel, zoals gebruikelijk, wanneer je het naar de toepassing pusht, gebeurt het niet op één plaats, dus het wordt anders gedaan of het doet het niet wordt op sommige plaatsen niet gedaan. En nu hebt u deze mogelijkheid in uw databasesystemen.
Nu in SQL Server 2016 is deze functie ingebouwd, dus het is nog geen optionele kostenpost voor de toevoeging van het datacenter, geloof ik; en in Oracle 12 moet u hun add-on voor levenscyclusbeheer kopen, maar dit is iets nieuws en opnieuw wordt het door het bedrijf aangestuurd. En vooral omdat je nu zoveel gegevens bewaart en je de datamining doet, dus de BI en de analyse, moet je weten wie toegang heeft tot welke gegevens en ervoor zorgen dat ze alleen mogen zien wat ze mogen zien.
Kijk ook hier eens naar, gegevensbescherming en compliance. U zult merken dat veel van de databasesystemen nu compressie bouwen, of het spijt me, codering rechtstreeks in de database en wat belangrijk is aan deze codering, als u naar de pijl-omlaag en de pijl-omhoog op het diagram kijkt, schrijft het naar schijf versleuteld en dan leest het terug in het geheugen en decodeert het. Dat is eigenlijk één model, er is een ander model dat, weet je, het eigenlijk alleen doet als het die gegevens via het netwerk communiceert naar de daadwerkelijke clienttoepassing.
In dat geval zou het zelfs nog steeds op de databaseserver in het geheugen kunnen worden gecodeerd en alleen gedecodeerd wanneer het naar de clienttoepassing wordt verzonden. Er zijn hier twee verschillende modellen en u vindt deze in de databases, en in feite was MariaDB in hun versie 10.X een van de databases die zojuist werd toegevoegd; Ik geloof dat ze nu op 10.1 of 10.2 zijn. En ik heb eigenlijk wat benchmarking gedaan op deze codering, en om deze codering te krijgen, ondervond ik slechts een afname van ongeveer 8 procent in de doorvoer of snelheid. In een benchmarking-test heeft de codering niet zoveel veroorzaakt en daarom is het een zeer handige functie.
Nu hebben we eerder gezegd over flash-geheugen en SSD's en dat soort dingen. Een van de functies in Oracle en SQL Server die veel mensen zich niet realiseren, is dat u een flash of SSD op uw databaseserver kunt gebruiken en tegen de database kunt zeggen: 'Gebruik dit alsof het geheugen is. Behandel het RAM als preferentieel, maar doe alsof dit langzaam geheugen is en gebruik dat als een uitgebreide cache. ”Nu in SQL Server 2014 kwam dit uit en werd het" Buffer Pool Extension "genoemd, het is gratis. In Oracle kwam het uit in 11g R2 en heette het "Database Flash Cache" en het was daar ook gratis.
Mijn advies is echter om deze functie zorgvuldig te testen. Elke keer dat u de cache groter maakt wanneer u opzoekt, duurt het langer. Als u een flash-kaart van drie terabyte plaatst en tegen de database zegt: "Voeg dat toe aan uw geheugen", merkt u misschien dat iets vertraagd is vanwege de tijd om in te kijken en te zien of het in flash is, is het vies of schoon? Er is een punt van afnemende terugkeer. Mijn advies is om dit opnieuw te testen, kijk wat voor jou werkt, maar nogmaals, het zit in je database en in het geval van Oracle, zowel in SQL Server als Oracle, is het er al een paar jaar.
En dan brengt dat ons naar de opa die de in-memory databases was en dat komt omdat de database prijzen zijn gedaald. De andere reden dat u waarschijnlijk zou denken dat dit is gebeurd, is dat veel van de analyses vereisen dat de gegevens zeer snel toegankelijk moeten zijn en dus in het geheugen moeten zijn. Houd er rekening mee dat de algoritmen die de databases gebruiken om toegang te krijgen tot deze gegevens, om ze te comprimeren, om ze te coderen, om ze op te slaan, u weet dat in sommige gevallen sommige databases in een rij in het geheugen kunnen worden opgeslagen.
In sommige gevallen kunnen sommige databases dit opdelen in een kolomgeoriënteerd en de reden dat ze dat doen is dat ze een veel hoger compressieniveau krijgen, ergens rond de 11 tot 12X door het in kolomvolgorde versus rijvolgorde op te slaan. Dit verscheen voor het eerst in SQL Server 2014, het heette "Hekaton". Het is radicaal toegenomen in SQL Server 2016, ze zullen het zien waarnaar wordt verwezen door enkele verschillende namen en het kwam uit in Oracle 12c; Ik zeg hier de tweede release, niet R2. Er waren twee verschillende releases van Oracle 12c, de 12.1.0.1 en de 12.1.0.2. Het is de tweede release van de R1-versie van de database.
En de manier waarop u het definieert, het object in het geheugen is vergelijkbaar in beide databases. Hier zie je in de rechterbovenhoek, ik ben een SQL Server aan het maken en je ziet dat zegt dat geheugen is geoptimaliseerd en dat duurzaamheid alleen een schema is. Ik ga niet over al deze syntaxisbetekenissen, en in Oracle is het zelfs nog eenvoudiger, je verandert gewoon een tabel en zegt in het geheugen of niet en je kunt dat veranderen. Ik kan zeggen dat het vandaag in het geheugen is en morgen niet en dus is het erg flexibel.
Ik heb wat tests gedaan op Oracle met geheugentabellen, ik had enkele tests die bijna 40 minuten duurden, daar op de bovenste rij. Wat belangrijk is, was dat tegen de tijd dat ik de onderste twee rijen bereikte, ik de looptijd had verhoogd of verkort, zou ik moeten zeggen, ongeveer vijf minuten, en toen ik naar de compressiefactor keek, waren de gegevens in het geheugen eigenlijk 3, 6 tot 4, 6 keer kleiner. Dat is belangrijk omdat ik in dit geval het kolomgeoriënteerde formaat en de compressie gebruikte. En raad eens? Ik paste eigenlijk bijna vier tot vijf keer zoveel gegevens in mijn geheugen aan. Ik kreeg niet alleen het voordeel van in-memory, het voordeel van kolomgericht, maar ook het voordeel van veel meer gegevens - tot vijf keer zoveel gegevens in de geheugencache, dus dit is een behoorlijk krachtige techniek. Nogmaals Oracle en SQL Server, je wilt hiernaar kijken, het zijn echt coole functies. En daarmee denk ik dat ik het open zal stellen voor vragen.
Eric Kavanagh: Nou Bert, allereerst ben je heel onbaatzuchtig geweest in al deze geweldige opleiding. Kun je even praten over wat jullie doen? Omdat je een aantal activerende technologie hebt die kan vergemakkelijken waar je het over hebt gehad. Praat gewoon even over wat jullie doen en laten we Dez en Robin hier in de vergelijking opnemen.
Bert Scalzo: Ja, ik werk voor een bedrijf dat IDERA heet. We zijn in Texas, we hebben ons hoofdkantoor in Houston, en ik zit nu eigenlijk in Austin, maar ik ben gevestigd in Dallas. We maken databasehulpmiddelen en we maken databasehulpmiddelen om u te helpen problemen op te lossen. Dat probleem kan zoiets eenvoudigs zijn als productiviteit. In dat geval hebben we een tool genaamd DBArtisan waarmee u uw databasebeheertaken kunt uitvoeren en het is één tool waarmee u 12 verschillende databaseplatforms kunt beheren. Ik kan SQL Server beheren, ik kan Oracle beheren, ik kan MySQL, DB2, Postgres beheren en ik gebruik één tool, één uitvoerbaar, één GUI-ontwerp en één consistente set workflows. We maken ook tools om compliance te doen, we hebben een tool genaamd SQL Compliance Manager om u te helpen aan uw compliance-behoeften te voldoen. Een andere tool genaamd SQL Security, dus we proberen de tools te maken die je helpen effectief en efficiënt te zijn, en wat echt leuk is als je naar onze website gaat, we hebben een heleboel freeware daar, dus als er niets anders is, ga dan downloaden - Ik denk dat we 20 of 25 freewares hebben. Er zijn echt heel goede freeware-dingen zoals een SQL Server en een Windows Help Check die gewoon kijken naar wat je hebt en je vertellen of je problemen of dingen hebt en het is helemaal gratis.
Eric Kavanagh: En jij bent echt een soort -
Bert Scalzo: Absoluut de eerste dingen-
Eric Kavanagh: Je spreekt vandaag over de heterogeniteit op de markt, er was een soort een-voor-iedereen-vergelijking die ik me eigenlijk herinner toen ik Dr. Michael Stonebraker interviewde lang geleden toen hij in 2005 verder ging een groot duwtje over vonnis over de kolomgeoriënteerde databasebeweging en hij had het allemaal over hoe het one-size-fits-all relationele model jarenlang domineerde, en hij voorspelde dat alles zou veranderen, en jongen had hij gelijk dat. Nu hebben we deze echt diverse en interessante omgeving met veel verschillende opties en mogelijkheden, maar je hebt iemand nodig om dat allemaal te beheren en het lijkt mij dat je bedrijf behoorlijk acuut is gericht op het oplossen van wiskundige problemen, waardoor het een enabler van de header van heterogeniteit, toch?
Bert Scalzo: Absoluut. Ik bedoel, er zullen altijd DBA's zijn die zeggen: "Ik wil geen GUI-tool gebruiken, ik doe alles met scripts", weet je? Ze denken dat ze het superman-type DBA zijn en dat is prima, maar voor de meesten van ons mensen willen we gewoon werk gedaan krijgen en - weet je, ik gebruik Microsoft Word om mijn documenten te schrijven. Ik gebruik Microsoft Outlook om mijn e-mail te doen. Ik bedoel, ik heb hulpmiddelen om taken uit te voeren. We bouwen hetzelfde soort concept, we bouwen tools voor databasebeheerders en ontwikkelaars om hen te helpen focussen op wat ze willen doen en niet hoe ze het moeten doen.
Eric Kavanagh: Dat is logisch, maar laat me je overgeven aan onze experts, en mensen voelen zich vrij om erin te duiken. We hebben een paar opmerkingen van het publiek. Misschien, Dez, een paar vragen en Robin een paar vragen?
Dez Blanchfield: Zeker. Een van de eerste vragen die ik je wil stellen, gezien de enorme ervaring die je hebt opgedaan, zie je binnenkort een moment waarop een van deze dingen gaat vertragen? Of denk je dat we echt aan het begin staan van deze voortdurende groeilijn van verandering? Ik denk dat een van de grootste problemen waarmee bedrijven te maken hebben, en dan steevast de mensen die proberen de technologie te ondersteunen die deze bedrijven krijgen om hun bedrijf te leiden, is dat de snelheid van verandering zo dramatisch is dat ze gewoon niet alles kunnen bijhouden de verschillende functies, en software, en systemen, en frameworks en architecturen, en nieuwe code in aantocht, en dan de hardware daaronder, zie je de huidige veranderingssnelheid helemaal onmiddellijk vertragen? Ik bedoel, je hebt te maken met zo'n breed scala aan platforms met de hele IDERA-suite. Gaan we snel vertragen of zitten we al een tijdje in deze gekke weggelopen goederentrein?
Bert Scalzo: Ik denk dat we ons bij de eerste 20 procent van die groeicurve bevinden en we hebben nog een lange weg te gaan en er zijn twee dingen die het duwen. De technologie blijft evolueren. U hebt enkele van de nieuwe geheugentypes genoemd die uit zullen komen, dat zal fantastisch zijn. Samsung krijgt hier binnenkort een flash-drive van 20 terabyte. Dat gaat dingen veranderen. We hebben al deze NoSQL- en clouddatabases, dit gaat gewoon door. Het enige dat wel best grappig is, is wanneer ik kijk naar databases zoals Oracle en SQL Server en sommige andere, het zijn echt geen relationele databases meer. Ik kan ongestructureerde gegevens in Oracle plaatsen en toch de ACID-naleving handhaven. Als je me dat 20 jaar geleden had verteld, had ik net gezegd dat je drugs gebruikte.
Dez Blanchfield: Ja, ja, ze zijn cool. Nou, zelfs nu die motoren die heel mooie niche verticals hebben, zoals GIS, gewoon beter dan native mogelijkheden nu. Je hebt een aantal geweldige opmerkingen gemaakt over de uitdagingen waar DBA's voor staan en de verschillende tijden van DBA's die we overal ter wereld hopen te zien, maar hoe ziet de wereld er uit met dat soort bedrijfsactiviteiten waarmee je te maken hebt? Ik bedoel, dit zijn de mensen die de verschillende platforms gebruiken, van je diagnostische manager, tot de inventarisatietools en helemaal tot het brullen tot het defragmenteren, hoe gaan DBA's om met deze verandering en hoe doen ze dat soort - weet je, wat doen ze met jouw tools om zo'n belangrijke verandering in hun landschap aan te pakken?
Bert Scalzo: Nou, ik ga bijna 20 jaar geleden terug, dan ga ik zeggen dat DBA's een zeer specifieke rol in een organisatie oplossen. Ze werken meestal met één databaseplatform, misschien twee, en ze beheren een relatief klein aantal databases. Nu snel vooruit naar vandaag en de databasebeheerder, hij gaat eigenlijk 10 databaseplatforms kennen. Hij beheert, en dit is geen grap, in sommige gevallen duizenden databases; dat is meer op de SQL Server-wereld of de MySQL-wereld. Maar nog steeds in de Oracle-wereld zouden ze honderden databases kunnen beheren. En dus hebben ze al deze nieuwe functies die uitkomen, ze hebben al deze nieuwe platforms en ze hebben al deze databases waarvoor ze verantwoordelijk zijn. Ze zijn op zoek naar hulpmiddelen om hun productiviteit mogelijk te maken en om hen te helpen een aantal dingen te leren.
En ik zal u een voorbeeld geven - als ik een tabel wil partitioneren, is het een behoorlijk obscure syntaxis, en als ik het wil onderverdelen, wordt de syntaxis nog moeilijker. Ik weet wat ik wil doen, ik wil emmers maken. Als ik een tool als DBArtisan heb die zegt: "Hé, hier is een mooi scherm waarmee je je kunt concentreren op wat je probeert te doen in plaats van hoe je het probeert te doen, en oh trouwens, druk op Laat de SQL-knop zien als je klaar bent en we zullen je laten zien wat de SQL was, zodat je dit echt kunt leren en beheersen. ”
DBA's ontdekken dat tools die hen helpen de klus te klaren, maar ook helpen hen al deze nieuwe dingen te leren die ze gebruiken en hetzelfde zou waar zijn - laten we zeggen dat ik een Oracle-man ben en ik ga naar MySQL en zeg, “Oké, maak een database aan, DBArtisan. Laat me nu de SQL zien, omdat ik me afvraag hoe het is om een database op MySQL te maken en ik heb net geleerd om te syntaxiseren. ”En dus helpen we ze niet alleen om te werken in meerdere databases, we leiden ze ook op in verschillende databases.
Dez Blanchfield: Het wordt nog interessanter als je uitkomt bij een aantal van de modernere - of niet moderner, dat is niet eerlijk om te zeggen - maar eens was een database een database. Tegenwoordig zie ik alles waar je het over hebt met de toegevoegde uitdaging die de technologie stapelt die we traditioneel van leveranciers zien en je soort open source erin en ook dat ze goed zijn. Niet alleen omgaan met de database-engines en de query-talen, maar ze gaan ook over de gegevenstypen, de gestructureerde en ongestructureerde, weet je, de uitdaging om te gaan met alles van het verre einde van het spectrum van een multi-petabyte HDFS omgeving tot kleine minuscule containers, en pakketbestanden en verschillende logbestandsformaten.
En ik denk dat dat iets is dat we nu zien waar geen enkel menselijk wezen is, ongeacht hoeveel een superman, supervrouw, wat ze ook denken dat ze zijn, fysiek kunnen ze gewoon niet mentaal omgaan met dat tempo van verandering en de schaal van variaties. Ik denk dat de suite met tools die je nu aanbiedt op een punt komt dat ze bijna op een standaardset staan op veel manieren, zodat we de databaseomgevingen die we zonder ze hebben niet kunnen uitvoeren, omdat we gewoon fysiek kan niet zoveel lichamen naar ze gooien. Ik heb echt genoten van je presentatie. Ik ga het doorgeven aan Dr. Robin Bloor, ik weet zeker dat hij ook genoeg vragen heeft om naar je toe te gooien.
Robin Bloor: Oké. Nou ik heb zeker vragen. Bert, ik weet niet waar je heen gaat - ik had een heel interessant gesprek een paar dagen geleden waarin iemand me begon te vertellen over de nieuwste DU-gegevensbescherming, en het leek me wat ze zeiden dat het ongelooflijk was draconisch in termen van dingen waar ze op stonden. Ik vroeg me af of je daar echt naar had gekeken; is het iets waar je bekend mee bent?
Bert Scalzo: Absoluut. Ja.
Robin Bloor: 2016, oké, vertel ons er eens over.
Bert Scalzo: En ik heb eigenlijk -
Robin Bloor: Diep interessant.
Bert Scalzo: Ik heb eigenlijk een tijdje gewerkt voor een flash-verkoper, in hun database-gebied om hen te helpen flash-producten voor databases te bouwen, en ik kan je vertellen dat de draconian helemaal naar beneden gaat. Wat ik bedoel is, als je je mijn dia herinnert, zei ik in sommige databases dat het de codering zal doen, maar het zet het in het servergeheugen en in sommige databases de codering - het is nog steeds gecodeerd in het servergeheugen, het wordt alleen gedecodeerd wanneer het wordt naar de client verzonden. Nou, wat je ook zult vinden, zijn enkele van deze overheidsstandaarden, vooral het ministerie van Defensie of het leger hier in de VS, ze gaan ook helemaal naar het flitsniveau en ze willen niet alleen weten dat je codering en decodering ondersteunt in je hardware, maar dat als iemand de chips heeft gestolen die - je weet wel, ze uit het ding hebt gehaald, uit je server, dat wat er is gecodeerd is en dus hoewel ze de opslag hebben, kan het niet zijn en ze zouden helemaal tot aan het daadwerkelijke - niet tot het flashgedeelte zelf, maar tot de afzonderlijke chips. Ze wilden die chip voor chip kennen, alles was gecodeerd.
Robin Bloor: Wauw. Ik bedoel, er zijn veel dingen die - weet je, ik denk dat het slechts een of twee dia's waren die je hierover hebt verteld, maar het was iets, een scenario dat ik erg interessant vind. Het redacteren van informatie bijvoorbeeld, er moet een beetje slim zijn dan alleen het maskeren van verschillende velden, omdat je tegenwoordig met machine learning tegenwoordig deductieve dingen kunt doen waarmee je informatie naar boven kunt halen die je voorheen niet kon opdoen.
Als je probeert te beschermen, laten we zeggen gezondheidsinformatie, dan zijn dat heel, heel draconische regels in de VS met betrekking tot gezondheidsinformatie, maar je kunt eigenlijk, met behulp van verschillende technieken voor machinaal leren, vaak uitzoeken wie iemands medische informatie is eigenlijk is. Ik vroeg me af of je daar iets over te zeggen hebt, omdat ze allemaal denken dat dat een interessant gebied is.
Bert Scalzo: Ja, absoluut, en ik gebruik dit alleen als voorbeeld. Ik probeer niet te zeggen dat de ene database beter is dan de andere, maar dit is een heel goed voorbeeld voor wat je zojuist hebt gevraagd. Als ik in Oracle bijvoorbeeld geen rij met gegevens mag zien, zoals het medisch dossier van John Smith niet mag zien. Als ik in Oracle zeg: "Selecteer dat record", wordt ik geblokkeerd of mag ik zien wat ik mag zien en wordt het opnieuw bewerkt. En als ik zeg: "Selecteer accountster uit de tabel waar John Smith gelijk is", krijg ik nul.
In SQL Server kan het redactie doen, maar het heeft enkele gaten. Als ik zeg: "Selecteer accountster uit de tabel waar het gelijk is aan John Smith", krijg ik er eigenlijk een terug, dus ik weet dat er een John Smith is. De ene is veiliger dan de andere. Nu verwacht ik dat ze dat oplossen, ze spelen altijd sprongkikker met elkaar. En nogmaals, ik probeer geen onderscheid te maken tussen de databases, behalve om een voorbeeld te laten zien - kijk naar waar we het nu over hebben, iets eenvoudigs als een select account moet ook worden verminderd door de redactie, hoewel technisch gezien er wordt niets anders geredigeerd dan het bestaan van de rij.
Robin Bloor: Ja, toch. Dat is best interessant. Ik bedoel, nog een algemene vraag omdat ik niet veel tijd heb, gaat eigenlijk alleen over de verbeteringen. Ik bedoel, je bent in één geweest waar ik weet dat je ons voorbeelden hebt laten zien van verschillende testresultaten die je hebt uitgevoerd - denk je dat de traditionele databases, laten we ze de dominante databases noemen, SQL Server en Oracle, vind je denk je dat ze de voltooiing voorblijven? Of denk je dat ze daadwerkelijk worden betrapt door een of ander soort verstoringen op de markt die echt voor hen lopen? Wat is jouw mening?
Bert Scalzo: Ik heb een mening en het is - weet je, nogmaals, ik ga zeggen dat het mijn mening is - Microsoft bijvoorbeeld, in het post-Ballmer-tijdperk maakt indruk op mij. Ik bedoel, deze uitgebreide database krijgt SQL Server op Linux, krijgt .NET over Linux, krijgt PowerShell over Linux; Ik denk niet dat traditionele leveranciers van databases achterblijven. Ik denk dat ze besloten hebben: “Hé, laten de nieuwe jongens, de startups iets definiëren. Laat ze uitzoeken wat sharding is en hoe het moet worden geperfectioneerd, en als ze eenmaal alle onderzoek en ontwikkeling hebben gedaan, weten we precies wat gebruikers willen, laten we nu sharding toevoegen aan Oracle. ”Ik denk dat ze gewoon slim worden en zeggend: "Hé, tweede of derde zijn is niet slecht als je de dominante speler bent, want dan zullen mensen niet van je migreren."
Robin Bloor: Ja, ik bedoel, het is een strategie die is gebruikt. Ik bedoel, IBM deed dat vroeger en de hele - voor hun hele productgamma's en het scoort redelijk goed totdat iemand met iets komt dat gewoon helemaal van de muur is waar niemand ooit aan gedacht heeft, maar je kunt niet plannen daar toch tegen.
Vragen uit het publiek, Eric?
Eric Kavanagh: Ja, maar je hebt tijd denk ik maar voor één misschien en ik weet dat Bert moet vluchten. Er was hier iets aan de hand - oké, de sharding-architectuur op Oracle 12c is dat een indicatie van - of wat is dat volgens jou, wat denk je dat daar gebeurt?
Bert Scalzo: Nou, Oracle absorbeert en / of biedt alles wat alle andere databaseleveranciers zijn. Ik kan bijvoorbeeld ongestructureerde gegevens in Oracle plaatsen. Ik weet niet hoe je ongestructureerde gegevens kunt plaatsen en het vervolgens een relationele database kunt noemen, dus het slaat nergens op, maar dat kan wel. En nu voegt Oracle scherf toe, dus zegt Oracle: "Weet je wat? Wat de markt ook wil, we zullen ons database-aanbod doen omdat de markt wil wat de markt wil en we de oplossing willen leveren, we willen dat ze bij ons blijven. ”
Ik denk dat je extra items gaat zien. Het zou me niet verbazen om Hadoop-achtige clustering van databaseknooppunten te zien, niet in een Oracle-rack of echte applicatiecluster, maar in feite in meer een traditionele Hadoop-achtige clustering die die sharding doet. En dus denk ik dat je een database zoals Oracle kunt inzetten zoals je een Hadoop zou doen, en dit soort trends zullen doorgaan. Deze grote databaseverkopers verdienen miljarden dollars en willen hun markt niet verliezen, dus ze zijn bereid zich aan alles aan te passen of iets aan te nemen.
Eric Kavanagh: Nou, weet je, het is grappig omdat ik de open-source leveranciers al een hele tijd heb gevolgd en me dat allemaal heb afgevraagd terwijl het een grote impact zal hebben op de traditionele technologie met gesloten deuren, en voor een tijdje het voelde zeker alsof de open-source-verkopers serieus vooruitgang boekten, en nu ik naar de markt kijk, zie ik een soort van wat je zegt, dat de grote jongens hun wiskunde hebben gedaan, hun potloden hebben geslepen en ze bedachten hoe ze kunnen veel van dat soort dingen in hun architecturen weven. Of het nu IBM, of Oracle of SAP is - ik was vorige maand net op de SapphireNow-conferentie en Steve Lucas, die de helft van dat bedrijf leidt, schepte op dat SAP nu meer open-source componenten in hun HANA-cloudplatform opneemt concurrenten. Als je daar de wiskunde over doet, is het een behoorlijk indrukwekkende uitspraak en het vertelt me dat de grote jongens niet snel ergens naartoe gaan.
Bert Scalzo: Nee, ik zou mijn geld op beide inzetten. Ik bedoel, als je kijkt, lag de voorraad van Microsoft onlangs op ongeveer $ 50 en, weet je, slechts een paar jaar geleden was dat op 25. Je verdubbelt je aandelenkoers niet in een korte periode tenzij je goede dingen doet en, je weet je, van alles doen vanaf Windows 10 dat het eerste jaar gratis is tot alle andere slimme dingen die ze doen, deze uitgebreide database-functie vind ik gewoon fenomenaal. Ik denk dat wat er gaat gebeuren, veel mensen zullen eindigen in Azure, niet direct, niet zoals ze zeiden: "Laten we mijn database naar Azure migreren." Het zal daar op magische wijze migreren omdat het gearchiveerd wordt daar met behulp van deze nieuwe stretch database-functie en dus zal de acceptatie van Azure alleen maar omhoogschieten.
Eric Kavanagh: Nou, dat is een van de trends op de markt die zelfs ik kan zien, zelfs op je Mac. Terwijl je in je Mac gaat om wat documenten op te slaan, nu - en de nieuwere Macs volgen gewoon door de cloud, toch? Ik bedoel, er zit veel zin in die strategie en ik kijk er ook naar en ga: “Oké jongens, je probeert me stuk voor stuk in je cloudomgeving te lokken, en op een dag als ik een film wil kijken als mijn creditcard is verlopen. Ik ga in de problemen zitten. "
Bert Scalzo: Ja, maar je doet het op Facebook.
Eric Kavanagh: Ja. Dat is waar.
Bert Scalzo: Je zet alles op Facebook.
Eric Kavanagh: Nou, niet helemaal alles.
Bert Scalzo: Nee, ik bedoel-
Eric Kavanagh: Ja, ga je gang.
Bert Scalzo: deze sociale trends bereiken bedrijven. Nu hebben bedrijven nog veel andere dingen die ze moeten doen, maar ze zien deze trends en ze doen hetzelfde. Ik zie Oracle of Microsoft niet verdwijnen. Sterker nog, ik ga elke keer aandelen kopen als er een dipje is.
Eric Kavanagh: Ja, inderdaad. Nou mensen, ga naar idera.com, IDERA dot com. Zoals Bert zei, ze hebben daar een heleboel gratis dingen en het is een van de nieuwe trends op de markt - geef je wat gratis dingen om mee te spelen, word je verslaafd, en dan ga je de echte dingen kopen.
Mensen, dit is weer een Hot Technology geweest. Bedankt voor je tijd vandaag, Bert, Dez natuurlijk en Robin ook. We spreken je volgende week, mensen, er gebeurt veel. Als je ideeën hebt, kun je die van jou echt e-mailen, . We zullen de volgende keer met je praten, wees voorzichtig. Tot ziens.
